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

71–80 of 431 posts

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

#71

Post by raihansaputra »

cess11 wrote: post #49
breckenedge wrote: post #35

Earlier quoted context omitted.

It isn’t just younger developers doing this, nor even inexperienced ones. I’ve seen a ton of experienced people do this to themselves and their teams, mostly it seems to be able to pad their resume, but some honestly believe newest and shiniest is best.

Juniors with tons of experience aren't very uncommon.

The way i've seen it is Junior/Senior as a label of wisdom/engineering acumen and experience (not just a title) is not directly correlated to years of experience. Some people just have the same year of experience/level repeated 3-5 years. Some "Junior" with 1 YoE can come away with learnings some seniors never get in their careers. Not wholly their own fault, but it's a fact.

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

#72

Post by [deleted] »

powerhugs wrote: post #45
tobr wrote: post #32

Earlier quoted context omitted.

Haven’t you also often made a moat between yourself and doing literally anything else more interesting at the company?

Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy. Here, parent explained in detail how to get stuff done, management very happy and secure their position for years to come.

[deleted]

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

#73

Post by itronitron »

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.

"checkout project, reformat all source files, commit"

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

#74

Post by stego-tech »

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…

Small, but not insurmountable. The time always comes when a new leader and their lieutenants come into the org and prioritize new features over maintenance, at which point your moat is null and void and you’re on borrowed time. I’ve yet to find a way to build a moat that withstands that level of hostility without actively harming the organization in the process.

I’d love to hear how others deal with this inevitability.

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

#75

Post by dlisboa »

Kuraj wrote: post #54

It's funny because 90% of my experience has been legacy projects, and the greenfield projects for me were the hardest, because it's really hard to organize as a team to build something from ground up, not kill each other with shovels in the process, and not introduce technical debt early on that will be impossible to pay off down the road. When joining a legacy project, most of the hardest work has already been done…

There's also much more technical pressure on a greenfield project mainly because if it turns bad it's "your fault". There's no legacy to blame, no excusing bad choices (you made them!). It is part of the responsability but if and when it goes sour there's a bigger feeling of impostor syndrome than on a legacy project.

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

#76

Post by ambicapter »

mytailorisrich wrote: post #64
powerhugs wrote: post #45

Earlier quoted context omitted.

Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy. Here, parent explained in detail how to get stuff done, management very happy and secure their position for years to come.

A good way to secure your position is to be the go-to expert for a product with many years of life ahead of it. Fixing stuff on a legacy product may make management happy but if that product is discontinued next year then you haven't accrued technical expertise valuable to the company (but you may have built a reputation as a fixer and quick learner). So, as usual, it is a balancing act. Edit: this is my perspective…

It is indeed, but at the same time, things that have stuck around tend to stick around, and hot new things have a way more variable longevity score.

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

#77

Post by ninetyninenine »

donatj wrote: post #56
tobr wrote: post #32

Earlier quoted context omitted.

Haven’t you also often made a moat between yourself and doing literally anything else more interesting at the company?

Depends on your definition of interesting? I find improving established code of far more interest and reward than greenfield. Coming to understand what a person was thinking while building something is fascinating. My updates are tangible life improvements to real human beings. That interests me, at least. Greenfield, I have the incredibly stressful job of making all the major architectural mistakes people will compl…

I’m interested in finding the patterns and architecture that prevents those mistakes. I think I’ve found it already.

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

#78

Post by joezydeco »

mytailorisrich wrote: post #64
powerhugs wrote: post #45

Earlier quoted context omitted.

Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy. Here, parent explained in detail how to get stuff done, management very happy and secure their position for years to come.

A good way to secure your position is to be the go-to expert for a product with many years of life ahead of it. Fixing stuff on a legacy product may make management happy but if that product is discontinued next year then you haven't accrued technical expertise valuable to the company (but you may have built a reputation as a fixer and quick learner). So, as usual, it is a balancing act. Edit: this is my perspective…

I'm referring to embedded, not web dev.

When times get tight the new projects get shitcanned and the 10 year-old cash cow design gets the promised new features.

One crusty project I worked on was a legacy control board for a piece of restaurant equipment. The customer, the company that built the actual machine, had been building this product for 40 years. It had been through two PCB redesigns and two different microcontrollers, but the logic was tried and true and had to survive. A port of the project from 6800 assembly to C had completely gone off the rails and the contractor was dumped. All it took was a 20-opcode fix to a routine that the contractor just couldn't grok.

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

#79

Post by duxup »

I've run into a few engineers, very capable people and I'd be happy to work with them, but their experience was limited to very structured environments. It sounded like they were in well organized organizations.

One in particular worked for a sort of "side ways competitor". They were horrified to hear about my deploying a fix all by myself, no review, for a legacy product that really didn't have a good testing environment. It was inconceivable to them.

On the other hand, not long after, our organization of 4 coders put out a better product in 3 months than their massive organization did in 18 ... and using that some "inferior" legacy systems that just so happened to be better suited to the job than some fancy new framework.

Post reply on HN