4 ms·

As far as I can tell, most software is changed rarely enough that writing readable code is a net loss. At every job I've had, there were piles of code that wen

• jayd16 6y ago
  >The former always massively outweighs the latter. This is not enough of an argument. You can't predict what code will be read so we try to make it all readable. I consider this to still be beneficial even if most of the code is never refactored.
  • NateEag 6y ago
    Yep, you can't know in advance what code will evolve. I see that as an argument for my position, though. It's faster to write less-readable code. Documenting all your abstractions takes time, as does making sure all your names are ideal, as does making the abstractions in the first place (and they're often the wrong ones if you do them up front). A business only has so much money to spend on a tool or product, and they want maximal bang for their buck. That comes from shipping stuff fast and seeing what sticks. Once you've seen what features are evolving and matter to users, those are the ones you start refactoring and improving, both for functionality and readability. Obviously, do what you can to make your first pass readable. Don't spend lots of time on it until you have evidence this code will be modified often, though, because on average it isn't. I kind of hate this conclusion, and I'm not very good at it, but that's where I've landed these days.