> 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).
Thank you sincerely for your thoughtful comment.
Here are some of my points:
> I lost the drive to endlessly customize my phone.
The way to avoid that is to 'start at the maximum and gradually decrease'. I don't want to endlessly fiddle with everything while not missing out on anything.
> I gladly put into "empathy and philosophy" ones.
Actually, my anticipated answer is that I would use Tool Intelligence to do this well. But as soon as I say that, people will come at me cursing. I'm trying to find something to say in response to that.
> you can't know what you need until you're facing a real problem in a real domain
My point is, many people can't figure out what tools are useful to them even when they have a real problem in front of their eyes.
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. :)
Thank you for saying that. And be warned: the below part of this comment is self-promotion, so don't read it if you don't want to.
-
-
-
-
-
-
-
-
-
-
-
-
I have a post[1] about how I use my mouse. From that, you can get a sense of how I use tools. I think it will be interesting because while there are many articles about how to use keyboards, I couldn't find articles about mice.
I'll keep posting interesting writings, so I'd be happy if you subscribe. I think when I submit a post introducing my room to HN, they will be at a loss for words.
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).