Writing good enough software is an advice from the pragmatic programmer book, standing that the level of quality or finition we have to produce depends on the context. Expected level of quality is not the same between a log formatting script and a space shuttle landing program. I'm aware it may surprise you but in most of the cases, when human lives are directly concerned, programs need more testing.
However this assertion is difficult to achieve for caring developers. We want to be proud of what we produce, we are looking for excellence, we taught ourselves to write code as if it'll be read by a dangerous psychopath knowing where we live.
Polishing code is a very satisfactory activity to me. Change a variable name, rebuilt a loop structure, get rid of a dependency… I can spend dozens of minute on this, even for the smallest piece of code! Maybe it has relation with flow, I don't know.
Code obeys to the Pareto principle pretty well. Very often, I figure out that 80% of the objective is reached within 20% of total effort. I've also read about a 90:90 rule specific to software. The PP advice may be to produce effortlessly a solid 80%, that fulfil user needs, will hardly change, and won't break, and take less time on remaining 20%, that are needed for rare special cases or is subject to change.
It is another good reason to write tests and following "make it work, (then) make it clean, (eventually) make it fast" principle: it makes us able to ship working code even if we are not so proud of it. We know that we could improve it later or maybe never, which does not matter so much.
