3 ms·

Everywhere I have worked has about the same average engineer tenure (between 1.5-2 years), but had massive differences in code quality. Also, super-long-tenure

Everywhere I have worked has about the same average engineer tenure (between 1.5-2 years), but had massive differences in code quality. 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

goalieca 6y ago
> 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. Haha. So true. Isn’t the adage you’re either changing or dying?
kevstev 6y ago
That's an interesting take- how long do you think it takes before an average tenure becomes detrimental? Honestly, I haven't worked in environments where you have people there for 10 years, and even 5 is a real rarity in my experience (I am getting close to doing this for 20 years now as well). Its much more common to have the average turnover be about 2 years, and in most places I have worked, it takes about that long before you start to get really good- at least to the point where someone asks you to make a change, and you can more or less visualize what changes need to be made in what places and have a very good idea of how long it will take.
hinkley 6y ago
> The wrong type of super-long-tenured engineer 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.
MattGaiser 6y ago
I get the problem with the guy who was there 20 years, but every project I have worked on has not made it to the end with the same engineers as those who started on the team. 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.
mywittyname 6y ago
> 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. 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.

goalieca 6y ago

kevstev 6y ago

That's an interesting take- how long do you think it takes before an average tenure becomes detrimental? Honestly, I haven't worked in environments where you have people there for 10 years, and even 5 is a real rarity in my experience (I am getting close to doing this for 20 years now as well). Its much more common to have the average turnover be about 2 years, and in most places I have worked, it takes about that long before you start to get really good- at least to the point where someone asks you to make a change, and you can more or less visualize what changes need to be made in what places and have a very good idea of how long it will take.

hinkley 6y ago

> The wrong type of super-long-tenured engineer 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.

MattGaiser 6y ago

I get the problem with the guy who was there 20 years, but every project I have worked on has not made it to the end with the same engineers as those who started on the team. 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.

mywittyname 6y ago

> 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. 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.