Choose Boring Technology (2015)

I shun the unnecessary - completely with you on that. But I'd prefer gaining relative mastery over _1 decent tool_ in each of the areas that you pointed out so that I have enough tools in my toolkit which prevent me from using the wrong tool for the wrong job. For example, I'd hate to use shell scripts to do something that ansible does really well.

A modern solution, fortunately or unfortunately, is built up of multiple smaller tool sets as you pointed out - and, if used correctly, each enhance productivity tremendously. Writing a frontend app (something that I've only recently started doing since I'm on my own) is immensely more productive if working with something like react rather than with a relatively old framework based on the jvm.

What I'm trying to say is - tech we use is ultimately a tool - we should optimise for productivity. In that case, Boring Technology helps being more productive since we know a lot more about it which makes it easier for us to bend it to our will as well as debug/diagnose the unknowns.

But it also doesn't mean we continue to use `grep` when silversearcher/ripgrep is out there in the world :)

That's the lens that I look with when I come across new tools/technologies (regardless of how long they've been around) - do they have the potential to be net-productivity enhancers over a long-ish period of time && by how much (0.5x? 5x?).

Restricting the number of different technologies in your toolbox gets you most of the benefits described in TFA. But contrary to "boring", it's actually preferable for some of those tools to be bleeding edge. That way you also get to enjoy the benefits of the Python Paradox.

Of course, you need to have good enough taste to pick new techs, and sometimes the bleeding edge will cut you. But because you amortize that cut over the whole org it doesn't hurt much.

React has become the de facto lingua franca for front end development. Could you imagine some CTO or technical lead saying, "We're not going to use React because it's too new and unproven." React has proven itself. Facebooks has 100K+ components. There are no unknowns there. Using jQuery or vanilla JS instead would be way more problematic and have more overhead than using something more experimental like Elm or ReasonML.

You should almost never use classes in JS, but when you do, they're much easier to work with and understand than defining properties on the prototype. The "new" keyword has been around since almost JS's inceptions (it's available in IE 3, which came out in 1996).

Some of your technologies require no learning to start using (PostCSS). Some can require a whole new mental model/programming paradigm, but can be incredibly useful if used sparingly and in the right places (RxJS). And some things you just need to do to not have a garbage application (testing).

Look, just make assessments as to what your needs are, what are common practices, what your current team is capable of being productive with, and what you're going to be able to hire from.

However, if you have React devs in your team, then this is NOT spending an innovation point at all. The same would hold true for even MongoDB here.