Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You're not a senior engineer until you've worked on a legacy project (2023)

infobip.com

Post reply on HN
Print view View original

261–270 of 431 posts

Re: You're not a senior engineer until you've worked on a legacy project (2023)

#261

Post by jonahx »

shermantanktop wrote: post #253
jonahx wrote: post #229

Earlier quoted context omitted.

> The time always comes when a new leader and their lieutenants come into the org and prioritize new features over maintenance, at which point your moat is null and void and you’re on borrowed time. The "on borrowed time" is an odd conclusion. When someone takes over, it's typically a priority change ("We want everyone working on new projects, just freeze this old stuff") rather than some kind revenge path against an…

It does happen that the new leader ends up saying out loud "everything we have is terrible," which is easily taken as "everyone who worked on it is terrible." And to be fair, sometimes that's true. And sometimes it's not true but the leader wants to bring over their crew of loyalists and needs to make room somehow. Long-term ownership and careerist jockeying don't go well together.

Ah, that's definitely true. But that feels like an orthogonal concern to you being an existing dev working on legacy stuff vs greenfield stuff... unless the new boss likes the greenfield stuff for some reason. What you are talking about is more of an ever-present possibility of "new management fallout" in almost any field.

Re: You're not a senior engineer until you've worked on a legacy project (2023)

#262

Post by serial_dev »

ilitirit wrote: post #227

Hard to disagree. I can usually tell what type of type of experience devs have by the snarky, dismissive responses I've gotten on various internet forums over the last two decades. e.g. "Oh but you would never have this problem if you performed proper code review" - Random_Rockstar_Dev_254 However not all legacy projects are bad to work on. If they're decently developed, then often you'll find that most of the pain i…

I see that going through these three kinds of projects let me grow as a developer:

1. green field project 2. other people's legacy project 3. your green field project growing into legacy project.

You can learn so much from each of these, but to me the most eye opening experience was our green field project growing into a project with more and more developers.

You could learn so much about others, some were very arrogant, went on constant refactoring mission only to mess up everything. If for some reason, I couldn't check what they did, usually, I had to come in and fix their stuff, but sometimes the only person knowing about the edge case was me, so I just left it "messed up".

Others tried to understand why the system ended up this way, some accepted it, while the best actually improved the system by looking back and recognizing the simplicity hiding in the mess.

Re: You're not a senior engineer until you've worked on a legacy project (2023)

#263

Post by mianos »

shermantanktop wrote: post #253
jonahx wrote: post #229

Earlier quoted context omitted.

> The time always comes when a new leader and their lieutenants come into the org and prioritize new features over maintenance, at which point your moat is null and void and you’re on borrowed time. The "on borrowed time" is an odd conclusion. When someone takes over, it's typically a priority change ("We want everyone working on new projects, just freeze this old stuff") rather than some kind revenge path against an…

It does happen that the new leader ends up saying out loud "everything we have is terrible," which is easily taken as "everyone who worked on it is terrible." And to be fair, sometimes that's true. And sometimes it's not true but the leader wants to bring over their crew of loyalists and needs to make room somehow. Long-term ownership and careerist jockeying don't go well together.

My recent experience is that a lot of the system was not as good as it could have been because it's a hard problem. The company got bought out and all the new bosses come in and say all the existing code and way things are done is crap. Then, a year later, with everyone sacked and new people brought in, once again, these guys say the same thing and promise they are the top guns to fix it all up. I just checked out on the third round.

Re: You're not a senior engineer until you've worked on a legacy project (2023)

#264

Post by lcfcjs6 »

itronitron wrote: post #66
joezydeco wrote: post #20

As an embedded engineer in a new position I always volunteer to take up an old crusty legacy product that nobody else wants to touch. It's a quick education into how the company approaches projects and all the ghosts they had to fight along the way. All the business logic is there, and sometimes it's even documented. And once you have a semblance of knowledge about how the thing works and how to make fixes, you've bu…

Additionally, reading through other people's code is educational and it also builds self-esteem.

Unless the "other peoples code" actually turns out to be yours that you wrote years ago, and forgot about :D

Re: You're not a senior engineer until you've worked on a legacy project (2023)

#265

Post by jaggederest »

milesrout wrote: post #216
bgribble wrote: post #214

There's no hurt feelings like the hurt feelings of a junior engineer, who has spent the last year kvetching about how much they hate working on legacy junk, hearing someone else refer to one of THEIR projects as "legacy junk". Any code that's old enough to have its first birthday party is "legacy", which means that "legacy" is a completely useless category. Anyone calling anything "legacy" is generally just showing t…

1 year old code is not legacy. Legacy is a useful category. COBOL is legacy. Maybe it is unclear exactly where to draw the line but if that were a valid reason to discard conceptual categories we wouldn't have any.

I like the definition from "Working Effectively with Legacy Code", Michael Feathers says legacy code is code without tests.

Re: You're not a senior engineer until you've worked on a legacy project (2023)

#267

Post by rectang »

spike021 wrote: post #136
itronitron wrote: post #66

Earlier quoted context omitted.

Additionally, reading through other people's code is educational and it also builds self-esteem.

ironically most people can say the same about coming back and reading their own old code

"No wonder that didn't work."

Re: You're not a senior engineer until you've worked on a legacy project (2023)

#268

Post by ChrisMarshallNY »

serial_dev wrote: post #262
ilitirit wrote: post #227

Hard to disagree. I can usually tell what type of type of experience devs have by the snarky, dismissive responses I've gotten on various internet forums over the last two decades. e.g. "Oh but you would never have this problem if you performed proper code review" - Random_Rockstar_Dev_254 However not all legacy projects are bad to work on. If they're decently developed, then often you'll find that most of the pain i…

I see that going through these three kinds of projects let me grow as a developer: 1. green field project 2. other people's legacy project 3. your green field project growing into legacy project. You can learn so much from each of these, but to me the most eye opening experience was our green field project growing into a project with more and more developers. You could learn so much about others, some were very arrog…

> very arrogant

My experience, is that this is usually a defensive shell around personal insecurity.

On the outside, it looks the same, but internally, insecure people can be reached (not easy), whereas truly arrogant folks (a lot more rare than you might think) cannot.

My experience is that most difficult people are actually decent folks, that we can enjoy working with, but we need to adjust to them, and they need to adjust to us.

Re: You're not a senior engineer until you've worked on a legacy project (2023)

#269

Post by lexicality »

duxup wrote: post #79

I've run into a few engineers, very capable people and I'd be happy to work with them, but their experience was limited to very structured environments. It sounded like they were in well organized organizations. One in particular worked for a sort of "side ways competitor". They were horrified to hear about my deploying a fix all by myself, no review, for a legacy product that really didn't have a good testing enviro…

Deploying straight to production? Eh, we've all been there. It happens.

No review though? Aaaa

Re: You're not a senior engineer until you've worked on a legacy project (2023)

#270

Post by nibab »

Most engineers will scoff at the idea of patching up a legacy project if they see the slightest deviation from “best practices”. They will slam their fists on the table and claim that management keeps “piling on tech debt”. They will argue for a total rewrite and dismiss any concern of said rewrite taking years because “this is what it means to have high standards and best engineering practices”. They wear this as a badge of honor and frame the conversation as a question of morality and purity, in which they of course have the upper hand since they are not motivated by petty business concerns such as profit.

Engineers that refuse to acknowledge constraints, whatever the nature of those constraints may be, are not engineers. At best they are ideologues, at worst they are just incompetent. The most pathetic thing you can do is just continuously deny the laws of physics and reality, because it doesn’t suit you at some ideological level.

Truly elegant solutions are those that account for all constraints in the simplest, most concise way. It is those that do more with less.

Post reply on HN