I, much like all of you, love making things. We like to take things apart and figure out how to put them back together. Or, well, at least attempt to put them back together. We then chose this as our career path. We might even be decent enough at it to get paid for it. Much like everything else that becomes a job, we end up getting burnt out and start to dislike it. So lets dissect the bad parts from the good to make a more meaningful career out of it!
The first thing that's incredible about this career path is the human element. Humans make mistakes and we learn from those mistakes. As software engineers are typically pessimistic, you'll be reminded of your mistakes quite often. Software engineers typically spend their days debugging issues and critiquing design. That affords that kind of mindset into our daily lives.
What's so cool about this is that your past mistakes become a tool for others to take advantage of. Take a former tech lead colleague of mine for example. Passionate person who lives and breaths design patterns and software engineering. You know the type, they're constantly in the director's office persuading their agenda, justifying their existence by forcing unnecessary changes.
The platform team created a cli to spin up a local dev environment. So this tech lead went to task immediately. Became a change-agent for the good of all developers in the company. A virtual pillar of light in the dark ages of spinning up your own development environment. Everyone has the same environment eliminating the issues that come with differing operating systems or dependencies or what have you. One could spend unlimited hours talking to different developers in the office the benefit of using such a tool.
What you begin to learn over time as a software engineer is that rolling your own tools tend to introduce complications. Using your experience you shy away from making immediate change so that tools can be hardened and battle-tested. Luckily for me I caved immediately and began to use this tool. Issues abound, but I was able to work through them and even make changes to the tools source. Once things were pretty normal over time I began to simply use it as intended and forgot about it. After a while I began to notice issues. Things weren't working and debugging internal tools is always super easy. Internal tools always include rigorous documentation. CLI Internal tools like include exhaustive help commands along with examples for every parameter. These tools are deeply embedded with package managers for easy update. Or not. Any way, I became the only developer with the issue I was facing. It took the manager of the platform team and I the better part of a day to diagnose the issue and to my embarrassment I needed to update the cli.
As you can guess by now the next few months felt like minutes. I like to reflect back on something one of my previous CTOs would say at all hands meetings. "What gets you out of bed in the morning excited for work?" After over hearing the first time I was being used as an example to keep all of our tooling up to date my drive to be a better dev was never higher. After hearing this one issue in performance reviews because managers totally don't hear something negative once and then harp on it for the next year. What got me out of bed every morning was the knowledge I was being used as an example of how others can be better.
Here's where the bad part comes in. I sometimes like to defend myself and my position. Did the CLI tool mention any deprecations? Did the CLI tool recommend upgrading in a warning? Was the cli tool in an easy to use package manager or was it like every single other internal tool and you had to build the thing yourself? None of that matters or will ever matter. At the end of the day I took a manager's few hours to diagnose an issue that was already fixed.
What were we talking about? Ah, yes, building things. That's what we do. I forgot. That's what we as the builders get recognized for! The things we build!
Sometimes when other people have an agenda, it feels really good to be a part of that change. One great thing that happens as a non managerial or lead engineer is the glory of completing and deploying such a change for the betterment of customers internal or external. Say you have this tech lead that is starting an MVP (minimal (non) viable product(bug riddled barely pseudo code)). You get tapped to be a part of this. Take it forward. Productionalize (Technical term. see also: un-f*ck) it. It replaces an old thing, build upon it, makes it better! Managers are happy! Customers are um, well, they hate it but its better so they'll like it eventually! Then the best thing happens. Tech lead gets tapped to work on another project. Issues poor in as customers start to use it. System design can't handle a feature that was in the old functionality? No matter, you're there to save the day! The rest of the team moves on to other projects but you volunteered for this one. However your team still needs to make progress on this new thing that was moved on to. You feel bad that you can't contribute because you had to work on this other thing. What becomes really slick is on standup management or leads or staff members like to bring something up in general. Like for example "this new feature isn't going away so I don't know why some of you wouldn't expect to fix issues as they arise" Haha! This is surprising to you because you have a team. The team should have items in backlogs or whatever that the team can work on right? That's how this works right? Whomever is on the team can work on any item. Sure. You bring that up with your manager. Turns out that's how it works! "Also why aren't you working on the new thing we have deadlines?! Can you fix these issues or not?" Super cool. Love it.
Often times in your career you get to experience switching teams. With layoffs and condensing team sizes this will start to become relatively normal. Thanks Musk. Sometimes you get a manager that has a hard time explaining definites. They don't like to allow for criticisms to those changes except for their A-Team. With these kinds of managers you'll typically hear about changes through the grapevine. I met with my manager one time after hearing I would be joining a different team from a fellow engineer. I brought it up in our 1:1 and he was like oh yeah, hey, can you start joining this other teams stand ups and helping them out? I was like sure. I then thought that was it, I would temporarily help them out. In our next one on one after attending both stand ups. They mentioned: hey can you stop attending our standups and only attend that teams standup? This was an actual conversation. I liken joining a new team to joining whole new job. You definitely are given a ramp up time on said team, right?
So here we are in 2024. Things have changed. As an engineer you have way more competition. You can be let go for any reason at any time and it turns out there are engineers decentish enough to figure out what you did to keep things running. You're replaceable. There's these new tools that make you even faster at doing the fun part of the job so you can spend your hours doing the other stuff. The even better stuff. The human element. You will write less code and you'll love it! You'll be passionate about it! "You'll enjoy the changes or you'll find you don't belong here" - Actual CTO from actual software company all hands.
"I just want to write software!"
Top comments (0)