On Good Tools

A good tool disappears when you're using it. You stop thinking about the tool and start thinking about the problem. This is true for software, for instruments, for text editors, for kitchen knives.

A bad tool reminds you of its existence constantly. Every interaction requires a detour through the tool's logic rather than your own.

I've been thinking about this because I've been trying to decide what makes some developer tools feel good and others feel like wrestling. The answer is almost never the feature set. It's whether the tool agrees with your mental model of the problem.

When it does, using it is almost invisible. When it doesn't, every interaction is a small negotiation.

The implication: building a good tool requires understanding how your users think about the problem, not just what they need to do. These are different. The first is harder. The second leads to tools that work on paper.

Most tools work on paper.