[atomicnumber3]

That, and most orgs simply do not reward or even pretend to care about these kinds of improvements. If you delete bad (but working) code, and replace it with good (and, let's assume best-case scenario - also working) code, what has actually changed for the business?

Nothing. Except that in 3 years the junior dev that gets a ticket about doing something in this area will come in and not notice the code isn't a dumpster fire. Or, in 3 years, you won't notice that you didn't have to optimize this code a year ago.

What they do notice is that you were insisting on working on some mumbo jumbo and ok good they're done now they can actually work on something useful. Haha aren't these devs quirky? Sometimes they take a few days and work on something weird, and all the other senior devs nod and salute solemnly and I'm too scared to ask for more details, but they don't usually take too long so let's just indulge them for a few days to keep them happy so they don't leave too.

It takes a very, very deeply engineering-first org to really cultivate this intentionally. And similarly it seems like succeeding as a startup requires at least a decent amount of shipping some shit code fast so you get a series B, so usually you don't start in this posture and never shift into it before it's far too late.

And also unfortunately, devs often _do_ spend time optimizing/refactoring personal pet peeves as opposed to things that might have a good chance of mattering. I once saw another senior dev spend a week optimizing string allocations on our hot path. Our owner loves people who can do this kind of stuff, so it got a lot of praise. The microbenchmarks looked great, pretty graphs. Users noticed nothing, the actual metrics we track literally did not change, and now the already-complicated hot path is decorated with some contorted string-allocation-avoiding warts here and there and the next person to go in and change the code is _definitely_ going to keep doing that pattern, for sure. Meanwhile our oauth flow is still a tortured, unloved, twisted writhing mass of pain and suffering that prints bug reports like CVS receipts.

So... extraordinarily difficult to intentionally cultivate a culture that does this judiciously.

[block_dagger]

One of the most rewarding aspects of my previous career at a company spanning from a startup to an IPO and beyond was deleting bad code and replacing it in a massive Rails app that was touched by hundreds of devs in a high churn environment. I also took on fixing massive schema inefficiencies that had a lot of risk of breaking nearly every other team's flow. It took a lot of careful work and communication across multi-year goals that I managed, mostly alone. I was allowed to do this by a few early folks who believed I was doing a good service for the company in the long run but kept hinting it was a bad career choice for me personally. I believe I was eventually let go for making these massive improvements instead of adding that green button that the new Product guy wanted. No regrets.

[BubbleRings]

I think I’ve taken some considerable career hits for that kind of attitude, but mostly no regrets here either. But I think I was affected by how, once you leave that company, your contribution to the effort can seem kind of gone, gone gone. That’s part of why I came back to trying to create a physical invention that someone might care about. Something for the grandkid to put on his mantlepiece and say “my granddaddy made this and patented it and (hopefully) it was the start of his big company.”

[gerad]

> Meanwhile our oauth flow is still a tortured, unloved, twisted writhing mass of pain and suffering that prints bug reports like CVS receipts.

Wow, this line is a keeper. This whole comment is so insightful. Reminds me of how awesome HN can be sometimes.

[fmbb]

Good code and bad code are not objective values.

I have worked with many people that spend days replacing good code with bad code because they are ”paying down technical debt”.

[atomicnumber3]

This is a good point, but I think it's mostly a precondition to having the luxury of the problems I was describing. If you can't even broadly agree on what is good vs bad code, your engineering org has deeper problems. You don't even need substantial agreement, just enough to identify what the genuine problem areas are, vs what's just not how someone would've written it themselves.

[fmbb]

You need to agree on the problem, not the problem areas.

Then someone proposes a solution for the problem, and you review the code to see that it solves the problem. If the solution is not bad and the problem is big, you can let them merge it.

[nasmorn]

I once worked with a guy that thought all working code was good code. I literally showed him a massively improved refactored version and he basically just shrugged. Once he left our velocity went way up

[BubbleRings]

You should write a book on this stuff.