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

341–350 of 431 posts

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

#341

Post by lmm »

kalaksi wrote: post #304
marcinzm wrote: post #198

Earlier quoted context omitted.

It's not hatred. It's self-interest. The very heart of capitalism. A rational response to incentive structures. You're the one sacrificing your own self-interest for pride and are upset that others refuse to do so. edit: And I get it, I don't optimize my own career like this, focusing more on what I enjoy to work on at the moment. But I don't begrudge people who do optimize nor do I claim to be better than them. If a…

"More rational" is subjective. There are values and incentives, other than money and specific kinds of self-interest, that can bring satisfaction and joy. And why should someone be respected if they are intentionally making others lives more difficult like that. That's just hypocritical.

Moving to a new framework that will look good on everyone's CV isn't making people's lives more difficult, quite the opposite.

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

#342

Post by hnthrow90348765 »

codegeek wrote: post #47

Legacy or not, I don't consider anyone really senior unless they have spent building and more importantly maintaining/fixing a system at least for 3-5 years at one single place and have done this at least 2-3 times across different companies. We all know that it is a lot easier to start a new/greenfield project with shiny tech etc. It is a lot harder to maintain especially once it is 2-3 years old and in production w…

That's nothing, I don't consider anyone a real senior unless they've maintained something for 10 years!

But seriously, everyone tries to move these goal posts. We still have no good idea.

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

#343

Post by urda »

cpeterso wrote: post #190
urda wrote: post #92

For readers, programmers, and engineers stopping in here asking "ok what can I do to better myself here?" I really recommend "Working Effectively with Legacy Code" By Michael C. Feathers. It is a top notch read, and helps newcomers (and vets alike) approach these legacy systems.

Marianne Bellotti’s “Burn It With Fire: Manage Aging Computer Systems (and Future Proof Modern Ones)” is another good book about working with legacy systems, though its focus is more about managing system evolution and modernization than specific code techniques.

Adding that to my list thank you very much.

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

#344

Post by lmm »

seanalltogether wrote: post #31

You're also not a senior engineer until you've been forced to adopt the coding style and practices of that legacy project. A lot of younger developers like to come into a new project and slap on the latest frameworks or coding practices that they've picked up recently, without acknowledging that breaking the standards of the project lead to higher mental load to maintain that code over the long term.

> breaking the standards of the project lead to higher mental load to maintain that code over the long term.

Nah. Over the long term the lava layer pattern is the only way to stop the mental load of the project from growing indefinitely. You will ultimately have to keep up with modern development practices, because keeping everything on standards from 2010 will ultimately be even worse, and the longer you leave your migrations the more painful they will be.

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

#346

Post by jamesfinlayson »

FridgeSeal wrote: post #281
kvirani wrote: post #272

Earlier quoted context omitted.

Yes! #3 is key to making one humble

Nothing quite like suffering through your own decisions to make the lesson stick!

Ugh, too right. Going through that made me appreciate working on a legacy project later on, because I could improve things rather than watching things get worse.

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

#347

Post by Tainnor »

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

Yes, and the flip side to this is the other kind of senior that you mention in your comment: the one that refuses to believe that things can be done better.

It's hard to find the right balance between wanting to write better code and pragmatically dealing with the realities of a huge, messy legacy codebase with tons of bad decision - you can't fix everything (and certainly not at once), so you have to choose your battles wisely.

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

#348

Post by mannyv »

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…

You can learn from anything. A "legacy" product is one that works, but is generally hard to maintain.

"Why is it hard to maintain?" is a question every architecture person should be able to answer...especially after digging into some large, old piece of software.

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

#349

Post by __turbobrew__ »

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

I see this constantly on HN and have had to learn to not engage with those conversations. It is like some people have never had to run a project under any sort of external constraints like head count restrictions, layoffs, inheriting a system which you didn’t write, or awkward organizational structures.

Some will scream until their ears bleed that there is only one optimal way to do things and if you aren’t doing things that way you are a incompetent chump — totally disregarding the reality that people have to work with.

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

#350

Post by ChrisMarshallNY »

godelski wrote: post #327
nothrabannosir wrote: post #297

Earlier quoted context omitted.

Not OP but: destigmatize admitting failure (by doing it yourself), normalize admitting ignorance and asking questions (by doing it yourself), find someone they look up to and demonstrate healthy collaboration dynamics with that person, explicitly labeling things which you value, as they happen (e.g. "thanks for saying you're not sure, or I would have thought that you were and it would have made me value the statement…

To add (some overlap): - Share credit and be generous with sharing - It is better to error in the direction of over sharing credit than under sharing (taking credit for yourself) - Slow down, say "I don't know" (good to follow up with "but I'll find out") - Saying "I don't know" is often a better answer than guessing - Guesses are fine, but should be prefaced and be clear that you speculate BUT will follow up and ver…

One of the best ways for me to learn, is to explain.

That's a very old pattern.

That's one of the reasons I write stuff that no one reads[0]. Writing up a technique forces me to research it, and break it down into its simplest components.

[0] https://littlegreenviper.com/miscellany/

Post reply on HN