You know, I think we’ve reached the point in the divide where it would be more instructive for me to see more examples of how you work, or vice-versa than it would to continue like this.
I get the sense that we are expressing preferences, at this point. I’m sure it would be interesting to watch you do what you do. :)
> 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).
Anyone who says “it’s easy” might be having an easy go of it, or they might lack the self-awareness to realize the amount of energy and cortisol they are burning through when they accomplish the task.
“Easy” things today can mysteriously cause burnout tomorrow. It’s easy to mistake the brain chemicals that lubricate effort for lack of friction.
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.
I get the sense that we are expressing preferences, at this point. I’m sure it would be interesting to watch you do what you do. :)