There is a version of creativity that imagines itself infinite. Unlimited time, unlimited budget, unlimited options. It sounds like freedom. It mostly produces paralysis.

The sculptor who can make anything tends to make nothing decisive. The developer with no constraints tends to over-engineer everything into a cathedral nobody needed. Infinite space doesn’t liberate — it dissolves.

What actually makes something good is usually a limit well-chosen.

A deadline forces you to decide what matters. A word count forces you to find the sharpest sentence, not the comfortable one. A bounded domain forces you to understand something deeply before you abstract it. Hexagonal architecture isn’t restrictive — it’s clarifying. When you know exactly where the domain ends and the infrastructure begins, the domain gets sharper. You stop smuggling concerns into places they don’t belong.

That’s not a cage. That’s a craft.

Aulë understood this, or at least he learned it the hard way. He shaped the Dwarves in secret, outside the design of Ilúvatar’s Music — and what he made was brilliant, technically. The craftsmanship was real. But because he worked without constraint, without that friction of working within something larger than himself, what he made couldn’t fully live. It could only imitate. Ilúvatar had to breathe into it what Aulë could not conjure alone.

That’s the paradox the Silmarillion keeps returning to: the makers who refuse limits either corrupt what they make, or find they’ve made something hollow. The Music was a constraint. The Ainur who worked within it shaped the world. The one who departed from it — Melkor — didn’t create. He only distorted.

Constraint isn’t the enemy of craft. Unconstrained power is.

In software, we romanticize greenfield projects. Finally, a clean slate. No legacy, no compromise. But most greenfield projects devolve into the same mess in six months, because the team hasn’t yet discovered which constraints matter. The good constraints — the ones that come from really understanding the problem — take time to earn. You can’t skip to them.

That’s why TDD isn’t just a technique. It’s a discipline of constraint. You write the test first, which means you commit to the interface before you have the implementation. That’s uncomfortable. It’s also why it works. The constraint forces clarity. You have to know what the thing should do before you can build it.

Stoics knew this too. Epictetus was a slave. Marcus Aurelius was an emperor. Both found virtue in accepting the limits of their situation as the actual ground to work from — not an obstacle to transcend, but the very material of a good life. Not resignation. Precision.

You don’t need unlimited options. You need the right limits, clearly seen, honestly worked within.

The question I keep returning to: Which of my current constraints are I calling obstacles — when really, if I worked with them instead of against them, they’d be the thing that finally makes the work sharp?