In defense of boring tools

There’s a particular kind of restlessness that disguises itself as diligence: the feeling that your tools are the bottleneck. A faster terminal, a sharper editor, the new framework everyone’s benchmarking — surely that’s what stands between you and the work.

It almost never is.

The most productive engineers I know share one habit, and it isn’t a tool at all: at some point, they stopped shopping. They picked an editor, a language, a way of taking notes — usually nothing fashionable — and then spent the next decade getting frighteningly good at that small set of things. Their setups are boring. Their output is not.

Novelty has a payroll

Every new tool charges you twice. Once up front, in the hours you spend learning it — and again quietly, forever, in the maintenance: config drift, breaking changes, the plugin that stops working, the migration you’ll do in eighteen months. Boring tools have already collected their fees. make is not going to surprise you. Neither is SQLite, or rsync, or a plain text file with today’s date at the top.

That’s the actual argument for boring: not nostalgia, but predictability. A tool you can predict is a tool you can think with. The interface disappears and the problem is all that’s left.

The escape hatch

None of this means never adopting anything. It means changing the default question from “is this better?” — almost everything is better in some dimension — to “is this better enough to pay for twice?” Occasionally the answer is yes. Version control was worth it. So were type checkers. When the answer is really yes, you’ll notice, because you’ll keep hitting the same wall every week and the new thing removes the wall entirely.

Everything else is shopping. And shopping, whatever it feels like at the time, is not the work.