11 ms·

You can maintain other people's monstrosities and quickly learn the lessons. There's a couple of folks at work who joined straight out of college a few years ba

by geofft 6y ago

You can maintain other people's monstrosities and quickly learn the lessons. There's a couple of folks at work who joined straight out of college a few years back and ended up with ownership of a terribly-designed production system that everyone else depends on, and they've been doing a solid job of switching it over to a reasonable architecture while it's running. I don't know what title they have but I'd certainly trust them with complex systems more than the people who built the original mess. Every poor decision, every overconfident choice of shiny new database, every weird layer on top because they wanted something expedient, every ill-advised API promise, etc. has hurt this new team, and the original builders for the most part have gone on to other employers. Meanwhile, you can also absolutely spend five years not working on anything that needs to scale (by being at a company/team that can't execute, by building prototypes instead of products, etc.) and not have a sense of how to do better.

croon 6y ago
I can't make any judgement on the specific case you're describing, but I've seen this general scenario play out a few cycles in my career. My guess is that they overcorrect on the previous system designers mistakes, because they too have only had that one experience and this is their first time building a new one. And the cycle repeats in another 5 years when a new group of fresh grads have to take over/rebuild the current new system. I hate being ageist in any direction, but experience actually do take time, and only older people have been younger, never the reverse. The hard part is recognizing what is unique to a generation and what is commonality. Or you can tell me I was wrong in 10 years.
iso1631 6y ago
Everything thinks the crap they inherit is terrible. Everyone thinks they can rebuild it in a far better way. Everyone then passes their project on to someone else, who thinks the crap they inherit is terrible.
- nthj 6y ago
  I agree, and this is why I mentor my engineers to replace the phrase technical debt with specific qualities that are impacted by technical choices: * Resistant to future change * Won’t scale past x units * Prone to operational issues * Exposes us to liability or compliance risk * Increases ongoing maintenance costs Any large initiative to replace "crap" should map to specific product quality attributes that stakeholders and leadership buy in to, and ultimately be justifiable back to COGS or churn mitigation. In this way, objectively, a system can be $10M better because it e.g. closes $10M in customer tickets.
  - RandoHolmes 6y ago
    This is why any of the "ilities" is a red flag for me. Don't tell me it isn't scalable, make it concrete. Tell me what specific numbers we're supposed to meet. Don't tell me it isn't readable, tell me specifically what the problem is.
    - deleted 6y ago
      [deleted]
  - Aeolun 6y ago
    Oh, I like this one. I’ll be borrowing it for future use.
routerl 6y ago
In my (extremely not senior) view, maintaining other people's monstrosities doesn't teach the right lesson, because there are many ways to get things wrong, but fewer ways to get things right. Previously, maintaining someone else's monstrosity taught me to avoid their specific mistakes, but not those classes of mistakes. I'd momentarily feel superior over having a different idea about how to accomplish those goals, only to feel deflated once my idea also showed short-comings. Better to learn how to reason correctly about these things, and that probably doesn't happen until you take seriously the cost of maintenance, which really only comes once you've spent enough time in those trenches, having dug them yourself.
- RandoHolmes 6y ago
  > I'd momentarily feel superior over having a different idea about how to accomplish those goals, only to feel deflated once my idea also showed short-comings. That just means you weren't valuing the right things. At the end of the day, that's what it's about. It's not about "technique A should have been used instead of technique B", it's more about what you value. It matters because those values will inform both your decisions and your actions. For example, someone who values performance will not write slow code. Someone who values productivity will write slow code. Someone who values stability may or may not write slow code and may or may not be productive, but their systems won't arbitrarily go down.

by geofft 6y ago

croon 6y ago

I can't make any judgement on the specific case you're describing, but I've seen this general scenario play out a few cycles in my career. My guess is that they overcorrect on the previous system designers mistakes, because they too have only had that one experience and this is their first time building a new one. And the cycle repeats in another 5 years when a new group of fresh grads have to take over/rebuild the current new system. I hate being ageist in any direction, but experience actually do take time, and only older people have been younger, never the reverse. The hard part is recognizing what is unique to a generation and what is commonality. Or you can tell me I was wrong in 10 years.

iso1631 6y ago

Everything thinks the crap they inherit is terrible. Everyone thinks they can rebuild it in a far better way. Everyone then passes their project on to someone else, who thinks the crap they inherit is terrible.

nthj 6y ago
I agree, and this is why I mentor my engineers to replace the phrase technical debt with specific qualities that are impacted by technical choices: * Resistant to future change * Won’t scale past x units * Prone to operational issues * Exposes us to liability or compliance risk * Increases ongoing maintenance costs Any large initiative to replace "crap" should map to specific product quality attributes that stakeholders and leadership buy in to, and ultimately be justifiable back to COGS or churn mitigation. In this way, objectively, a system can be $10M better because it e.g. closes $10M in customer tickets.
- RandoHolmes 6y ago
  This is why any of the "ilities" is a red flag for me. Don't tell me it isn't scalable, make it concrete. Tell me what specific numbers we're supposed to meet. Don't tell me it isn't readable, tell me specifically what the problem is.
  - deleted 6y ago
    [deleted]
- Aeolun 6y ago
  Oh, I like this one. I’ll be borrowing it for future use.

routerl 6y ago

In my (extremely not senior) view, maintaining other people's monstrosities doesn't teach the right lesson, because there are many ways to get things wrong, but fewer ways to get things right. Previously, maintaining someone else's monstrosity taught me to avoid their specific mistakes, but not those classes of mistakes. I'd momentarily feel superior over having a different idea about how to accomplish those goals, only to feel deflated once my idea also showed short-comings. Better to learn how to reason correctly about these things, and that probably doesn't happen until you take seriously the cost of maintenance, which really only comes once you've spent enough time in those trenches, having dug them yourself.

RandoHolmes 6y ago
> I'd momentarily feel superior over having a different idea about how to accomplish those goals, only to feel deflated once my idea also showed short-comings. That just means you weren't valuing the right things. At the end of the day, that's what it's about. It's not about "technique A should have been used instead of technique B", it's more about what you value. It matters because those values will inform both your decisions and your actions. For example, someone who values performance will not write slow code. Someone who values productivity will write slow code. Someone who values stability may or may not write slow code and may or may not be productive, but their systems won't arbitrarily go down.