[DavidWoof]

I think the idea of things being broken for a bit while you refactor implies that you haven't checked the code in, not that you don't care about breaking things in production.

I've been working with some pretty bad programmers lately, roughly sub-fizzbuzz or close to it, and one of the most stunning differences I've noticed is how terrified they are of their code. They program like they're building a house of cards. Once it seems to work, the idea of refactoring it for readability is completely foreign to them (of course, so is the idea of unit testing).

I think it's that kind of programmer this article is aimed at. Sure, you should make sure you don't break things, but you should also have some confidence in your code and be willing to constantly improve it.

[InclinedPlane]

"I think the idea of things being broken for a bit while you refactor implies that you haven't checked the code in..."

This makes me cringe. I think it means that the code hasn't been merged with the main branch, or to the release branch, or that the feature flags which turn on the new code haven't yet been set to turn it on by default yet.