Live data from Hacker News

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

infobip.com

241–250 of 431 posts

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

#241
post #238

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…

It feels like you're just finding other ways to describe people who are senior in title only which is far too common. Any senior that uses their title to justify a 'you can't tell me way to do attitude, is a senior in title only. I think the term is the issue. Senior development means something more intrinsic than it does in other title, like a senior manager. I think what we're attempting to define is something clos…

> I think what we're attempting to define is something closer to seasoned developer.

I'm fully aware of that, which is why "Senior" is in double-quotes, but experienced (aka "seasoned") is not. My point is that you can be seasoned at delivering bad products. The point about seniority just speaks to tenure at a company. Sure, you can join a company as a "Senior dev", but that's not quite what I'm referring to here. One would think that they would be exposed during the interview process, but alas, we all know that's often not the case.

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

#242
post #203

Earlier quoted context omitted.

As a senior engineer your job is to take on the unglamorous hard problems, both technical and organisational, that are holding the team back. Doing this, and being seen to do it, early-on in your time with an employer will be somewhere between appreciated and expected.

If you do this you should also be good at story telling. Not working on the new things, but making sure the core business running, is often times looked down upon in my experience. Most leaders will see the greenfield project move fast and wonder why the established and "complete" software moves slower.

Yes, thats a very good point. And one that I learned to my cost in a previous job.

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

#244

My first "software engineering" scale project was working on a existing massive 10 y.o js pub/sub and java templated webapp. Taught me why typed languages are valuable, why I should never listen to PMs, why I should be humble, why estimates are impossible but sort of important, and why long feedback loops anywhere in the entire process (including compilation) are productivity killers, along with not having an isolate…

Learning to never listen to PMs sounds like the opposite of being humble

I was being a bit facetious with that one. In retrospect, I would have pushed back quite a lot more, but for different reasons than I did when I was in my early twenties. PMs are there for a reason, but the realistic pace that a given change can be expected to be made on this type of software, especially as a new team member, is a lot slower than I should have tried to achieve and that they would have liked, and it's important to avoid burnout.

I thought I needed to earn my place and tried very hard, but slowing down and going home at the right time regardless of whether the thing I was working on was done or not, would have been smart. They placed a lot of pressure on me to produce perfect code at the same rate as all the java devs based on the assumption the assumption their job was harder because it was backend, but the tools and parameters of their work were wildly better at the time, and I had undiagnosed ADHD.

So, I'd be protecting my sanity more and telling them it'll get done next week instead of trying to fit one more thing in because "it's just a button" or whatever.

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

#245
I prefer a flat structure where you're a junior developer if you're still in training. I've held positions where my title was senior while I worked on a few projects, both legacy and otherwise. However, I think labels like these are harmful and create an atmosphere of authority and gatekeeping. I still learn new and exciting things from everyone, including junior associates. On the other hand, I know people who label themselves as senior who could be called junior.

After enough time, none of these HR provided labels matter and the work you do signals your level, not the other way around. Just a fair bit of warning though, regardless of your level, you should know how to implement the solutions from the ground up without corporate support and IT setting everything up for you.

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

#246

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…

Similar here. First thing I do when joining a new project is to fix bugs in a legacy product. Forces me to read through the code, follow the data and execution. Nice thing about bugs is also they (mostly) have defined behavior.

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

#247

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 think that value comes from code that solves tough or complex problems, which can be humbling while improving your understanding. Feels good when you get a grasp of what’s going on and can understand that there may not be a simpler approach, just a different one.

There’s also legacy code that is not great and is not solving a complex problem but is just a product of the conditions at the time. It’s easy to look at that and assume you can do better given the same constraints, and this is neither educational nor esteem-building. Just an ego massage.

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

#248

Earlier quoted context omitted.

I keep telling people v1 of anything always sucks. One of the tells of an inexperienced engineer I use is how much they disparage the previous team's work.

This harkens back to Chesterton’s Fence. It’s always worthwhile to interrogate why things were done the way they were, especially when first coming onto a project. Knowing the why of a decision is essential to understanding if and how it should be changed. Especially if the reason is “this is what we had the time and knowledge to do at the time.”

The people who have those answers have long gone. The only person left is a project manager who tells you it's up to you to figure it out. After you make a change in production they will come to you with questions after a few months, just when you assumed things must have gone well

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

#249

Only a little senior, if you're still working and not sitting in meetings all day - rungs remain

Why is sitting in meetings all day considered the top of the IC developer ladder? I don’t want my career to end up like that

Beats me, I didn't want it either :(
Post reply on HN