You are your tools

Something not addressed in this article is that not all tools are equally useful. Many tools aren't well suited for your problem; some tools aren't well suited for any problem.

A wonderful discussion of tool-making is Mike Bostock's keynote at Foss4G 2014 [1]. I rewatch it from time to time; it has really made me think differently about tool making and problem solving.

[1]: https://vimeo.com/106198518

Sometimes a "tool" is as simple as agreeing to enter a certain kind of conversation.

For example, when martial artists practice, they mix the study of technique with its application in a competitive setting. This distributes the learning into a feedback loop amongst the population of students, with good techniques surviving and evolving in their application over time. Gradually the dojo settles into a style based on the direction of its teaching and the kinds of students it recruits, which can then be further tested against the wider world in a tournament.

In comparison, if you just watch a video and try to do the techniques with your buddy at home, you don't enter into that conversation. Nothing is being tested thoroughly so your feedback is limited at best and the training probably won't hold up when brought anywhere else.

For another example, having a creative conversation requires taking a starting point or thread of thought and allowing it to be pursued farther and farther without shooting it down or completely terminating the thread. In this scenario the conversation partner or partners need a mindset that can spot opportunities for coherent elements that weren't necessarily obvious: rather than focusing only on execution, they can adapt concepts and techniques from one scenario to another effectively to generate new ideas. Over time this process eventually suggests some form of execution as a way of proving the idea, but not necessarily a "final" execution. The creation of a large work is an accumulation of this process of having the conversation and gradually adapting elements into the work as they are found relevant.

In that light the tangible "tools" of things like gear, software, etc. play a somewhat instrumental role. Sometimes they are the source of feedback because the workflow can convey success or failure(error messages, misplaced pixels, etc.) At other times they are more like a component of execution and require a whole extra design phase in order to convey feedback: development tools play this role with respect to application software since having the program compile and not crash, or even fulfill some written spec, is insufficient in telling you if it's really doing the right thing. And when highly abstract techniques like mathematics are brought into play the effect is almost magical since the coding tools offer next to zero feedback on whether the resulting algorithm produces correct results: you can create some tests but the basis is all steeped in a theory of operation that renders the physical program structure irrelevant.