The scratches I could see

Between 1999 and 2005, I wrote my accounting software four times.

From the outside, some of that work would probably have looked unnecessary. The software could have been installed. A customer might never have noticed the parts that bothered me. Time spent rewriting could have been used for another feature, another client, or an earlier release.

But I knew where the scratches were.

That knowledge matters. There is a difference between improving work because the improvement serves the user and polishing it because we are unable to let go. Craft can become avoidance. A rewrite can be a refusal to test the work in reality. The fact that nobody else can see a flaw does not automatically make fixing it noble.

The opposite mistake is also common. We excuse a weak foundation because the surface looks acceptable. We leave confusing code, a fragile process, or an ambiguous commitment in place because the immediate audience cannot inspect it. The hidden compromise survives long enough to become somebody else's constraint.

The useful question is not whether every scratch must be removed. It is whether the scratch changes the integrity of the thing.

Will it make the work harder to maintain? Does it conceal a risk from the person depending on it? Are we accepting it because the trade-off is reasonable, or because the deadline gives us a convenient excuse? If the decision is deliberate and visible, imperfection can be responsible. If we hide the compromise even from ourselves, it usually returns as debt.

I no longer think private standards need a heroic identity around them. They need judgment. Some flaws are cosmetic. Some are structural. The work is learning to tell the difference, and being willing to repair the structural ones even when applause will never arrive.