On Constraint

There's a common assumption that creativity requires freedom — that the fewer rules you impose, the more interesting the output becomes. I think the opposite is closer to the truth. The most generative moments I've had, in code and in writing, came from working inside tight boundaries.

A sonnet has fourteen lines. A function has a signature. A page has edges. These aren't obstacles to expression — they're what makes expression legible. Without a frame, there's no composition. Without a constraint, there's no decision.

In software this shows up everywhere. A type system is a constraint. An interface is a constraint. The decision to build with no dependencies is a constraint. Each one eliminates possibilities — and elimination is where clarity lives.

I started thinking about this while building a site with no framework, no build step, no templating language. Every page written by hand. It's slower. It forces you to ask whether a page deserves to exist. That question turns out to be useful.

The worry is always that constraint becomes dogma — that you'll follow the rule past the point where it serves you. But dogma is just constraint without attention. The practice is in noticing when the frame helps and when it's become the thing you're performing instead of the thing you're making.

I don't have a tidy conclusion here. Constraint isn't a philosophy. It's a tool with a short handle — you have to stay close to the work to use it.

back to essays · next: The Geometry of Attention · something I built