Unfortunately, I’m not convinced. The author makes a good case for experimentation, but not for “tool maximization.”

I think there is a case to me made for “find tools that do your work for you” —- that’s “buy, don’t build” —- but that case was not made here.

Further, I think that it’s easy to actually overwhelm yourself with too many tools, at which point you’ve exhausted your interest and willingness to learn them. I have several “code time” extensions, which I installed under this exact line of thinking. I still haven’t made the evaluation of which one I prefer. I picked one by default and kept the others “just in case.” And I have plenty of other extensions that I plan to someday evaluate.

I think the best tool use and evaluation comes from a sense of immediate necessity, just like the best learning comes through immediate practice and application.

Everything else is just imagination, which can be hard to sustain and substantiate.

Almost always the tool junkies were configuration people. Almost always the people who could program tended to avoid configuration madness as much as possible or would write scripts to dynamically manage the configuration madness for them.

The most counter-intuitive thing about this is that you really don't have to be smart to be a programmer. You just have to be willing to solve problems. You can call that adversity, grit, or perseverance. While higher intelligence is certainly helpful it is not the defining characteristic. I suppose its similar to consciousnesses, which is negatively correlated to intelligence and yet still required in exceptionally high doses to operating at the top of any profession.

My guess is that the author is curious by nature, and driven toward trying new technology. The author likely enjoyed some success as the result of exploration. The important thing here is: it is not necessarily virtue or pragmatism that led the author to this (I think) contraversial opinion.

Some other things to consider:

- Trying to minimize TCO and risk is important; the more tools (especially free ones?) the more risk and potential cost - Providing an easy training experience for newcomers is important; too many tools can be overwhelming during onboarding - Being happy in your work is important; will the tools make you happy? will they make the people you work with and work for happy?

> If you treat the usage of tools as "subjects of learning" and deliberately memorize them, it can be done. Such things are usually much lighter and smaller in volume than what is normally seriously treated as subjects of learning, which is why they are not treated as subjects of learning. So if you try to master them deliberately, it's easy to do.

I strongly disagree. Cognitive load is a thing that has different impact on individual people. Also, rote memorizing mental models, sometimes difficult-to-grasp ones due to bugs and poor UX design, is never inherently "easy."

"It's easy" is a fallacy, one that I keep hearing especially from healthy male developers, who I think sometimes lack empathy and awareness that not everyone's brain, cognition, and perception works exactly like their own.

For hobby things it might be fine of course.

Solution: Nah, just learn them it's easy, see it as an investment

Given that, the article does have an implied filter criteria that goes unsaid, even though it says otherwise.