In the darkest of days, I discovered how to remote login to my computer at work through the company vpn. I then proceeded to work overtime at night in secret for a week or so, writing documentation and refactoring code.

I finally woke the fuck up and realized that I shouldn't be obsessing over proprietary codebases that do not belong to me, and I should put this misguided energy into my own projects.

So yeah, as a bad dev habit I'm working on fixing, this fits the bill.

Udemy courses are targeted at ABSOLUTE beginners. It's excruciating to pull through and finish the course "just because". And some of these courses are jam-packed with 30-60 hours just for them to appear legit, but the reality is the value you get could be packed to 3-5 hours.

You're better off just searching for or watching for the things that you need on Google or YouTube.

You'll learn more when building the actual stuff. Yes, it's good to go for the documentation. Just scratch the "Getting Started" section and then start building what you want to build already. Don't read the entire documentation from cover to cover for the sake of reading it. You won't retain everything anyway. Use it as a reference. You'll gain wisdom through tons of real-world experience. You will pick things up along the way.

Don't watch those tutorials with non-native English speakers or those with a bad accent as well. Native speakers explain things really well and deliver the message with clarity because they do what they do best: It's their language.

Trust me, I got caught up in this inefficient style a handful of times. Don't waste your time.

What an absolute fucking disaster of a day. Strap in, folks; it's time for a bumpy ride!

I got a whole hour of work done today. The first hour of my morning because I went to work a bit early. Then people started complaining about Jenkins jobs failing on that one Jenkins server our team has been wanting to decom for two years but management won't let us force people to move to new servers. It's a single server with over four thousand projects, some of which run massive data processing jobs that last DAYS. The server was originally set up by people who have since quit, of course, and left it behind for my team to adopt with zero documentation.

Anyway, the 500GB disk is 100% full. The memory (all 64GB of it) is fully consumed by stuck jobs. We can't track down large old files to delete because du chokes on the workspace folder with thousands of subfolders with no Ram to spare. We decide to basically take a hacksaw to it, deleting the workspace for every job not currently in progress. This of course fucked up some really poorly-designed pipelines that relied on workspaces persisting between jobs, so we had to deal with complaints about that as well.

So we get the Jenkins server up and running again just in time for AWS to have a major incident affecting EC2 instance provisioning in our primary region. People keep bugging me to fix it, I keep telling them that it's Amazon's problem to solve, they wait a few minutes and ask me to fix it again. Emails flying back and forth until that was done.

Lunch time already. But the fun isn't over yet!

I get back to my desk to find out that new hires or people who got new Mac laptops recently can't even install our toolchain, because management has started handing out M1 Macs without telling us and all our tools are compiled solely for x86_64. That took some troubleshooting to even figure out what the problem was because the only error people got from homebrew was that the formula was empty when it clearly wasn't.

After figuring out that problem (but not fully solving it yet), one team starts complaining to us about a Github problem because we manage the github org. Except it's not a github problem and I already knew this because they are a Problem Team that uses some technical authoring software with Git integration but they only have even the barest understanding of what Git actually does. Turns out it's a Git problem. An update for Git was pushed out recently that patches a big bad vulnerability and the way it was patched causes problems because they're using Git wrong (multiple users accessing the same local repo on a samba share). It's a huge vulnerability so my entire conversation with them went sort of like:

"Please don't."
"We have to."
"Fine, here's a workaround, this will allow arbitrary code execution by anyone with physical or virtual access to this computer that you have sitting in an unlocked office somewhere."
"How do I run a Git command I don't use Git."

So that dealt with, I start taking a look at our toolchain, trying to figure out if I can easily just cross-compile it to arm64 for the M1 macbooks or if it will be a more involved fix. And I find all kinds of horrendous shit left behind by the people who wrote the tools that, naturally, they left for us to adopt when they quit over a year ago. I'm talking entire functions in a tool used by hundreds of people that were put in as a joke, poorly documented functions I am still trying to puzzle out, and exactly zero comments in the code and abbreviated function names like "gars", "snh", and "jgajawwawstai".

While I'm looking into that, the person from our team who is responsible for incident communication finally gets the AWS EC2 provisioning issue reported to IT Operations, who sent out an alert to affected users that should have gone out hours earlier.

Meanwhile, according to the health dashboard in AWS, the issue had already been resolved three hours before the communication went out and the ticket remains open at this moment, as far as I know.

This happened today...
Manager: how long this is going to take?
Dev: 3 months
M: cool! 3 weeks then
D: no.. This is quite complicated and most of us are unfamiliar with the topics. It'll take us 2 weeks just to get started
M: drop the unit tests then. Just get the features done in 3 weeks. We have customers waiting
D: that's a bad idea. We'll end up with unstable co..
M: oh we also need to complete documentation, release guide, and this [shitty feature no one care about]
D: but that is even more complex. We don't have enough ti..
M: just copy it from stackoverflow. It'll only take 5 minutes guys

Worst part? This guy is technically sound and understands our pain really well. He is just acting dumb and trying to put the blame on us when the higher management asks

Second worst part? The whole team keeps silent when I try to convince him somehow and starts ranting after he leaves the call

This would be my first official post.

Been a IT Technician for a managed service provider for the past 9 years up until last year August. Managing director pulls me in with a movement to App Development after coming across some personal hobby projects I have done in the past.

Started in the new position in November as Junior Developer and workloads get dumped on me and left to figure it out. 4 weeks of running through code without documentation and the solutions started to make sense.

Started a new solution for a Large remote customer with documentation and timelines in December and I get pulled in again for a second time in front of the MD.

Good News:With effect in January I have been promoted to Head of Application development.

Bad News: The existing department head is leaving end of the month and I am to go 900km from home to hand over all responsibilities for the next 3 weeks.

Better News: Department has started shifting to DevOps and it is up to me to set the policies and work flows to how I see fit.

Worse news: it starts by expanding the team asap as 10 projects accounting to 4000 man hours with deadlines in Q3.

Wish me luck. It's going to be twisted Rollercoaster ride...

Documentation is like sex:
When it's good, it's very good.
When it's bad, it's better than nothing...

Holy shiiittttt I finally got 64bit NASM working on windows with cmake. Cmake documentation is fkn bad man.

I’ve got a c++ file that calls a procedure in an assembly file that calls win32 APIs to show dialogs and other cool shit. Compiling was working fine, linking turned out to be a bit of a pain in the ass, but figuring out how to enable NASM in cmake was a nightmare. Why is the cmake docs so horrific 🥺

There has to be a software project bingo somewhere where I could just mark one item at a time of what's wrong and should be fixed, eventually leading to the same loop all over again. Items include, but are not limited to:

- The application is too tightly coupled
- There are too many repos and people can't keep track
- Someone forgot to create a naming convention for everything
- Nobody is reviewing pull requests
- Someone opened a PR for their 1 month of work
- Some team created a service for themselves, that doesn't cover use cases for every other team (who didn't tell anyone they needed it), thus it was a bad thing
- Business owners telling something needs to get done now and go talk directly to a developer
- Nobody thought about network latency in microservice architecture
- There's an invalid translation in this string, let's push the MVP another two months to make sure everything is perfect before launch
- The API gateway has business logic in it
- Business wants to focus on output, development teams in outcome
- "You need to request a virtual machines from the IT department so we know you won't mine bitcoin there!" Takes two months to fulfill that request.
- <add documentation here>
- 675 vulnerabilities in packages
- People complain about not knowing what others are doing, but nobody wants to speak up

My best and worst dev experience this year was getting a new job.

The bad parts: I’m inheriting a code base that was maintained by an outside agency, so there’s very little documentation. There’s a lot of systems maintenance and upgrades that have to be done because it was never done. I’m working at a larger organization, so tracking down who I need for info can be tricky. I’m the only person maintaining my code base.

Now the good parts: Better pay and benefits. My co workers, dev and non-dev, are always helpful. Since the dev team is small, we are very discerning when we pick up work for the websites. I have more independence to self-learn. I’m not at a blame culture. My role is permanently remote.

So far I think the good outweighs the bad.

I'm drunk and I'll probably regret this, but here's a drunken rank of things I've learned as an engineer for the past 10 years.

The best way I've advanced my career is by changing companies.

Technology stacks don't really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it's not going to be the same as webdev or embedded. But all fields have about 10-20 core principles and the tech stack is just trying to make those things easier, so don't fret overit.

There's a reason why people recommend job hunting. If I'm unsatisfied at a job, it's probably time to move on.

I've made some good, lifelong friends at companies I've worked with. I don't need to make that a requirement of every place I work. I've been perfectly happy working at places where I didn't form friendships with my coworkers and I've been unhappy at places where I made some great friends.

I've learned to be honest with my manager. Not too honest, but honest enough where I can be authentic at work. What's the worse that can happen? He fire me? I'll just pick up a new job in 2 weeks.

If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.

pour another glass

Qualities of a good manager share a lot of qualities of a good engineer.

When I first started, I was enamored with technology and programming and computer science. I'm over it.

Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all.

The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)

Related to above, writing good proposals for changes is a great skill.

Almost every holy war out there (vim vs emacs, mac vs linux, whatever) doesn't matter... except one. See below.

The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me.

If I ever find myself thinking I'm the smartest person in the room, it's time to leave.

I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.

We should hire more interns, they're awesome. Those energetic little fucks with their ideas. Even better when they can question or criticize something. I love interns.

sip

Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us.

Tech stack matters. OK I just said tech stack doesn't matter, but hear me out. If you hear Python dev vs C++ dev, you think very different things, right? That's because certain tools are really good at certain jobs. If you're not sure what you want to do, just do Java. It's a shitty programming language that's good at almost everything.

The greatest programming language ever is lisp. I should learn lisp.

For beginners, the most lucrative programming language to learn is SQL. Fuck all other languages. If you know SQL and nothing else, you can make bank. Payroll specialtist? Maybe 50k. Payroll specialist who knows SQL? 90k. Average joe with organizational skills at big corp? $40k. Average joe with organization skills AND sql? Call yourself a PM and earn $150k.

Tests are important but TDD is a damn cult.

Cushy government jobs are not what they are cracked up to be, at least for early to mid-career engineers. Sure, $120k + bennies + pension sound great, but you'll be selling your soul to work on esoteric proprietary technology. Much respect to government workers but seriously there's a reason why the median age for engineers at those places is 50+. Advice does not apply to government contractors.

Third party recruiters are leeches. However, if you find a good one, seriously develop a good relationship with them. They can help bootstrap your career. How do you know if you have a good one? If they've been a third party recruiter for more than 3 years, they're probably bad. The good ones typically become recruiters are large companies.

Options are worthless or can make you a millionaire. They're probably worthless unless the headcount of engineering is more than 100. Then maybe they are worth something within this decade.

Work from home is the tits. But lack of whiteboarding sucks.

Today, I started a new project with Rails. I used always an own auth implementation, now I thought I'll give devise a try. Hell... the documentation is bad, really really bad. I really don't know why people are using this and don't write this by themselves. Anyway, I kicked devise and write it again by myself.