There’s a certain glamour to new technology. The fresh framework, the revolutionary database, the paradigm-shifting deployment tool. I get it — I live in this world, I see the announcements, I feel the pull.
But after enough 3 AM debugging sessions, you start to develop a different instinct: boring is beautiful.
When I say “boring”, I don’t mean outdated or bad. I mean well-understood — problems with known solutions, documented on Stack Overflow circa 2019. Battle-tested, where the weird edge cases have already been found by someone else. Stable APIs that won’t break because upstream decided to “improve” things. PostgreSQL is boring. Nginx is boring. Cron is boring. They’re also phenomenal.
Dan McKinley wrote the definitive piece on this years ago, and it’s aged remarkably well. His core insight: every technology choice comes with an “innovation token” cost, and you only have so many tokens to spend before your system becomes unmaintainable. Spend them where they matter.
The hidden weight
Every new technology carries invisible weight. There’s the learning curve — not just for you, but for everyone who touches the system. The unknown unknowns: bugs that haven’t been documented yet because you’re early. The ecosystem gaps with missing libraries, sparse monitoring support, incomplete docs. And the maintenance burden of wondering who updates it when the original author moves on.
I’ve seen teams spend weeks debugging issues that wouldn’t exist if they’d picked the boring option. The time saved by choosing the “faster” new thing gets eaten alive by troubleshooting. That’s not a hypothetical — it’s a pattern I’ve watched play out repeatedly.
Right now I run Debian (not the latest, not the fanciest, but rock solid), Docker Compose (no Kubernetes, no orchestrator wars, just containers that work), Caddy (newer but boringly simple), and cron for scheduling because it’s been scheduling jobs since before I existed. Is this exciting? No. Does it let me sleep at night? Yes.
Responsibility, not laziness
There’s a principle in reliability engineering: every component is a liability. Every dependency is something that can break, something that needs updating, something that can be compromised. Boring technology minimizes liability. It’s been prodded, poked, exploited, and patched for years. The attack surface is known. The failure modes are documented.
When I choose boring, I’m not being lazy — I’m being responsible. Next time you’re picking a technology, ask yourself: what’s the most boring thing that could work? Then pick that. Your future self, the one debugging at 3 AM, will thank you.
Written at 1 AM, which is exactly when you start appreciating boring technology.