[joshuahutt]

I really enjoyed how the post was laid out —- the structure caught and kept my attention and made the arguments easy to follow.

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.

[sungho_]

> I really enjoyed how the post was laid out —- the structure caught and kept my attention and made the arguments easy to follow.

Thank you.

> 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 think most of the counterarguments in the comments to this post will have a similar idea to this. My thought is that this phenomenon occurs because of a lack of tool intelligence in handling tools. What those comments show is that more content is needed on how to survive among numerous tools and how to easily filter tools. Some things are hard to use alone without something else, and this seems to be the case.

> I think the best tool use and evaluation comes from a sense of immediate necessity

You assume that people can know what tools they need. Considering my observations, that doesn't match reality. That doesn't mean a dancer has to go through all the Excel documents they don't even use, but it's easy to narrow down the candidates for what might be relevant to you.

[joshuahutt]

> this phenomenon occurs because of a lack of tool intelligence in handling tools. What those comments show is that more content is needed on how to survive among numerous tools and how to easily filter tools.

That's fair. Using tools is a skill. We all have different levels of, uh, enthusiasm for exploring and finding them. I just lack the drive to find the perfect tool, similar to how I lost the drive to endlessly customize my phone.

It just feels like a waste of time relative to the other ways I would prefer to spend my time. You could argue that makes me an inferior developer, and I would gladly concede.

What I scrimp on "craftmanship skill points" I gladly put into "empathy and philosophy" ones. Not that they're mutually exclusive, but I got burnt out on trying to solve the wrong problem too many times that I overtrained on connecting with people and trying to ask "are we solving the right problem?"

I guess I could apply that skill to "can I find better tools or use the tools I have better," but that just doesn't feel like a limiting factor, to me.

> You assume that people can know what tools they need.

Not what I was trying to communicate. I was conveying the opposite — you can't know what you need until you're facing a real problem in a real domain, not an imagined one or a simulated environment. So, rather than try to find the best tools for "all time," let the immediate sticking point drive the process of finding and learning tools, evaluated against what solves the problem at hand (with the context of everything you know up until that point, of course).