Comment by geofft | Hacker News Reader

Comment by geofft | Hacker News Reader

Parent Full thread

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.

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.

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

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.

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.

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.

Oh, I like this one. I’ll be borrowing it for future use.

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.

Reply on news.ycombinator.com