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

351–360 of 431 posts

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

#351

Post by recroad »

lmm wrote: post #344
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…

As long as all the layers are actually being replaced. A bit of each pattern in each layer makes for a mess.

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

#352

Post by throwaway2037 »

__turbobrew__ wrote: post #349
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 di…

The real miracle is when you see a teammate who can still perform well under these insane constraints. I have seen it a couple of times in my career. They still find a way to write "good enough" code or write "good enough" docs. It was inspiring.

I would say the same about a sales person who can still manage to have a great year even when the (their) market is cratering. Again, I have seen it a few times, and it always impresses me... watching them pull a rabbit out of the hat!

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

#353

Post by lmm »

recroad wrote: post #351
lmm wrote: post #344

Earlier quoted context omitted.

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

As long as all the layers are actually being replaced. A bit of each pattern in each layer makes for a mess.

You don't and can't fully replace each layer, at least not in order - you should expect to have three or four ways of doing things in the codebase, that's just the reality of large old codebases. It still beats having your whole codebase be stuck on the oldest of those three or four ways.

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

#354

Post by ChrisMarshallNY »

karparov wrote: post #279
ChrisMarshallNY wrote: post #268

Earlier quoted context omitted.

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

> but internally, insecure people can be reached (not easy) How? Any advice?

Well, I have found that finding things in common with people is usually a great segue into improving relationships. Learning more about them, also helps a lot. Find the things they care about. It can be surprising.

I have learned to make the first move, myself. It doesn’t work, if I insist on them doing it. Also, I need to accept their value system. If they truly have values that I can’t deal with, I usually “compartmentalize” things, so I don’t deal with them, in those areas.

I’ve spent my entire adult life, getting along with people that don’t play well with others. I haven’t always been able to get through, but I’ve had more success than failure.

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

#355

Post by blululu »

m463 wrote: post #305
ChrisMarshallNY wrote: post #268

Earlier quoted context omitted.

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

> > very arrogant > a defensive shell around personal insecurity. could just be despair and honesty. I was reading about the kindle os here and wonder how many people are facing giant hairballs in their professional life. > the Kindle’s OS is a mess of Java, Javascript, Lua, Native and React Native code. ... > The Kindle runs stripped down Linux with a React Native frontend along with Java backend applications. https…

I literally laughed out loud on the bus reading the linked file. The infographic is all too true.

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

#356

Post by intrasight »

Then I became a senior engineer pretty early - as my first job was working on nuclear power software. We had code in Fortran that NOBODY was allowed to edit. But lots of other legacy Fortran was up for grabs.

Oh, and my favorite software tale is when we turned on the new software in the control room and the first thing the plant manager said when he looked at the new digital instrumentation was "that can't be right".

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

#358

Post by Tainnor »

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.

There's a tradeoff here too. If your codebase was started in Java 6, I dearly hope you won't continue to write code in that style anymore for new code.

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

#359

Post by alexvitkov »

ryukoposting wrote: post #278
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.

I used to work for a company where the American devs indented with 4 spaces, and the German devs indented with 2 spaces. When they finally decided to standardize the code style across the company, they couldn't agree on indentation. So, they compromised and everyone started indenting with 3 spaces. I swear I'm not making this up. I worked on one codebase that lived through that transition, and some source files would…

Probably the best argument for tabs I've seen so far.

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

#360

Post by alexvitkov »

bornfreddy wrote: post #175
itronitron wrote: post #73

Earlier quoted context omitted.

"checkout project, reformat all source files, commit"

Sure. Of course you can't commit to the main branch and your commit will never pass code review (which is a requirement for merging), let alone the automated tests in CI that apply formatting and fail if anything is not formatted as it should be. These safeguards save so much time that there should be no excuse for not having them.

Not wanting pipelines to fail because someone put an extra space after the line, or because someone's text editor didn't put a new line at EOF, or put a unicode BOM or whatever is a pretty good reason not to have this "safeguard".
Post reply on HN