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

361–370 of 431 posts

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

#361

Post by runeblaze »

belval wrote: post #200

Might be true, but as someone who worked on a few legacy projects, the opposite, i.e. "You're not a senior engineer until you've worked on a greenfield project" is also true. There are skills that you won't pickup by working on old piles of code. Knowing what technology to pick, how to design your system for high-availability and how to avoid needless complexity are just as important to a well-rounded senior. Perhaps…

Personally reading this thread I just realized that devs encompass so many areas. Requirement for senior engineers working on practical formal methods, real-time systems, Linux-kernel hacking, or those writing CUDA kernels all day are all gonna be different. System design is only for a broad kind, but not for all kinds, of senior engineers.

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

#362

Post by kerkeslager »

pmarreck wrote: post #98
kerkeslager wrote: post #88

Earlier quoted context omitted.

I have hobbies. The most interesting work is going to be 10% interesting and 90% not interesting. In most cases it will be less interesting than that. Prioritizing "interesting" work means you'll always be exploited by the companies that can sell you on less pay, less benefits, less time off, less respect in exchange for some pittance of perceived novelty. Don't fall for this trap.

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

Actually you're completely wrong. I do have ADHD.

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

#363

Post by godelski »

ChrisMarshallNY wrote: post #350
godelski wrote: post #327

Earlier quoted context omitted.

To add (some overlap): - Share credit and be generous with sharing - It is better to error in the direction of over sharing credit than under sharing (taking credit for yourself) - Slow down, say "I don't know" (good to follow up with "but I'll find out") - Saying "I don't know" is often a better answer than guessing - Guesses are fine, but should be prefaced and be clear that you speculate BUT will follow up and ver…

One of the best ways for me to learn, is to explain. That's a very old pattern. That's one of the reasons I write stuff that no one reads[0]. Writing up a technique forces me to research it, and break it down into its simplest components. [0] https://littlegreenviper.com/miscellany/

  > One of the best ways for me to learn, is to explain.
Kinda The Feynman Method[0] or even Rubber Ducky Debugging[1]. I found that teaching in grad school has immensely helped. Not only do you have to solidify concepts to a much higher degree but you revisit stuff too. I think there is a big difference between the level of expertise needed to be comfortable working with some knowledge vs what is needed to teach that knowledge. The former is much more personal. But when learning any topic there's always things you had to table, that you didn't answer, because you had to make general progress. But if you don't revisit these, then they always remain unknown. Revisiting often brings new insights and thinking that you probably didn't expect. Any time I've revisited a topic, even ones I know quite well and have revisited many times, I often find that there's still more for me to learn. There's infinite depth, so always keep your eye out.

[0] https://fs.blog/feynman-technique/

[1] https://en.wikipedia.org/wiki/Rubber_duck_debugging

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

#364

Post by throwaway2037 »

m463 wrote: post #305
ChrisMarshallNY wrote: post #268

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…

> > very arrogant > a defensive shell around personal insecurity. could just be despair and honesty. I was reading about the kindle os here and wonder how many people are facing giant hairballs in their professional life. > the Kindle’s OS is a mess of Java, Javascript, Lua, Native and React Native code. ... > The Kindle runs stripped down Linux with a React Native frontend along with Java backend applications. https…

The meme image is very funny. Recommended reading: https://kindlemodding.org/kindle-os/kindle_os.png

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

#365

Post by stego-tech »

pmarreck wrote: post #105
stego-tech wrote: post #74

Earlier quoted context omitted.

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

Yup, you and Shermantanktop get what I was asking perfectly. Seeking confirmation I hadn’t overlooked anything that I could’ve done better, but you’re both dead-on.

The irony is that for those of us who enjoy maintaining, improving, and eventually replacing legacy stuff (code, systems, infrastructure, etc), what we really want is often just stability in career - hence the moat. It means it’s cheaper to keep us around for the long haul than rehiring us again at current market rates every few years, especially if we’re making ends meet with a high quality of life. But that’d mean focusing on the long term, which I don’t see many companies doing in general.

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

#367

Post by kerkeslager »

namdnay wrote: post #19
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.

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 :)

At this point I just don't think total rewrites from scratch are a good idea, full stop. I've never seen a rewrite from scratch that didn't lose most of the learned solutions from the previous attempt, repeat most of the same mistakes and have to re-discover the solutions, and utterly fail to even attempt a passable improvement on a model of the core complexity of the problem being solved.

I'm not granting a "rewrite from scratch in Rust" exception even though that's in vogue right now. I'm not saying don't rewrite it in Rust, I'm saying don't rewrite it from scratch. It's harder to write new features in Rust while maintaining the old C code, but it's the right way to do it.

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

#368

Post by 3vidence »

epolanski wrote: post #294
catlifeonmars wrote: post #258

Earlier quoted context omitted.

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 fr…

I feel very similarly about the split between my professional and personal code.

Theres always something that needs to be rushed out the door at work and honestly nobody pays me for pretty code.

But my own projects? The code is a large part of why I do it .

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

#369

Post by tomlockwood »

I kind of love working on a legacy project, its like reading a love letter from past devs, their hopes and dreams, classes describing an abstraction that was never used. It's like reading hate mail from past devs, towards their bosses, towards ways of doing things they didn't like. It's like uncovering a stack of newspapers from a time before agile, when people had eldritch and archaic ways of naming tables and variables and methods, when they spoke of things we've forgotten.

Sometimes it is a pleasure and sometimes it feels distant and alien and frustrating.

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

#370

Post by gibspaulding »

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…

> 2009-04-03 JS Added TAX_REF_ID

Hey at least they’re using iso 8601 dates!

Post reply on HN