Live data from Hacker News

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

infobip.com

291–300 of 431 posts

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

#291
Everybody hates working on legacy projects, myself included.

I am proud that I am a part of a team that uses most of the best practices

Speak for yourself... I'm the exact opposite. Then again, outside of work I fix and maintain other physical systems which are many decades old, some close to a century, so perhaps that changes the perspective. I see so many in the software industry cargo-culting "best practices" dogmatically, creating constant churn via useless trendchasing, that they keep reinventing - badly - new ways to do the exact same things as before.

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

#292

Earlier quoted context omitted.

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.

A quip I'm often fond of that I think I stole from an old web comic eons ago

"I can't ever get even with past-me, and I'm already on thin ice with future-me"

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

#293

Earlier quoted context omitted.

When you're on a reasonably large legacy project that's a pipe dream. One of the old specialty C ERPs I've worked on has literally buried more than 3 (the ones I know of) "great Ruby rewrites". There are just _so many_ features, that the newcomers always ended up on the chopping block after 5-10 years and before they could achieve real customer traction. The old project just ended up getting some more interface fixes…

Yep. The only possible way to rewrite such projects is to do it gradually, piece by piece. It is also important that the refresh happens from within and is led by those who understand the legacy codebase and, especially, the business requirements it fulfills. No way can an external team do something like that. Being given project description "it must do everything the legacy project does, plus these new features" doe…

I just spent 5 years of my life building such a system. Then we were asked to do it again (a refresh of the refresh, if you will) and everyone marvels that suddenly we can do everything both fast and correct.

Well, we just spend 5 years training the team on how to build the old refresh, and now the new refresh can be done properly.

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

#294

Earlier quoted context omitted.

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

Conversely, reading through my own code from ancient history (>3 months ago) is both humbling and terrifying :D

This happens to me all the time, but mostly with work code.

I'm under pressure, I have to deliver, things get rewritten many times, edge cases are found and fixed in production after they slipped through multiple qas but need to be fixed instantly or we lose money.

It happens.

But personal code? I am almost always proud of my work. It shows in general I was not under pressure and enjoying building it.

Even my code from the first year of programming, it shows it was made to make a point in writing a nice solution.

I may cringe at times, but still proud.

Context does matter, and code quality is more often than not a byproduct of our emotional state rather than skills.

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

#295
Does replacing a completely unsalvageable legacy project count? It's done and dusted at this point, but I replaced a C/PHP codebase written by an IP-trolling freelancer who kept project sources as his personal IP, won back after a legal settlement. It was all deliberately obfuscated single letter naming and misdirected logic paths, along with a heavy reliance on global state. Investigating any individual part was manageable, thankfully, but I still had to unwind a great many useless stack frames and reverse-engineer several intense procedural bit-logic algorithms.

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

#296

Earlier quoted context omitted.

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.

A quip I'm often fond of that I think I stole from an old web comic eons ago "I can't ever get even with past-me, and I'm already on thin ice with future-me"

I'm doing my best to prevent myself from being on thin ice with my future-me.

I posted recently about how I divorced not too long ago. I'm in an apartment now (for the first time in 16 years) while I stack up cash to build a new house.

I always think I'm not making any progress but then I see my next door neighbors ordering DoorDash 15+ times per week, and I realize that I'm doing pretty damn good for myself.

Or I walk by the mirror and think about how I've neglected my lifting for the past 6 months while I finished up this SWE degree. But I'll see those same neighbors struggle to walk up the stairs and I again realize that I'm making some awesome choices compared to those two folks.

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

#297

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?

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 differently", "thank you for not taking the feedback on the code personally, the result is a better codebase for everyone"). And do the same with them whenever they imitate any of that, without dwelling on it any further or treating it any differently.

TL;DR: Normalize healthy dynamics by example.

Obviously just my 2c and every case is different etc.

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

#298

Earlier quoted context omitted.

tell me you don't have ADHD without telling me you don't have ADHD

For what it's worth, I find it much easier for my ADHD to debug and improve existing code than to greenfield - it's actually interesting . Debugging is like a detective's work with small dopamine hit at each step of unraveling the situation and a huge reward once you finally grasp it. It's best to do on someone else's code, so you don't get too frustrated with your past self ;) Greenfielding provides some rewards too…

That is a good point and I'd likely be good at that.

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

#299
post #256

Earlier quoted context omitted.

For what it's worth, I find it much easier for my ADHD to debug and improve existing code than to greenfield - it's actually interesting . Debugging is like a detective's work with small dopamine hit at each step of unraveling the situation and a huge reward once you finally grasp it. It's best to do on someone else's code, so you don't get too frustrated with your past self ;) Greenfielding provides some rewards too…

On the other hand, the infrastructure variant of this is the exact opposite. Trying to figure out if something specific is in use and who uses it or if someone just clicked around in your cloud console and forgot about it is the worst. There's only so many ways I can be inventive in building proxies to measure usage. We sometimes get incidents that things someone remembers should exist do not work, only to find out t…

Tell me you use AWS without telling me...

... I literally had a multi month ticket open to track down an expense for something I either never used or only used once which ended up being a load balancer or some crap

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

#300

Earlier quoted context omitted.

tell me you don't have ADHD without telling me you don't have ADHD

In a world where everyone has ADHD, I welcome these few non-ADHD aliens.

Never said I didn't!
Post reply on HN