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

101–110 of 431 posts

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

#101

Post by no_wizard »

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.

> Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy

Truth is harsh, however this seems to be 100% accurate for nearly all cases of employment. Rarely do you get to focus on simply interesting problems and good engineering as a primary concern

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

#102

Post by connicpu »

It's a very interesting experience working in a large codebase that's a few years old while we're in the middle of trying to dramatically rearchitect everything because we realized the old way of doing things was creating tons of technical debt and confusing abstraction. Even worse, we're always trying to optimize things because we've got some soft real-time requirements and we're using about 50% of our entire time budget after we upgraded our bare metal servers to Zen4 (it was more like 70% before that). Every fix turns something else into the long pole that needs to be rebuilt with the lessons we've learned about writing clear, concise, high performance code.

As it turns out, if you're operating on large data in bulk you should probably just have a dense ID map and then do everything in arrays. Nothing beats arrays :)

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

#104

Post by ethbr1 »

MassiveQuasar wrote: post #62
regularfry wrote: post #50

Earlier quoted context omitted.

It depends on your goals, though. Depending on the company, that can be a very good way to be treated as a cost centre to be minimised.

Yes, let's minimize the only dev working on legacy software.

Has said many a manager who thinks developers are fungible.

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

#105

Post by pmarreck »

stego-tech wrote: post #74
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 inevitabilit…

if you've built up respect at the company and speak your mind regarding the maintenance vulnerability, the new crew should pay attention. if they don't, then you're screwed anyway, but so is the company.

source: endured this while working at a startup that was bought out by SFDC. Kept my principles, but lost the job. /shrug

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

#106

Post by curious_cat_163 »

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…

That's insightful! Especially the part about "all the ghosts they had to fight along the way."

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

#107

Post by nxpnsv »

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…

Good advice, now I’m going to have to figure out the office printer, and find my linkedin account…

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

#108

Post by kerkeslager »

thecleaner wrote: post #85
itronitron wrote: post #66

Earlier quoted context omitted.

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

> it also builds self-esteem. Well crafted dig.

Sure, but if there's anything I've learned from working on legacy software, it's that I don't know why the code was written the way it was. I'm not the only smart person to work on a codebase, and it's more common that another smart person did what they did for a reason, than that I'm a genius who knows better than they did.

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

#109

Post by globnomulous »

atoav wrote: post #58
calebpeterson wrote: post #8

I once had a manager that was fond of saying: > Experience is what you get when you don’t have any. The only better experience than working on a legacy codebase is working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions.

I always tend to say: "Everybody learns better from their own mistakes, but if you are empathic you can also learn from other people's mistakes". The latter is less costly and only requires you "only" to open your eyes and look at projects that are in an ugly state the right way. Yet surprisingly few people are capable of looking at someone elses fucked up project and not going all like: "Hah! Idiots! I would never h…

> which software ages like fine wine and which ages more like milk

Now I'm curious. What software has aged well? What software hasn't? Do certain types or categories of software tend to age better or worse?

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

#110

Post by ninetyninenine »

petsfed wrote: post #93
ninetyninenine wrote: post #77

Earlier quoted context omitted.

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

You've found a way to correctly anticipate new user needs and new technologies years, even decades, in advance? And you've found a way to completely forestall the non-technical demands that force non-ideal design choices? You're sitting on a gold mine friend.

I should say not prevent it. But minimize it in the maximum possible way.

I am sitting on a gold mine. But I can’t prove it. That’s the problem with this stuff. The industry moves horizontally with each design such that nobody knows if say the current design trend was better than the last. We go better or we go worse and nobody knows if it actually was.

Maybe I am sitting on a gold mine. The problem is you’d never know about it. You’d never believe it. Because a proof isn’t possible.

So because it’s not provable you have no clue about any design whether one is better or one is worse and thus you disbelieve everything.

The overall question is how do you create a design or pattern that has maximum adaptability to anticipate any possible requirement change with minimal rewrites? Where you only swap in and swap out modules without changing structure?

I think I found the best possible way. But you won’t believe me.

Post reply on HN