From “The Inheritance of Tools” by Scott Russell Sanders:
I had botched a great many pieces of wood before I mastered the right angle with a saw, botched even more before I learned to miter a joint. The knowledge of these things resides in my hands and eyes and the webwork of muscles, not in the tools. There are machines for sale—powered miter boxes and radial arm saws, for instance—that will enable any casual soul to cut proper angles in boards. The skill is invested in the gadget instead of the person who uses it, and this is what distinguishes a machine from a tool.
Related post: Software exoskeletons
This notion always comes to mind when I consider using a new software tool to aid my productivity. Before I delegate hard-won skills to an automated tool, I must first test and qualify that tool against my own knowledge and experience.
Just as my prior tools required me to develop a level of expertise and proficiency before I could trust them and use them well, each new tool represents another turn of the (increasingly complex) wheel.
The problem comes when the skills the tool supplements become atrophied. I used to be very proficient in wringing the last ounce of performance from primitive microcontrollers by supplementing compiler output with hand assembly. I remember well the first time an optimizing compiler created code that was both smaller and faster than my best efforts. I took that as a challenge not to further improve my own hand-assembly skills, but to instead learn a bit more about compiler optimization.
That compiler’s output was a sobering reminder that optimally mapping an algorithm to a processor’s instruction space by a combination of graph analysis and brute-force is indeed something that should be delegated to a computer. More important to me was the stimulating intellectual path that led me to that conclusion.
While I do worry (a little) that my “assembler chops” may indeed be fading (especially as new processors with new instructions sets continue to arrive), I put it in the same category as flint-knapping: A practice at which I am not most productive (in the professional sense).
Being able to qualify a new tool for use, to learn enough about it to trust it, is a far more useful skill. If for no other reason than, when it fails, to be able to write an accurate and useful bug report!
I occasionally do some woodworking, mainly when I have more time than money. I once borrowed a friend’s fancy radial arm saw, only to find it wasn’t cutting accurately. Rather than abandon the machine and revert to my hand tools, I instead spent much of the weekend fixing the tool, rather than my home. With no regrets.
All of us are tool users. Many of us are tool builders. Then there’s another group of tool users who are also tool “critics” and “fixers”. I’m proud to be in that last group!
Thanks for sharing the reference, I hadn’t seen that essay and it strums some chords for me.
A tool may be a component of a machine or it could be a stand alone piece to create other components or art.
A machinery may use a tool to accomplish its objective.
The main difference is the process.
A single stand alone component cannot generate a process (process meaning continuous operation with little degradation)
This is the main difference between a tool and a machinery