The tools that get out of the way

There is a particular feeling when a tool disappears. You stop thinking about the tool and start thinking about the work. It is rare enough that I have started keeping a list of the software that manages it, looking for what they share.

The list is short. A text editor, a terminal, one notes app, a stopwatch, a paper notebook that has no opinions at all. What they share is not speed, though they are all fast. It is that none of them ask me anything I did not come to answer.

The cost of a question

Every dialog is a small tax on attention. Individually they are nothing — a second, a click, a choice between two things you do not care about. Collectively they decide whether a tool is somewhere you think or somewhere you administrate.

A tool that asks you a question at the wrong moment has not saved you a decision. It has moved the decision to the point where it costs the most.

The good ones front-load their questions. They ask once, at setup, when you are already in configuration mode, and then never again. The bad ones sprinkle the same question across every session, because someone measured that the setting was “engaged with” and drew the wrong conclusion.

What this looks like in code

The clearest version of this I know is the difference between these two signatures:

// Asks the caller to decide, every single call site.
function save(doc: Doc, opts: { format: Format; encoding: Encoding }): void;

// Decides well, lets you override when you actually care.
function save(doc: Doc, opts?: Partial<SaveOptions>): void;

The second one is not less powerful. It is the same power with the questions moved to where the answers exist. Most callers have no opinion about encoding; the three that do can say so.¹

A short test

Before shipping something, I try to count the decisions I am handing to the person using it:

1. How many choices must they make before the tool does anything useful?
2. How many of those choices could I have made correctly on their behalf?
3. Of the remainder, how many need to be made now rather than later?

The gap between question one and question three is the tax. It is almost always larger than I expect, and shrinking it has never once made the tool worse.

---

None of this is an argument for fewer features. It is an argument for fewer interruptions — which, five years on, turns out to be the only thing that determined which tools I still have open.

Footnotes

1. This is the whole argument for good defaults, compressed. The interesting part is not that defaults save typing — it is that they move a decision to the person who has the context to make it. ↩