The Myth of Done
Every codebase is unfinished. So is every life. The question is whether you're honest about it.
No codebase is ever finished. I used to think that was a problem.
There’s always another layer to extract, another boundary to draw, another test to make more expressive. Every refactoring reveals the next one. Every clean abstraction casts a shadow where the next mess is already forming. The system breathes. The “done” state is a mirage that recedes as you approach it.
Tolkien understood this better than most. He spent decades on the Silmarillion — the deep mythology beneath The Lord of the Rings — and never published it in his lifetime. The timelines shifted. The cosmology evolved. Aulë, the craftsman Vala, built the Dwarves before their time and then offered to unmake them when Ilúvatar confronted him. Even the gods of Middle-earth made things they had to release, or couldn’t finish, or built knowing they were imperfect. Tolkien’s world feels discovered rather than invented — like it existed before he wrote it and will persist long after. The incompleteness is structural to its depth. It is not a flaw. It is the texture of something real.
We confuse completeness with quality. A finished thing is not necessarily a good thing. An unfinished thing is not necessarily a failure.
Marcus Aurelius didn’t write the Meditations for publication. They’re working notes — unpolished, repetitive, sometimes contradictory. He kept returning to the same ideas not because he hadn’t resolved them, but because resolution wasn’t the point. The practice was. The incompleteness was honest.
In software, I’ve learned to distinguish between two kinds of “not done.” There’s the incompleteness that comes from avoidance — the module nobody wants to touch, the edge case quietly deferred, the conversation kept off the agenda. That kind accumulates. It compounds into debt: borrowed time, charged interest.
And then there’s the incompleteness that comes from honesty. We shipped now because the alternative was shipping nothing. We drew the boundary here because further clarity required information we didn’t have yet. We marked this as a known unknown rather than letting it become a hidden assumption. That kind of incompleteness isn’t failure. It’s precision.
The craftsman’s real job isn’t to finish. It’s to know which kind of unfinished you’re standing in.
When you call something “done,” are you being accurate — or are you just deciding to stop looking?