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

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

#151

Post by TheNewsIsHere » Mon, Feb 17, 2025, 6:03 PM UTC

ethbr1 wrote: post #97

thecleaner wrote: post #85

Earlier quoted context omitted.

> it also builds self-esteem. Well crafted dig.

Imposter syndrome is fueled by colleague deification. It's easy to view smart coworkers as superpeople... until you're reminded that they, on occasion, make dumb human mistakes too.

This is a fantastic insight.

I used to suffer from imposter syndrome significantly. It helped to see the mistakes others made which anyone could have made. It also helped to have my own good ideas and talent explicitly acknowledged. Learning to not take criticism personally and own your own mistakes also helps to rob imposter syndrome of its power because it demonstrates to others that you can be forthright and self aware, and that helps build trust.

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

#152

Post by orochimaaru » Mon, Feb 17, 2025, 6:06 PM UTC

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…

Agree. Also, not be judgemental about the state of things as in "which moron did this". Approach it from a point of understanding and respect rather than criticism. There are multiple reasons why the code base and tooling around it are in the crusty old state. They are usually decisions that engineers or middle management had no control over.

I've been with my company for a while now. Too often I find someone come in with the "this is trash and all of you are idiots" mentality. I've typically not been keen to help such folks. They usually soon ask for rescue from the very same dumpster fire they created.

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

#153

Post by samus » Mon, Feb 17, 2025, 6:08 PM UTC

kerkeslager wrote: post #108

thecleaner wrote: post #85

Earlier quoted context omitted.

> it also builds self-esteem. Well crafted dig.

Sure, but if there's anything I've learned from working on legacy software, it's that I don't know why the code was written the way it was. I'm not the only smart person to work on a codebase, and it's more common that another smart person did what they did for a reason, than that I'm a genius who knows better than they did.

Sometimes there were reasons, but they were not necessarily good ones. Like these:

- time pressure, leading to just making it work and not caring about edge cases, which were bolted on later. Or maybe never at all. And naturally, there is no useful testsuite.

- the prototype ended up in production

- a refactoring happened, but there was no follow-up into other areas of the code base

- features changed, but the code is still influenced by the necessities of the old way it worked. Similarly, for changing technical circumstances

- code was copy-pasted or was worked on by too many people

- code was herded too long by the same person and now, to put it nicely, bears traces of their bespoke coding style

Chesterton's Fence is still very relevant, therefore I'd still err on the side of writing a lot of high-level tests before touching anything.

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

#154

Post by lolinder » Mon, Feb 17, 2025, 6:09 PM UTC

marcinzm wrote: post #130

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.

> 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. Using the latest framework improves their future job prospects. Whatever company they work for will lay them off in a split second and wo…

> So why should they care about the long term of a project?

Because your future networking potential—and therefore future job prospects—depends on being liked by your peers, who may not choose the same moment of departure as you would. Follow standards and work towards long-term maintainability not because you see yourself at the same company in 2 years but because your coworkers might see themselves there and you want them to like you and feel good about recommending you to their network.

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

#155

Post by calebpeterson » Mon, Feb 17, 2025, 6:09 PM UTC

svachalek wrote: post #27

calebpeterson wrote: post #8

I once had a manager that was fond of saying: > Experience is what you get when you don’t have any. The only better experience than working on a legacy codebase is working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions.

"You either die a hero or you live long enough to become the villain"

Never thought of that in the context of software projects. It works really well!

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

#156

Post by neilv » Mon, Feb 17, 2025, 6:12 PM UTC

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…

Also, some companies and teams do versions of this, officially or unofficially.

One pre-FAANG tech company I worked had a policy (known among the local schools) that each new hire has to "pay your dues" on grunt work, before you get to do fun/glamorous work. That kinda worked for them.

A problem they had was that they were doing desktop development in C and C++, which, among other purposes, had to ship software bundled with new brand-name PCs (so not necessarily able to bugfix over Web later). The real problem was that very few new grads are minimally competent at production-grade C or C++. But, in early Web years, the company couldn't hire enough experienced software engineers to relocate to a college town. So they had to try to train and retain local grads of a top CS program. That might've been part of the thinking behind "pay your dues"... before you get to make rookie mistakes with greenfield.

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

#157

Post by AtlasBarfed » Mon, Feb 17, 2025, 6:13 PM UTC

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…

... just don't make the mistake of documenting too well :-)

Developers need to realize that AI means that a lot of coddling our profession used to get is going away. Employment has always been a tenuous relationship with a fundamentally sociopathic entity, but things will be getting a lot worse in the future.

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

#158

Post by hollywood_court » Mon, Feb 17, 2025, 6:13 PM UTC

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.

I find this to be true in many aspects of life. Just watching how other people do things is often a huge self-esteem boost for myself.

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

#159

Post by drakonka » Mon, Feb 17, 2025, 6:15 PM UTC

I started my career working on a large legacy project. It was the best learning experience, and super interesting. It certainly did not make me hate legacy projects. Work was like an investigation into who did this weird thing and when and for what reason - and there was usually a good reason. Then detangling if that reason is still valid today, or if we have time to refactor the thing appropriately to rewrite it in a different/better way, or how we can solve this obscure bug without breaking five other usages, etc. And doing all that as elegantly and non-disruptively as possible with hundreds of people on a tight timeline relying on the codebase. It was an extremely satisfying challenge.

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

#160

Post by sibeliuss » Mon, Feb 17, 2025, 6:16 PM UTC

where-group-by wrote: post #26

I unironically like working on legacy projects. It's good to know it stood the test of time and my efforts spent on it won't be wasted, because it is unlikely to be dropped. Of course this assumes there is a way to introduce improvements at all. Just keeping the lights on isn't as satisfying.

I love it too! So much to see / do / improve