Make It Inevitable, Not Impressive

For a long time I chased impressive. I wanted the work to make people notice the cleverness in it — the flourish, the trick, the thing that announced how much skill went in. Impressive points back at its maker; it wants you to see the effort. And it works, briefly. But the work I actually admired in other people didn't feel impressive at all. It felt inevitable — as if it could only ever have been this way, as if you could have thought of it yourself, though you didn't. Impressive says look what I did. Inevitable says nothing, because there's no seam, nothing sticking out to admire — just a result so well-fitted to its purpose that it reads as the natural state of things.

Here's the part it took me years to learn: you don't reach inevitable by trying harder in the moment. You reach it by shaping the terrain so the good outcome is the easy one. Software people have a name for this — the pit of success: build the thing so that simply using it normally drops you into the winning practice, without vigilance or heroics. The right path is downhill; the wrong path is uphill, or walled off entirely. You're not relying on anyone (including yourself) to be careful. You're arranging things so careful is the default.

Concretely, that means your defaults are decisions — the default is what most people will live with, so make it the outcome you actually want. It means making the wrong move hard to even express: a shape that only permits the valid state, a guardrail that stops the dangerous call before it runs, a type that won't let an illegal combination be written at all. The effort moves from the moment of use, where it's fragile and easy to skip, into the design, where it's paid once and protects everyone after. (This is a cousin of subtraction from Principle Nº Two, pointed forward: there you remove what isn't the work; here you remove the ways to get it wrong.)

Where it goes wrong

The common failure is leaning on discipline and documentation to prevent an error that a design could have made impossible — a warning in the README instead of a wall in the code. Discipline runs out; the wall doesn't. The opposite failure is building the terrain so steep and narrow that it becomes a cage, blocking legitimate work in the name of safety. Inevitable isn't imprisoning — the good path should feel effortless, not forced. And remember the honest cost: inevitable work is usually harder to make than impressive work, because making the right thing the easy thing takes more passes, not fewer — and nobody will notice the seams you removed.

Put it to work

Take one mistake you keep making — the same slip, the same forgotten step. Instead of resolving to be more careful, redesign so it can't happen: change the default, add the guardrail, reshape the thing so the wrong move simply isn't available. If you succeed, you'll stop thinking about it entirely — which is exactly how you'll know it became inevitable instead of impressive.

From my own practice, and the “pit of success” idea (Rico Mariani; popularized by Jeff Atwood) — make the right thing the easy thing.