I'll just point out one part of your comment, and use it to illustrate what I wanted to say.
> instead of learning to use their computers more efficiently
What i wanted to say is just that, you might be just more efficient by avoiding spending a lot of time learning complex tool, and concentrate on simple one, with the hope that the loop of improvements of your tools will compensate the loss of productivity due to a non-optimum usage. The general idea is, if you spend of lot of time to learn a tool, you are betting that it will worth it on the long run, at the hypothetical cost of losing the time use to acquire that knowledge we you finally decide that an alternative is a better option - with the added momentum you'll have before quiting your hard learned cherished tool. On the contrary, when learning quickly, less efficient, simple tools you bet on the future evolution of that tools : you will gain in productivity on the later tools that might pop up, ones that you will also learn quickly, but will be a bit more efficient.
While I would completely agree with the author on the fact that some people will refuse to learn what would be more efficient tool on the long run, he fails to recognize that a chain of more simple tools, that improves over times and allow quick adaptation and optimization can be in some circumstances be an approach that leads to the exact same efficiency.
This is why I complain that the article was pedantic, because it states too strongly that mastering complex software is the way to go, whereas, while there is a regrettable tendency to discard complex tools too quickly, diving in them might be not always as wise as it could seem.
I'll just point out one part of your comment, and use it to illustrate what I wanted to say.
> instead of learning to use their computers more efficiently
What i wanted to say is just that, you might be just more efficient by avoiding spending a lot of time learning complex tool, and concentrate on simple one, with the hope that the loop of improvements of your tools will compensate the loss of productivity due to a non-optimum usage. The general idea is, if you spend of lot of time to learn a tool, you are betting that it will worth it on the long run, at the hypothetical cost of losing the time use to acquire that knowledge we you finally decide that an alternative is a better option - with the added momentum you'll have before quiting your hard learned cherished tool. On the contrary, when learning quickly, less efficient, simple tools you bet on the future evolution of that tools : you will gain in productivity on the later tools that might pop up, ones that you will also learn quickly, but will be a bit more efficient.
While I would completely agree with the author on the fact that some people will refuse to learn what would be more efficient tool on the long run, he fails to recognize that a chain of more simple tools, that improves over times and allow quick adaptation and optimization can be in some circumstances be an approach that leads to the exact same efficiency.
This is why I complain that the article was pedantic, because it states too strongly that mastering complex software is the way to go, whereas, while there is a regrettable tendency to discard complex tools too quickly, diving in them might be not always as wise as it could seem.