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

311–320 of 431 posts

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

#311

Post by chasd00 »

philipov wrote: post #125
no_wizard wrote: post #101

Earlier quoted context omitted.

> 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

Boredom is in the mind, not the task. Things aren't boring, people are. An important type of intelligence is the capacity to find what's interesting about a task that others lack the imagination to see. One needs to be able to create their own interesting solutions rather than expecting them to be handed down on a plate.

> find what's interesting about a task that others lack the imagination to see.

word of warning from an old guy, don't create problems for yourself when you don't have to. Turning something boring into something interesting can have painful consequences down the road.

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

#312

Post by adra »

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…

The windows kernel is old. The Linux kernel is old. These are both old code bases, but they're not "legacy" at least in terms of how many would phrase the term. A codebase let to rot is legacy. A codebase that is constantly improving itself to be in the best state so that it can adjust to modern programming standards is just a good piece of software.

That all said, it's all subjective, blah blah the end.

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

#314

Post by dabockster »

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…

Legacy code is amazing RAG material to throw at an AI ;)

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

#315

Post by ninetyninenine »

progmetaldev wrote: post #310
ninetyninenine wrote: post #288

Earlier quoted context omitted.

No im saying i have a general solution for everyone. The general part only applies to the part where are software projects are similar. The part where they are dissimilar it can’t apply. It’s impossible to generalize over distinctly different things but I found a solution that generalizes over what’s similar in the overwhelming majority of projects. If you find a templates solution works for you then that is not a ge…

Apologies for the misunderstanding. Sounds interesting, but saying you can't prove it, and nobody will believe it is a tough sell. I guess I find it hard to believe like others, but you are talking in very abstract terms, and not being able to (or refusing to) give any kind of details sounds like you are trolling or don't realize that your solution does only work for what you work on. I'd say I could be proven wrong,…

No need to apologize. I assure you I'm not trolling. Yeah I am talking in abstract terms because I don't really want to get into a debate on the topic. The reason is because any design style in this area is basically unprovable and leads to endless debates. There's no point.

I do have something that explains my pattern and serves as support for it. But it's no proof because such a thing isn't really provable. Anyway it's easier to let AI explain it. In the following conversation I basically ask chatGPT about this topic with very general questions while manipulating it as little as possible.

https://chatgpt.com/share/67b3ca4b-fc5c-8001-a072-342357b8a6...

chatGPT basically arrives at the same pattern I discovered. Where I cheated is when I started giving my own opinions on the several patterns chatGPT suggests and I hinted the LLM at the direction I wanted to go. Everything else is a very general question.

That being said, there are clearly other sets of general questions that can very well lead chatGPT to form alternate conclusions, but this one aligns with what I and many others have discovered.

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

#316

Post by Terr_ »

kerkeslager wrote: post #108
thecleaner wrote: post #85

Earlier quoted context omitted.

> 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.

Kind of light fighting against the human tendency [0] to blame the failings of others on their core character rather than the situations they are in, and vice-versa for oneself.

[0] https://en.wikipedia.org/wiki/Fundamental_attribution_error

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

#317

Post by pavel_lishin »

tayo42 wrote: post #29
pavel_lishin wrote: post #17

Earlier quoted context omitted.

"Code that already exists" isn't necessarily the same as a "legacy project", though everyone's definition of what "legacy" means is different.

I guess, how do you define legacy then?

Honestly, it's a "know it when you see it" situation mostly, but there are some strong smells indicating there's a legacy project in the walls:

- none of the original authors are with the company anymore.

- it's written in a language/using a stack/using technology that is used absolutely nowhere else in the company anymore.

- it is big enough that migrating all of its functionality is a tremendously difficult undertaking, to the point where it's likely never going to get done, at least not in your lifetime (either in terms of your tenure at the company, or literally, before you die.)

Outdated architecture/code practices/patterns are a smaller smell, as is the lack of documentation/testing - but those can be present even in greenfield projects written by a big enough dipshit - and I say this having been that dipshit at several points in my career :)

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

#319

Post by pavel_lishin »

nateburke wrote: post #37
callc wrote: post #22

Earlier quoted context omitted.

Legacy 12 year old? Try 40 - 45 year old code. Back when people mandated an 80 character line width because their CRT monitors only had so much resolution

IMHO 80 char lines are easier on my eyes, independent of monitor tech. I get antsy all the way over there on the right! Past 100 chars I am simply less confident in being able to pull off the ocular carriage return to the next line.

I find 80 characters to be too short, and the resulting code after passing through a linter is significantly harder to parse due to the indentation being all over the place.

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

#320

Post by godelski »

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…

  But this will never be an issue in the real world
  - Also Random_Rockstar_Dev_254
I see this a lot too. Which I think I have a good analogy: judging a program by its output is like judging a math proof by its last line. But math proofs are really hard and annoying because you can divide by x somewhere and then have to contend with the fact that x cannot be 0 or else you have to divide by 0, making your proof invalid. The proof is only valid in its entirety. I see programs in the same way. But this is exactly why Test Driven Development is so naive. You can't just write tests to check your correctness, it only works under the assumption that you can predict all possible classes of data that will be processed and in which way. Currently and in the future. The experience of a senior should certainly make TDD far more effective, but I'd say a graybeard is one who knows the limitations and is able to write code that is efficient, can per-emptively address future tests, and writes in such a way that the code can be easily modified and adapted for the future changes.

If I've learned anything in my history of coding it is that where the program ends up is never where I expect it to. My experience makes me better at predicting that differential, but to be honest, given a big enough project you are never really going to be able to predict the end state. Things change that are out of your control.

I'd also argue that this is why it is so important to write documentation and comments while coding. It'll help you later on and anyone that is onboarding (small cost to document, but many people reap the benefits). I don't want a junior coming in and completing a task fast, but I want them to come in and learn the codebase and how to adapt it for the task. Sure, it isn't as fast, but juniors are an investment anyways. I think we have to be honest that no matter what we do we are either investing or taking debt, both of which compound. But I think the problem is that interest is hard to observe and debt is less observable than the direct cost seen in an investment. Maybe a real Sr Dev is the one who is more aware of these trade-offs?

Post reply on HN