I really enjoyed how the post was laid out —- the structure caught and kept my attention and made the arguments easy to follow.<p>Unfortunately, I’m not convinced. The author makes a good case for experimentation, but not for “tool maximization.”<p>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.<p>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.<p>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.<p>Everything else is just imagination, which can be hard to sustain and substantiate.
One thing I learned early in my programming career is that some people can program, as in writing original logic, but many employed programmers found programming to be too tedious or emotionally exhausting. For the later group the most common output of work was writing configurations. Programming logic defines a job but configurations merely describe what to do with existing jobs. The distinction is monumental.<p>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.<p>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.
I am sure that some people will read this post and feel either encouraged or vindicated. A younger version of myself might have been one of them.<p>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.<p>Some other things to consider:<p>- 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?
Analysis paralysis would be the main argument against this (says the guy who took _years_ to finally decide on using the docmfp package for Literate Programming his current project).
If there's one thing that I've seen everybody agree on here it is that you can only choose one operating system, one web browser, one text editor and one $10 dollar per month subscription and then you have to stick with those for the rest of your life.
From TFA:<p>> 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.<p>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."<p>"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.
At least as far as I see around me, people who do this, like a todo list, keep adding new tools and wondering if they shouldn't use that one instead the one they chose before. Depending what field you work in, this is quite annoying because on reddit/X someone will come with something you 'really need to try' and that doesn't add to the bottom line of my business. A bit is nice, but people who try 'everything' are not really productive in my view.<p>For hobby things it might be fine of course.
The problem is there are not 100 tools out there but literally infinite, in the sense that one could not learn them all simply because new ones are created faster.<p>Given that, the article does have an implied filter criteria that goes unsaid, even though it says otherwise.