Being a senior software engineer comes with many challenges, but one of the main ones is probably the conflict between spending energy on high level discussions and hands-on engineering. I already touched on some of this in the Life as a Senior Engineer post , but I thought it might warrant a bit more discussion, something I hope is useful both for senior and junior engineers. Small note: there's a lot of sausage in this post. I don't hate sausages, I like them a lot, and if you work at an actual sausage factory: sorry, I mean no disrespect.
First let's cover the sausage factory. My view on software engineering, and life in general, is that it's mostly a mess. You try to package as much of it as you can in something that looks nice, but when you poke it a bit it turns out that it's not all pretty - which leads to the sausage factory.
The software engineering sausage factory is a large one with a shiny outside, a couple of nicely looking facilities, but as you get closer to the actual making of the sausages you get more and more apprehensive. To quote Seinfeld: knowing you is a bit like being in the jungle - I never know what I'm going to find next, and I'm real scared .
So when you go into the sausage factory as a junior engineer it all seems pretty nice. Everything is clean, there's a plan, and you just need to do your work. But the more senior you get the more you realize that plans are shallow and often not founded in much other than personal opinions, strange compromises, or conflicting business priorities.
And interestingly, what gets made in the factory is not the actual product - hands-on software engineering takes place elsewhere. Instead, the factory produces decisions, which are often hard to understand if you weren't there when they were made (and even then they might not be too easy to understand).
This explains one of the tensions you often encounter as a senior engineer: you see a bigger picture and all the compromises that go along with that. Those compromises translate into technical design decisions that to individual teams can seem wrong, possibly even stupid.
The challenge then becomes to explain how the smaller parts fit into a larger picture. Failing to do so usually results in resentment and accusations of drive-by architecting. If you're lucky your company is on Blind, and people will provide very candid feedback there.
All of this usually leads to you having less time to do hands-on engineering, because you get caught up in writing documents, design reviews, decision making, and much more - and also, your conscience might not allow you to ignore the mess that's in the factory. Which might work out fine for a while, but suddenly you realize that you don't really know what's going on any longer, and more junior engineers no longer regard you as a role model. Why? Because your engineering hourglass is empty and you're now only an engineer by title.
The engineering hourglass is the thing that happens when you stop being hands-on. As soon as you do that the hourglass starts emptying. There is of course no strict rule on how long it takes to empty, but I'd say 2-3 months. It resets when you do more hands-on engineering, but if it runs out it's incredibly hard to reset since at that point you're out of touch with the code base, your development environment no longer works, and a lot of other things have changed since you last looked, which all means that you have to spend even more effort getting up to date again.
But so what if the hourglass is empty? Isn't it better to spend time where your special powers can be utilized best? I've seen various people claim that it's not the act of coding that's important, it's the ability to design and guide. However, the thing is that your special powers don't remain special for that long, so you need to keep improving, and that does (in my absolutist view) mean coding, reviewing, being on-call, etc.
It's a balance, of course, but given one option of not coding at all and another of not designing at all, I'll pick not designing any day. Mainly because there's just about zero chance you'll be able to code without designing, even if it's not explicit, but it's very possible for you to design something that can't actually be implemented in code in actual real life.
That concludes the story of the sausage factory and the engineering hourglass. Key takeaways?
The more senior you get the more you get to visit the factory.
If you're junior then appreciate the fact that someone else is doing it for you and reflect on how decisions might include components you're not aware of.
Don't let your engineering hourglass run out.
First published on LinkedIn, 21 March 2024.