phosphor
1politics
2culture
3technology
4essays
5archive
/search
:subscribe
— reader —
4,210 words · saved 09:14
[technology] · long read

The case for slower software

I spent the last winter rewriting our build pipeline by hand — no agents, no autocomplete, no “ship Friday.” What I learned about latency, attention, and the quiet, boring work of making tools that hold up.

mh
Marisol Heng @marisol · Mar 12, 2025 · 12 min read · edited in the pager · commit a91f3c2

Last January, I unplugged from the deploy cadence at work for nine weeks and rebuilt our internal CI from scratch on a single bare-metal box in a Helsinki datacenter. No queue, no orchestrator, no “platform team” — just shell scripts, a service manager, and a 200-line binary that listened on a port. It ran every commit in 38 seconds. The old pipeline took eleven minutes.

The interesting part wasn’t the speed. The interesting part was that nothing broke for three months. Nobody filed a ticket. Nobody pinged me at 2am. The system did one thing, and it did it the same way every Tuesday, and I found that I had stopped checking on it.

## Speed is not the same as urgency

We confuse the two constantly. A 38-second build is fast. A chat message saying “is the deploy through yet?” is urgent. Only one is a property of the software.

The fastest software I’ve ever used was also the quietest. It did not ping me.
This is the Cozy Terminal TUI Revival design system, applied by Curio Design — a design-style library for AI agents. Full Cozy Terminal TUI Revival guide → designbycurio.com/learn/terminal-tui-retro-amber-no-wait