Haven’t you also often made a moat between yourself and doing literally anything else more interesting at the company?
back
10 comments
Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy.
Here, parent explained in detail how to get stuff done, management very happy and secure their position for years to come.
> Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy
Truth is harsh, however this seems to be 100% accurate for nearly all cases of employment. Rarely do you get to focus on simply interesting problems and good engineering as a primary concern
Boredom is in the mind, not the task. Things aren't boring, people are. An important type of intelligence is the capacity to find what's interesting about a task that others lack the imagination to see. One needs to be able to create their own interesting solutions rather than expecting them to be handed down on a plate.
> find what's interesting about a task that others lack the imagination to see.
word of warning from an old guy, don't create problems for yourself when you don't have to. Turning something boring into something interesting can have painful consequences down the road.
Boredom is lacking stimulation. Even the most cutting edge task can grow boring if you need to plumb with it dozens of times over a year. Just because you can find what's unique doesn't mean it stimulates you. That's the exact issue with why neuro divergent individuals are demonize: they don't take as much interest with people as "normal people" would.
>One needs to be able to create their own interesting solutions rather than expecting them to be handed down on a plate.
You should tell that to every old manager I had.
I’ve got some mulch in my yard that needs counting.
Everything in this comment is gold.
> Things aren't boring, people are.
What a strange thing to say! Aren't people also kind of... things? Shouldn't they be at least as interesting as things?
You gotta go into R&D if you want to focus on the fun stuff without the annoying plumbing. But such positions require an entirely different pipeline from getting a SWE position out of college.
A good way to secure your position is to be the go-to expert for a product with many years of life ahead of it.
Fixing stuff on a legacy product may make management happy but if that product is discontinued next year then you haven't accrued technical expertise valuable to the company (but you may have built a reputation as a fixer and quick learner).
So, as usual, it is a balancing act.
Edit: this is my perspective from the embedded world. It probably applies generally, though.
I'm referring to embedded, not web dev.
When times get tight the new projects get shitcanned and the 10 year-old cash cow design gets the promised new features.
One crusty project I worked on was a legacy control board for a piece of restaurant equipment. The customer, the company that built the actual machine, had been building this product for 40 years. It had been through two PCB redesigns and two different microcontrollers, but the logic was tried and true and had to survive. A port of the project from 6800 assembly to C had completely gone off the rails and the contractor was dumped. All it took was a 20-opcode fix to a routine that the contractor just couldn't grok.
It is indeed, but at the same time, things that have stuck around tend to stick around, and hot new things have a way more variable longevity score.
I wouldn't say that's the conclusion. If there's only one true thing about work is: management doesn't care about you. They can fire you for any reason, and thinking that by working on stuff nobody else wants to work on you are "safe", it's an illusion.
If any the conclusion is: work on what you want, life is short.
Engineers have a special place in society like doctors and lawyers. Working with management is part of the job, but engineers have a professional ethical obligation to say no if they are asked to something against the public good.
The split there isn’t in favor of doing stuff that’s fun and novel though; actually, the engineer should usually pick a boring proven solution if the public has a high stake in the outcome.
Only valid when engineering something which can kill/hurt/pollute. These areas are regulated and can carry personal liabilities when it goes wrong.
But the vast majority of HN topics are not concerned. Additionaly, it does not pay well
> Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy.
That's a perfectly reasonable thing to want out of engineering for yourself. I wouldn't state it as an absolute truth for all people though.
Personally, I'd like to be working on something that extends the state-of-the-art a little, even if only by a tiny fraction. It can be one for the other disciplines involved - it doesn't have to be the software I'm writing that is responsible for that (and it usually isn't), but that's what I derive satisfaction from.
It depends on your goals, though. Depending on the company, that can be a very good way to be treated as a cost centre to be minimised.
Yes, let's minimize the only dev working on legacy software.
Do you think that software becomes poorly understood and maintained because the company treats it as a prestigious job and rewards people for working on it?
This is how I got laid off. Working on legacy software, sole person on the team, eventually management decided that it could be replaced by AI or some such pixie dust.
That's a very narrow definition of engineering. And while it's not wrong, it's absolutely more of a "management" POV. Like sure, for management, engineering is mostly about what you said, but that's it.
Well, that's just, like, your opinion, man.
Depends on your definition of interesting?
I find improving established code of far more interest and reward than greenfield. Coming to understand what a person was thinking while building something is fascinating. My updates are tangible life improvements to real human beings. That interests me, at least.
Greenfield, I have the incredibly stressful job of making all the major architectural mistakes people will complain about for years to come. I'm not interested in that. There's also a much higher chance with greenfield that the product will just fail and no one will enjoy your work.
I’m interested in finding the patterns and architecture that prevents those mistakes. I think I’ve found it already.
You've found a way to correctly anticipate new user needs and new technologies years, even decades, in advance?
And you've found a way to completely forestall the non-technical demands that force non-ideal design choices?
You're sitting on a gold mine friend.
I should say not prevent it. But minimize it in the maximum possible way.
I am sitting on a gold mine. But I can’t prove it. That’s the problem with this stuff. The industry moves horizontally with each design such that nobody knows if say the current design trend was better than the last. We go better or we go worse and nobody knows if it actually was.
Maybe I am sitting on a gold mine. The problem is you’d never know about it. You’d never believe it. Because a proof isn’t possible.
So because it’s not provable you have no clue about any design whether one is better or one is worse and thus you disbelieve everything.
The overall question is how do you create a design or pattern that has maximum adaptability to anticipate any possible requirement change with minimal rewrites? Where you only swap in and swap out modules without changing structure?
I think I found the best possible way. But you won’t believe me.
Check back in a couple years ;)
I did it. There’s always things that went wrong. But I found the way to minimize it.
I pulled this strategy at a new company and found that it opened up a million opportunities I could take my pick of. I basically got to shape my own role going forward.
Why? Because I very quickly made a name for myself as someone who learns quickly and then gets stuff done even in contexts where everyone else struggles. Solving problems that have long been considered intractable is a good way to show your value.
This is 100% true. Those problems you are solving probably don’t look all that important, but, in reality, they have been blocking sales, renewals, account expansions, or even access to markets for a long time. The business side of the house has probably given up or occasionally tries to wag the dog to get it fixed.
> Haven’t you also often made a moat between yourself and doing literally anything else more interesting at the company
Nope, assuming that code works and handles UTF8 (sorry, but there is a point where it is too far gone to save). You’ve made yourself essential. You know the business better. You are strategic. And often, you become the one person who knows the legacy code base. And you will quickly find yourself a part of super important decisions. You’ll be called out regularly for fixing things that have gone unfixed for years. You’ll also drive value by helping the company avoid spending vast amounts of money re-implementing functioning code. On top of that, new product is often a mix of new and old, so you’ll quickly find yourself in the middle of new product teams.
These insights are essential for playing the long game; it may sound distasteful for people early in their careers. That’s fine, but when you’re running out the clock to retirement, can’t go wrong.
It's not just about job security.
Even at a young age, some people find it super fascinating to work with old stuff and study the traces of people long gone.
If you're that kind of person, digging into an old assembly codebase is going to be so much more fun than learning some newfangled web framework.
I have hobbies.
The most interesting work is going to be 10% interesting and 90% not interesting. In most cases it will be less interesting than that.
Prioritizing "interesting" work means you'll always be exploited by the companies that can sell you on less pay, less benefits, less time off, less respect in exchange for some pittance of perceived novelty. Don't fall for this trap.
Ex: Game development.
tell me you don't have ADHD without telling me you don't have ADHD
For what it's worth, I find it much easier for my ADHD to debug and improve existing code than to greenfield - it's actually interesting. Debugging is like a detective's work with small dopamine hit at each step of unraveling the situation and a huge reward once you finally grasp it. It's best to do on someone else's code, so you don't get too frustrated with your past self ;) Greenfielding provides some rewards too, but once I'd greenfielded anything remotely similar already there's a lot of forcing myself to do it around the beginning and end, where there's plenty of unrewarding work to do. For greenfielding to be fun and easy, it needs to be a completely new area that I had no previous experience in, but that doesn't tend to end up with excellent results.
In a world where everyone has ADHD, I welcome these few non-ADHD aliens.
Actually you're completely wrong. I do have ADHD.
As a senior engineer your job is to take on the unglamorous hard problems, both technical and organisational, that are holding the team back. Doing this, and being seen to do it, early-on in your time with an employer will be somewhere between appreciated and expected.
If you do this you should also be good at story telling. Not working on the new things, but making sure the core business running, is often times looked down upon in my experience. Most leaders will see the greenfield project move fast and wonder why the established and "complete" software moves slower.
Yes, thats a very good point. And one that I learned to my cost in a previous job.
What could be more interesting than code that has managed to survive in the trenches of production?
More often than not it’s not enough work to just work on the legacy system that keeps chugging.
Nope. If you're willing to take on the shitwork without a lot of handholding and show real progress (which actually impact earnings) you'll have a really good stab at new opportunities.
> doing literally anything else more interesting
I found that working on legacy projects is often the most interesting.
There is the challenge of understating the original code base, which may look messy, but is full of history, you see the architectural mistakes and their consequences, how they managed to fix obscure bugs, tackle unexpected use cases, different code styles,... Then they ask you to implement a feature or fix a bug, you have to find what can be touched and what can't, what is a bug and what is a feature, see how much time you have, and decide on a strategy. This is production code and people are using it right now, and they are efficient with it, you have to help them and not force them to relearn everything for no good reason.
And there is technical debt management, your goal is to make the code better or at least not worse, but without introducing breaking changes and under time constraints. You have to manage your off time to make improvements that will help you in the future (chose wisely) as the next truckload of tickets arrive. It includes having a good relationship with your managers as no one wants you overworked, as it would just cause technical debt to accumulate with no time to repay it.
And good luck getting an AI to do that, if you want job security in the age of LLMs, that's your change. It doesn't mean you can't use AI, but you certainly won't be replaced by it.