Choose Boring Technology
đź”— a linked post to
mcfunley.com »
—
originally shared here on
I saw this article referenced while reading Bill Mill’s recap of relaunching a website, which in and of itself is a delightful read for those of us who nerd out on large-scale system architectures.
I am almost certain I’ve read Dan’s piece on boring code before, but I wanted to share it here because it serves as a great reference for those of us who are sick of making bad tech stack decisions for bad reasons.
In particular, the ending here sums up my experience consulting with many different tech teams:
Polyglot programming is sold with the promise that letting developers choose their own tools with complete freedom will make them more effective at solving problems. This is a naive definition of the problems at best, and motivated reasoning at worst. The weight of day-to-day operational toil this creates crushes you to death.
Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.
The teams which move the fastest are the ones who are aligned on a vision for what is being built.
Often, these teams hold a “strong opinions, loosely held” mentality where they decide what tools they’ll use, and they’ll use them until they no longer solve the problem at hand.
Put another way: in a business context, experimenting with your tooling is a huge organizational expense that rarely yields a worthwhile return on investment.
Your focus should be on what you are building rather than how you’re building it.