
You are your tools - ingve
https://lemire.me/blog/2017/11/22/you-are-your-tools/
======
jake-low
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](https://vimeo.com/106198518)

------
subwayclub
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.

