"Choose boring technology"
Dan McKinley wrote an influential post years ago arguing that engineering teams should default to proven, understood tools — and spend their "innovation tokens" sparingly on genuinely novel problems.
I have thought about this post almost every week since I read it.
What boring technology actually means
Boring does not mean bad. It means:
- Well understood — you know how it fails
- Well documented — answers exist on Stack Overflow
- Battle tested — other people have hit the edges
- Staffed — you can hire people who know it
Postgres is boring. Redis is boring. They are also phenomenally capable and run half the internet.
The excitement trap
New frameworks feel productive because you are learning, not because you are building. The novelty releases dopamine. The debugging comes later.
I have shipped three projects on frameworks that no longer exist. I have shipped many more on Rails, Next.js, and Postgres — and they are still running.
My current rule
New project, new feature, new service — ask: could I solve this with a tool I already understand?
Usually yes. The rare times the answer is no, that is a good reason to reach for something new.
Conclusion
Reserve your innovation budget for the problems that actually require it. For everything else: be gloriously, unapologetically boring.