On writing software you can leave alone

The best programs I use are the ones I stop thinking about. They start the same way every time, they fail in ways I can predict, and they never ask me to hold their hand. I open them, do the thing, and close them again. That absence — the not-thinking — is the whole point, and it is surprisingly hard to design for.

Absence is a feature

We tend to measure software by what it does: features, integrations, the length of the changelog. But a tool earns its place in your day by what it lets you not do. A good editor doesn’t remind you it exists. A good backup runs while you forget it’s running.

The goal isn’t to be used. The goal is to be relied on, quietly.

Designing for the exit

If you want people to leave your software alone, make the common path boring and the rare path obvious. Boring is a compliment here — it means predictable, and predictable means trustworthy. Every surprise is a small tax on attention, and attention is the one resource your users can’t buy more of.

So I try to ask a different question when I build: not what else could this do, but what can I remove so the person using it can think about something else?