Fix-it-later leads to shoddy code though. If you can have a clear understanding of the important concept (instead of a vague understanding) that can be reflect

Fix-it-later leads to shoddy code though. If you can have a clear understanding of the important concept (instead of a vague understanding) that can be reflected in a good name. Good name meaning one that is descriptive, unambiguous, and reveals a crisp, not vague, concept. Then with that good name, when you write the code the first time, the clarity of the concept will help you avoid logic pitfalls and messy constructs. Not to say comments are always bad, but probably a comment won't be needed, because the name itself will reveal the intent. Then later, when someone does come and edit the code, instead of having to come up with a better name, they can focus on whatever they came there for, and they can do so with a better understanding of each variable and what is going on. The difference between the two approaches is really about where you spend your extra time related to naming. In my approach, you spend a little extra time up front. But it begins paying dividends immediately, as you continue writing the very first version of the code; it is easier to write clearly and correctly. In your approach, you spend less time up front, and pour the code out faster, which might seem like a great thing. You also see an immediate payoff, because your process is fast. But then you (or someone who comes behind you) has to pay a heavy bill of technical debt. When I read your comment I read it as a description of what your current practice is, not something that has been thought through a lot. Growing clear concepts is a great way to think about it, so that's a good line to continue with imho. I just think that part can and should be done up front. Sometimes it's worth a short conversation with another developer to see if you can agree on a good definition reflected in a clear name. But you're also right that sometimes single word names work fine. And sometimes concepts are just clear and don't need much thought. Obviously those ones we can agree on. I'm more focused on the more difficult, or more vague ones, as a place where I think up-front quality naming is better than having the "fix-it-later" approach.