Boring stacks win
On choosing tools you can debug at 2am, and why novelty is a liability in production.
Every few months a new framework promises to solve the problem you already solved. It is faster. It is more elegant. It has a fox or a moon as its mascot. And every few months I keep choosing the boring thing — Postgres, Next.js, Node, a single deployment target — and the boring thing keeps quietly winning.
I have been on the other side. I have been the engineer who picked the new thing. The bet usually goes the same way: the first week is exciting, the second week reveals an undocumented edge case, and by the time the production incident lands you are reading GitHub issues from 2024 with no replies.
What I actually optimize for
I do not optimize for elegance. I optimize for the engineer — usually a tired version of me — who has to debug this at 2am with a stakeholder on Slack. That person is not impressed by clever abstractions. That person needs answers in StackOverflow, in changelogs, in the muscle memory of a tool they have used a hundred times.
Boring tools win because they have been broken in public, in front of millions of engineers, for years. Their bugs are documented. Their failure modes are known. Their performance characteristics are predictable.
When new tools are worth it
- When the boring tool genuinely cannot do the job — not just less elegantly.
- When the cost of being wrong is small and reversible.
- When you have time and budget for the learning curve to pay back.
Most of the time, none of those are true. Most of the time you have a deadline, a small team, and one shot at convincing someone the project is worth continuing. Boring is what gets you there.
Novelty is a tax. Sometimes the feature is worth the tax. Usually it is not.
If you are starting something today and you are not sure what to pick, pick the thing your most senior friend is bored of. They are bored of it because it works.