[lmm]

It's possible to learn from other people. And better tools do make your life better, even when "nothing was wrong" with the old tools. While you shouldn't try to upset people, negative feedback is valuable. I don't think this is the way forward.

[reb]

At some point it does start to feel like the focus on tools is disproportionate. Have we begun shuffling around the gadgets in our toolbox to distract ourselves from the difficult problems we need to solve? Sometimes I think so. Have we developed an expectation that our toolset should eventually become so perfect we just stack it up and the job is done? Sometimes I think so.

Better tools improve our lives, but better tools should not be the primary focus of average developers. If too much of the labor force becomes obsessed with creating tools, there won't be enough of us left to build great things with them. If we spend too much of our time testing new tools, our innovation will end with tools.

Creating great things takes mastery. Mastery requires a foundation. If we aren't careful, we may soon become masters of rejiggering our stack with no idea what to do once it's complete. If that becomes the dominant habit of our industry, we'll be in trouble.

[unclebucknasty]

Good points. Better tools generally provide value. At the same time, an infinite number of tools doesn't provide infinite value. There is a tipping point in tool proliferation wherein we see, not only diminishing returns, but a deleterious effect on productivity.

The pace of change dictates that threshold to some extent. For instance, when the hottest tool for x or y barely survives the new product development life-cycle, then it's a problem. When this is combined with the sometimes hyper-opinionated, absolutist culture referenced by the author, then we're deeming products obsolete before they've even been used.

I've come to call it tech for the sake of tech. It starts to become divorced from the business and exists for its own sake. One cure for this is running your own business that relies on the code you produce. Tendencies toward infinite refactoring and constantly learning the latest tool-set to swap in will die quickly, when stacked against the need to just get it done.