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

401–410 of 431 posts

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

#401

Post by Cthulhu_ »

fjjjrjj wrote: post #24
namdnay wrote: post #19

Earlier quoted context omitted.

And the only better experience than "working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions" is working on a second greenfield project long enough to see that drastically overcompensating for all the bad things from the first one is not the right solution either :)

And the only better experience than that is killing a new greenfield project before it gets to production because the old software was good enough and the problems were organizational in how the software was being used.

I wish this happened tbh. I've seen one where the greenfield (Scala, AWS, etc) is still living alongside the old good enough software they went back to (C# / .NET) ten years on.

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

#402

Post by Cthulhu_ »

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…

The challenge there is that "legacy" codebase are just so much slower; you spend more time figuring out what needs to be done and how, than just writing code like in a greenfield project. And everyone knows the latter is just so much more fun.

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

#403

Post by juangacovas »

westoque wrote: post #177

i've worked on many legacy code bases and i think an underrated skill that you need is courage. courage to be able to push changes you think could be breaking changes but always be optimistic that you to be able to fix as soon as possible. tests are ideal, but not everyone has 100% coverage. sometimes you just have to trust your gut and do diligence and push the change. don't be scared to push something because you d…

Agree. But you need confidence on being able to debug / log / fix / revert, so having a strong knowledge of some of the parts is mandatory (i.e. server if it's web-dev, etc).

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

#404

Post by Cthulhu_ »

bdelmas wrote: post #394

I would also say: you are not a senior engineer until you’ve worked on a repo with the next kool aid tech where the repo’s owners left the company.

Just because it's the latest kool aid tech, doesn't mean it's legacy; it often feels like it becomes legacy as the people pushing it leave.

But this is why technological choices need to be taken with care, and if you're in a managerial position, you should only agree on using new tech if there's dedication / guarantees for the ones pushing it, a healthy labour market, or budget to provide training for people that don't know it yet.

And that's why so much is still 'boring' languages like Java, .NET, PHP and Javascript instead of Rust or what have you.

I'm a Go fan though and will exclude that, as IMO Go is by design easy to learn by anyone.

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

#405

Post by Cthulhu_ »

wesselbindt wrote: post #326
amarshall wrote: post #274

I usually say that when people say “legacy project”, it’s really “code I either don’t understand or don’t like”.

I specifically mean code not covered by automated tests. And this almost always falls in the dislike/misunderstand pile for me, but not conversely.

I'd argue that even with automated tests it can be considered legacy. Easier to change things if the test coverage is comprehensive enough, but I've yet to find a project like that, even the ones I built myself.

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

#406

Post by cnity »

dwaltrip wrote: post #375
chasd00 wrote: post #309

Earlier quoted context omitted.

> Be vulnerable yourself? Being vulnerable to an insecure, arrogant, asshole just means becoming a doormat. Ask anyone from an abusive relationship.

Being vulnerable is not the same thing as not having boundaries.

Exactly this. Strong back, soft front.

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

#407

Post by devnullbrain »

nickysielicki wrote: post #376
itronitron wrote: post #73

Earlier quoted context omitted.

"checkout project, reformat all source files, commit"

Just to be clear, the argument for this has nothing to do with how the code looks and has everything to do with how you can swallow a pill, once, and in exchange you get clean rebases forever. You can hide the commit from blame consideration.

I've seen changes like this drag out over a year because the product had so many permutations that thoroughly testing any change was an exercise in futility. I've also seen changes like this fail to happen just due to a lack of cultural desire to make things happen.

The first one is more forgivable - sometimes that's just the problem space. But neither of them are conducive to fulfilling working environments.

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

#408

Post by breakfastduck »

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…

> 3. your green field project growing into legacy project.

This is always a fun one...

"Who wrote / designed this garbage... Oh wait, it was me"

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

#409

Post by protonbob »

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…

Legacy code is code without tests. Doesn't matter if it's new or old.

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

#410

Post by schmorptron »

chasd00 wrote: post #311
philipov wrote: post #125

Earlier quoted context omitted.

Boredom is in the mind, not the task. Things aren't boring, people are. An important type of intelligence is the capacity to find what's interesting about a task that others lack the imagination to see. One needs to be able to create their own interesting solutions rather than expecting them to be handed down on a plate.

> find what's interesting about a task that others lack the imagination to see. word of warning from an old guy, don't create problems for yourself when you don't have to. Turning something boring into something interesting can have painful consequences down the road.

How?
Post reply on HN