While I don't disagree with the premise that code that is better needs to get read less often, I think the problem is that by the metric of "how often will this

While I don't disagree with the premise that code that is better needs to get read less often, I think the problem is that by the metric of "how often will this code need to be read", pretty much no one writes code good enough to not have to worry about readability. I'd argue that both buggy code _and_ unreadable code is attributable more precisely to people overestimating how good their code is rather than not trying hard enough to make their code good. > In conclusion, good code is rarely read. Good code is so ergonomic that you almost don’t need to read it; you just use it. It allows developers to focus on building features and solving problems rather than deciphering existing code. This is the ultimate goal of good coding practices: to create code that is so clear and intuitive that it almost disappears, allowing the functionality to shine through. The problem I have with this formulation is that it seems highly unlikely that removing "write readable goal" as a first-class concern alongside "write good code" will produce code with more efficiency or quality; at best, you'll end up with the same amount of bugs and readability, but at worst, you'll be producing code with at least as many bugs that's less readable, which in the long run will increase the amount of work to fix the bugs that are found. Reframing the problem in terms of minimizing how much code needs to be read doesn't seem like it would end up improving the outcomes, but it does seem like it's measuring something that's so hard for people to actually estimate correctly that focusing on it will end up making the outcomes worse by the very metric it tries to use.