6 ms·

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 t

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 is in setting up your local codebase. e.g. sorting out make files, or header file clashes etc. And if you're lucky, some poor bastard has already done the hard work for you. As an aside, I know tons of experienced "Senior" developers who just suck at their jobs. The problem is they have tons of experience in delivering terrible products based on terrible code and architectural decisions. They just never had anyone to show them any better. And now that they're "Senior", noone can tell them anything. Many devs who work in corporates understand this pain. Shoutouts to my peers who have to "fix" 3000 line stored procs with a 100 line "change control comment saying stuff like "2009-04-03 JS Added TAX_REF_ID". I live your pain. EDIT: Also, if you happen to work at company that thrives on terrible legacy products, try to drill it into their heads that BAU Support is not part of the solution. Every time I've raised the issue of the mounting tech debt I've gotten the response "Business does not have the apetite to solve these issues. And why would they? That's why we have support teams".

Clent 2y ago
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 closer to seasoned developer.
- ilitirit 2y ago
  > 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.
- YZF 2y ago
  The title is more or less meaningless these days. That said the other problem is people can't always appreciate the perspective of a more seasoned developer. Some people who are very junior or intermediate think they know better since they don't have the experience. Lots of things in software come down to judgement/intuition and are not black and white. A lot of software development is about working with people and culture, not code.
  - t43562 2y ago
    The unseasoned developers are sometimes very keen on some idea, philosophy or method and are very intolerant of skepticism from someone who knows there is no such thing as perfection and no one way of solving all problems.
serial_dev 2y ago
I see that going through these three kinds of projects let me grow as a developer: 1. green field project 2. other people's legacy project 3. your green field project growing into legacy project. You can learn so much from each of these, but to me the most eye opening experience was our green field project growing into a project with more and more developers. You could learn so much about others, some were very arrogant, went on constant refactoring mission only to mess up everything. If for some reason, I couldn't check what they did, usually, I had to come in and fix their stuff, but sometimes the only person knowing about the edge case was me, so I just left it "messed up". Others tried to understand why the system ended up this way, some accepted it, while the best actually improved the system by looking back and recognizing the simplicity hiding in the mess.
- ChrisMarshallNY 2y ago
  > 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 to adjust to us.
  - karparov 2y ago
    > but internally, insecure people can be reached (not easy) How? Any advice?
    - nothrabannosir 2y ago
      Not OP but: destigmatize admitting failure (by doing it yourself), normalize admitting ignorance and asking questions (by doing it yourself), find someone they look up to and demonstrate healthy collaboration dynamics with that person, explicitly labeling things which you value, as they happen (e.g. "thanks for saying you're not sure, or I would have thought that you were and it would have made me value the statement differently", "thank you for not taking the feedback on the code personally, the result is a better codebase for everyone"). And do the same with them whenever they imitate any of that, without dwelling on it any further or treating it any differently. TL;DR: Normalize healthy dynamics by example. Obviously just my 2c and every case is different etc.
oh_my_goodness 2y ago
So, yeah, the minimum bar for "senior engineer" is very low. Can we all just accept that and move on?
adra 2y ago
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.
- GoblinSlayer 2y ago
  Linux kernel is old rotting legacy which is improving itself.
dabockster 2y ago
Legacy code is amazing RAG material to throw at an AI ;)
godelski 2y ago
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?
- frank_nitti 2y ago
  Always a favorite https://news.ycombinator.com/item?id=11396045 https://news.ycombinator.com/item?id=11396045
  - godelski 2y ago
    this should never happen...but it's happened to me[0] We've all been there lol [0] https://github.com/thehackerwithin/illinois/blob/5f91a29b1d45859e0e1e37f5ffcb5ed42afb9dde/git.md?plain=1#L325 https://github.com/thehackerwithin/illinois/blob/5f91a29b1d4...
Tainnor 2y ago
> 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 Yes, and the flip side to this is the other kind of senior that you mention in your comment: the one that refuses to believe that things can be done better. It's hard to find the right balance between wanting to write better code and pragmatically dealing with the realities of a huge, messy legacy codebase with tons of bad decision - you can't fix everything (and certainly not at once), so you have to choose your battles wisely.
mannyv 2y ago
You can learn from anything. A "legacy" product is one that works, but is generally hard to maintain. "Why is it hard to maintain?" is a question every architecture person should be able to answer...especially after digging into some large, old piece of software.
__turbobrew__ 2y ago
> 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. I see this constantly on HN and have had to learn to not engage with those conversations. It is like some people have never had to run a project under any sort of external constraints like head count restrictions, layoffs, inheriting a system which you didn’t write, or awkward organizational structures. Some will scream until their ears bleed that there is only one optimal way to do things and if you aren’t doing things that way you are a incompetent chump — totally disregarding the reality that people have to work with.
- throwaway2037 2y ago
  The real miracle is when you see a teammate who can still perform well under these insane constraints. I have seen it a couple of times in my career. They still find a way to write "good enough" code or write "good enough" docs. It was inspiring. I would say the same about a sales person who can still manage to have a great year even when the (their) market is cratering. Again, I have seen it a few times, and it always impresses me... watching them pull a rabbit out of the hat!
- darkwater 2y ago
  Or the other typical HN solution to this: just leave that toxic company and go somewhere else! (Maybe it was valid during ZIRP, but not now)
gibspaulding 2y ago
> 2009-04-03 JS Added TAX_REF_ID Hey at least they’re using iso 8601 dates!
khana 2y ago
[dead]
begueradj 2y ago
What if you work on legacy code projects but use AI for that ?
Lorkki 2y ago
> As an aside, I know tons of experienced "Senior" developers who just suck at their jobs. The problem is they have tons of experience in delivering terrible products based on terrible code and architectural decisions. It's a classic tragedy of engineering; you can actually ship with almost anything, and just successfully delivering a product reinforces a feeling that your choices were good, no matter how arbitrary they were in practice. People can get really confident that what they're doing is tried and true, while it's simply the only approach they've had for all of their career.
giancarlostoro 2y ago
Maturity and humility are key factors in being a senior developer. Those who lack humility will often cry about how its not their code that's messed up, delaying actual bugfixes and wasting developer hours, or worse producing a toxic work culture.

Clent 2y ago

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 closer to seasoned developer.

ilitirit 2y ago
> 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.
YZF 2y ago
The title is more or less meaningless these days. That said the other problem is people can't always appreciate the perspective of a more seasoned developer. Some people who are very junior or intermediate think they know better since they don't have the experience. Lots of things in software come down to judgement/intuition and are not black and white. A lot of software development is about working with people and culture, not code.
- t43562 2y ago
  The unseasoned developers are sometimes very keen on some idea, philosophy or method and are very intolerant of skepticism from someone who knows there is no such thing as perfection and no one way of solving all problems.

serial_dev 2y ago

I see that going through these three kinds of projects let me grow as a developer: 1. green field project 2. other people's legacy project 3. your green field project growing into legacy project. You can learn so much from each of these, but to me the most eye opening experience was our green field project growing into a project with more and more developers. You could learn so much about others, some were very arrogant, went on constant refactoring mission only to mess up everything. If for some reason, I couldn't check what they did, usually, I had to come in and fix their stuff, but sometimes the only person knowing about the edge case was me, so I just left it "messed up". Others tried to understand why the system ended up this way, some accepted it, while the best actually improved the system by looking back and recognizing the simplicity hiding in the mess.

ChrisMarshallNY 2y ago
> 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 to adjust to us.
- karparov 2y ago
  > but internally, insecure people can be reached (not easy) How? Any advice?
  - nothrabannosir 2y ago
    Not OP but: destigmatize admitting failure (by doing it yourself), normalize admitting ignorance and asking questions (by doing it yourself), find someone they look up to and demonstrate healthy collaboration dynamics with that person, explicitly labeling things which you value, as they happen (e.g. "thanks for saying you're not sure, or I would have thought that you were and it would have made me value the statement differently", "thank you for not taking the feedback on the code personally, the result is a better codebase for everyone"). And do the same with them whenever they imitate any of that, without dwelling on it any further or treating it any differently. TL;DR: Normalize healthy dynamics by example. Obviously just my 2c and every case is different etc.

oh_my_goodness 2y ago

So, yeah, the minimum bar for "senior engineer" is very low. Can we all just accept that and move on?

adra 2y ago

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.

GoblinSlayer 2y ago
Linux kernel is old rotting legacy which is improving itself.

dabockster 2y ago

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

godelski 2y ago

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?

frank_nitti 2y ago
Always a favorite https://news.ycombinator.com/item?id=11396045 https://news.ycombinator.com/item?id=11396045
- godelski 2y ago
  this should never happen...but it's happened to me[0] We've all been there lol [0] https://github.com/thehackerwithin/illinois/blob/5f91a29b1d45859e0e1e37f5ffcb5ed42afb9dde/git.md?plain=1#L325 https://github.com/thehackerwithin/illinois/blob/5f91a29b1d4...

Tainnor 2y ago

> 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 Yes, and the flip side to this is the other kind of senior that you mention in your comment: the one that refuses to believe that things can be done better. It's hard to find the right balance between wanting to write better code and pragmatically dealing with the realities of a huge, messy legacy codebase with tons of bad decision - you can't fix everything (and certainly not at once), so you have to choose your battles wisely.

mannyv 2y ago

You can learn from anything. A "legacy" product is one that works, but is generally hard to maintain. "Why is it hard to maintain?" is a question every architecture person should be able to answer...especially after digging into some large, old piece of software.

__turbobrew__ 2y ago

> 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. I see this constantly on HN and have had to learn to not engage with those conversations. It is like some people have never had to run a project under any sort of external constraints like head count restrictions, layoffs, inheriting a system which you didn’t write, or awkward organizational structures. Some will scream until their ears bleed that there is only one optimal way to do things and if you aren’t doing things that way you are a incompetent chump — totally disregarding the reality that people have to work with.

throwaway2037 2y ago
The real miracle is when you see a teammate who can still perform well under these insane constraints. I have seen it a couple of times in my career. They still find a way to write "good enough" code or write "good enough" docs. It was inspiring. I would say the same about a sales person who can still manage to have a great year even when the (their) market is cratering. Again, I have seen it a few times, and it always impresses me... watching them pull a rabbit out of the hat!
darkwater 2y ago
Or the other typical HN solution to this: just leave that toxic company and go somewhere else! (Maybe it was valid during ZIRP, but not now)

gibspaulding 2y ago

> 2009-04-03 JS Added TAX_REF_ID Hey at least they’re using iso 8601 dates!

khana 2y ago

[dead]

begueradj 2y ago

What if you work on legacy code projects but use AI for that ?

Lorkki 2y ago

> As an aside, I know tons of experienced "Senior" developers who just suck at their jobs. The problem is they have tons of experience in delivering terrible products based on terrible code and architectural decisions. It's a classic tragedy of engineering; you can actually ship with almost anything, and just successfully delivering a product reinforces a feeling that your choices were good, no matter how arbitrary they were in practice. People can get really confident that what they're doing is tried and true, while it's simply the only approach they've had for all of their career.

giancarlostoro 2y ago

Maturity and humility are key factors in being a senior developer. Those who lack humility will often cry about how its not their code that's messed up, delaying actual bugfixes and wasting developer hours, or worse producing a toxic work culture.