Tenure in this field is short enough that most devs are renters, not owners, so the mortgage isn't your problem.
I suspect that drives a lot of the problems.
I suspect that drives a lot of the problems.
Also, super-long-tenured engineers can be detrimental. There can be a tendency to not document anything when you can always just ask one of the oracles of knowledge that originally built it.
The wrong type of super-long-tenured engineer is just going to be defensive and full of excuses about why something was built one way, even when the pain of using what they built is dragging down the whole organization.
They will push back on anything new and choose to add incremental blobs of crap code to their existing pile of crap instead of breaking things down and using their learnings to help design the new system
Haha. So true. Isn’t the adage you’re either changing or dying?
Once you start thinking about the code in terms of memorization you’re a hazard to your coworkers. It’s one of the reasons I like to try to move about on projects.
When you built the code you had to think about two or three concepts at once. Then new functionality added another concern, and another, and another. For you, each addition was one more thing on a pile you already knew.
For someone new looking at that code, they have to now juggle ten things at once, so they either run away, or they learn by breaking things. Which the frustrated tenured person may use as confirmation bias about how all the new hires are worthless and we should only trust senior people. When really the entire situation is your fucking fault.
They don't need to stay 20 years, but at least someone should still be there from beginning to end of a 5 year or even 2 year project.
I'm pretty guilty of this. The way I see it, I can either tell someone now why things are, or I can let them waste time figuring it out for themselves.
If you stick around long enough, eventually you become partially responsible for a collection of projects built by people who came, did a passable job, then left. I'm not keen on spending months rewriting a system just because the current one has some issues. And if it needs a new feature/update, I have no problem tossing a turd on the pile of crap.
Granted, I see the appeal of rewriting things. You get to spend 12-18 months building a new project the way that you want it, then leave once it is built and the maintenance responsibilities kick in. These people have never had to actually maintain software before, so they have no idea how to even write maintainable software.
I still maintain that most of the legacy of the dot com boom bust cycle was not developers learning bad habits, but managers figuring out enough lines of bullshit they can tell people to string them along for 18-24 months and getting promoted or a new job after everyone figures out everything you said is empty (lies).
That’s IMO the root of the tech debt problem. Devs ate it up, but they were coached as well.
Not even close. Can easily have three people manage the same project in a two year period.
That would be somewhere between stereotyping and pernicious pessimism, and at your tender age you don't want to think about yourself in either of those ways, so we'll wait to see if this person will actually deliver or not. Great route to burnout.
Wouldn’t we also need to blacklist a company that loses a programmer before the five year mark?