Notes on slow tools

There's a particular kind of software that makes you wait: a build that takes a minute, a render that takes ten, a darkroom print that takes an afternoon. The modern instinct is to treat all of that waiting as friction to be optimized away. Sometimes it is. But not always.

I've noticed that the tools I'm most attached to are rarely the fastest ones. They're the ones with just enough friction that I have to think before I act — a small tax on impulsiveness that turns out to improve the work.

An example

Compare a quick chat message to a written letter. The letter takes longer, and that's exactly why it says more. You can't dash off a letter the way you dash off a text; the format itself asks you to slow down and mean it.

Software mostly moved in the opposite direction — every interaction faster, every loop tighter. That's usually good. But I think there's a real cost when everything is instant, because instant doesn't leave room for the pause where you reconsider.

I'm not arguing for artificial slowness. I'm arguing for noticing which parts of the wait are actually doing work, before you optimize them away.

← back to entries