Overwhelm Yourself with as Many Tools as Possible (Why Not?)(sungho.blog)
sungho.blog
Overwhelm Yourself with as Many Tools as Possible (Why Not?)
https://www.sungho.blog/p/overwhelm-yourself-with-as-many-tools-as-possible
23 comments
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.
“Easy” things today can mysteriously cause burnout tomorrow. It’s easy to mistake the brain chemicals that lubricate effort for lack of friction.
Also, memorizing mental modals has a sort of path dependence to it. Once you have one in your brain, it’s hard to replace, even if it sucks.
Hear hear. Also, if we include programming paradigms in the category of "tools", I've found that having more options has decreased my programming velocity, as I get distracted while coding down one path by all the other methods which might be better. It's like Plath's fig tree. I deliver better code now but I could be 3x faster when all I had was a hammer.
This is what I think. I admit that the line between the main task and the tools is blurry, but usually the difficulty of the tools tends to be proportional to the difficulty of the main task. As you said, if it's a simple task done with limited cognitive ability, the tools for it are also likely to be simple. Another point is that while there is an upper limit to how difficult tools are to use, there is no lower limit, so there are always many tools that can be mastered simply.
And my view that people overestimate the difficulty of learning them can be shown by this example. If someone made 300 more keyboard shortcuts for a code editor, you'd probably think it's crazy and a mess. But for people learning a foreign language, memorizing 300 completely new words is just everyday life, and it can be done in a day or a few days. Also, this is a long story to tell, but in my experience, it's easier to memorize keyboard shortcuts than foreign language words.
And my view that people overestimate the difficulty of learning them can be shown by this example. If someone made 300 more keyboard shortcuts for a code editor, you'd probably think it's crazy and a mess. But for people learning a foreign language, memorizing 300 completely new words is just everyday life, and it can be done in a day or a few days. Also, this is a long story to tell, but in my experience, it's easier to memorize keyboard shortcuts than foreign language words.
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.
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.
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.
Consciousness? Did you mean conscientiousness?
Yes. I frequently spell it wrong or the phone auto corrects it wrong.
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.
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?
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?
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).
You expressed this this much more concisely that I did.
Analysis paralysis is not inevitable. It's just a case of lacking tool intelligence
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.
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.
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 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.
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.
> 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).
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.
> 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. :)
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.
[1]: https://www.sungho.blog/p/maximizing-mouse-not-keyboard-pote...
- - - - - - - - - - - -
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.
[1]: https://www.sungho.blog/p/maximizing-mouse-not-keyboard-pote...
Problem: Learning many tools takes a lot of time and effort.
Solution: Nah, just learn them it's easy, see it as an investment
Solution: Nah, just learn them it's easy, see it as an investment
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.
For hobby things it might be fine of course.
For hobby things it might be fine of course.
Those are just the cases of lacking Tool Intelligence
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.
Given that, the article does have an implied filter criteria that goes unsaid, even though it says otherwise.
Given that, the article does have an implied filter criteria that goes unsaid, even though it says otherwise.
> 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.