I’ve previously argued that great tools for thought rarely come from contexts focused on creating tools. They’re usually created in the course of deep creative work in some domain, almost as a byproduct. And they’re usually made by people with significant expertise and investment in those creative problems. Stephen Wolfram created Mathematica to accelerate his original research on cellular automata; Alan Kay created Smalltalk to support PARC’s personal computing experiments; Dan Bricklin created VisiCalc in business school to help solve financial models. All three of these inventors were serious computer scientists invested in some original domain problem.
In these cases, the inventors’ domain problems were actually about math and computing, which certainly makes the overlap in skills likelier. We find another common source of overlap with computer scientists inventing tools in relatively universal domains. For instance, Charles Simonyi (inventor of the WYSIWYG word processor) was a computer scientist—but as a knowledge worker, he was also naturally a prodigious producer of memos. It’s telling that the affordances in Bravo (and later Word) are much more suited to memo-writing than for, say, novel-writing.
Outside these common areas of overlap, it’s harder to find great computer scientists who are also great domain practitioners. In most domains, great tool-makers are rarely great tool-users, and vice-versa. Michael Nielsen has pointed out that you would probably rather have Stradivarius make your violin than Joshua Bell, but you’d probably rather hear Joshua Bell play. Each activity—violin-making and violin-playing—requires independent virtuosic skill and a lifetime of practice. It’s rare to find both abilities in the same person!
Even if you did, there might be some advantages to separating the work: the tool-maker could constantly consider abstraction and generalization, and the tool-user could focus on meaningful problems at hand without being distracted by issues of systematization.
So certain kinds of progress in “tools for thought” may depend on figuring out a way for “tool-makers” to work very closely with “tool-users”—people who are in some sense devoting their lives to playing the instruments we create. This goes beyond the typical lite-ethnographic “design research” practiced by firms like IDEO: luthiers must become at least modest violinists themselves, embedded in those communities, and capable of making original (but probably limited) contributions to their problems. Likewise, the tool-users must become active participants in the design project, learning enough about how the tool is built to contribute meaningful ideas.
Photoshop is a good example: it was a collaboration between Thomas Knoll, a computer science graduate student; and his brother, John Knoll, an artist working on special effects at Industrial Light and Magic. I pursued a similar arrangement with Michael Nielsen when developing Quantum Country, and with teachers like Scott Farrar when researching novel educational environments at Khan Academy.
Orchestrating this kind of pair collaboration is much more challenging than the simpler case of a single effective tool-maker/tool-user. I’ve been collecting notes on the space; today I’d like to describe one strategy that seems particularly important in the space of medium invention.
How can working on the problems of another discipline, for the purpose of enhancing a collaborator, help me as a computer scientist? In many ways:
- It aims us at relevant problems, not just exercises or toy-scale problems.
- It keeps us honest about success and failure, so that we don’t fool ourselves so easily.
- It makes us face the whole problem, not just the easy or mathematical parts. In computational geometry, for example, we can’t avoid the cases of collinear point triples or coplanar point quadruples. We can’t assume away ill-conditioned cases.
- Facing the whole problem in turn forces us to learn or develop new computer science, often in areas we otherwise never would have addressed.
- Besides all of that, it is just plain fun to look over the shoulders of those discovering how proteins work, or designing submarines, or fabricating on the nanometer scale.
—“The Computer Scientist as Toolsmith II”, Fred Brooks (1994).
In a collaboration focused on medium invention, the tool-user might be an author, filmmaker, or artist. They’re the one with the authentic problem—a question to be answered, something to be said, an aesthetic to explore. Practically speaking, if we expect the tool-user to drive the context of use in these collaborations, they’ll be the primary instigator of the pair’s creative projects: hey, this story idea I have really wants to be expressed in a non-linear medium. Now there’s a project, and the tool-maker can start riffing on ideas around mediums which would support those creative aims.
But there’s a tricky chicken-and-egg problem here. If great creative work should drive the invention of new mediums, how can the initial idea driving the creative work get started in the first place?
In this model, the instigating context starts in the tool-user’s mind, likely the result of semi-private tinkering or reflection. For our example of expressing a story concept in a non-linear medium, maybe the tool-user got their idea when reading an article about Twine, then ran up against some of its limitations and mentioned them to a tool-making collaborator. But this means that as the tool-user tinkers with ideas which might become new creative projects, they’ll mostly be incorporating tools that are already almost “within grasp.” If a pair hopes to explore some idea in tool-space through a serious creative project, that idea must already be concrete and accessible when the tool-user’s conceiving of a next project. The pair must proactively develop an armory of tool ideas (both embryonic and mature) to equip the tool-user’s explorations.
Tool ideas in the armory don’t have to be working software. They just have to be solid enough to stand on—understood well enough that the tool-user can tinker with them in emerging creative projects. For example, when Michael started writing Quantum Country, the software was only an early sketch: the important thing was that he understood the idea’s shape well enough to imagine a book which powerfully implemented it. While sketching the book, it was fine (for a while) to simply write “Question: How many dimensions does a qubit’s vector space have?” in the text. The core idea behind the mnemonic medium was already “in the armory,” built on years of experimenting with spaced repetition systems.
The armory has important implications for the pair’s relationship and the division of labor. The tool-maker isn’t conceiving the creative projects, so if there’s an idea he finds promising, he must drive its development to the point that the tool idea is “in the armory,” so that it can then inspire future creative projects. On the other hand, the tool-user’s mostly not developing tool ideas, so if he’s struck by a tool idea—but that idea is not yet solid enough to be “in the armory”—he should be able to lean on the tool-maker to drive the idea’s development until it’s ready for the armory.
In both cases, the pair must develop ideas for the armory without assurance that they’ll necessarily be used by a future project. Entering the armory is just a necessary (but not at all sufficient) precondition for use in a serious creative project.
This conception is mostly useful in the context of repeated collaborations, particularly across distinct projects. The pair can learn plenty about their tool ideas as the tool-user deploys them in serious creative projects, but each project has limited scope for iteration. That’s because it’s difficult to maintain emotional connection to a creative project across delays and breaks.
To see why, imagine that the tool-user has written a first draft of a book in a new medium. Lessons from that draft prompt new iterations of the pair’s medium ideas. Though the tool-user may be plenty interested in those explorations, he’s likely not interested in totally rewriting the book using a new iteration of the medium. The medium can evolve a bit—particularly early in the drafting process—but it rapidly pushes against a gumption limit.
If the tools involved in each creative project can only evolve a limited amount during the course of that project, then each project’s tool frontier is substantially determined by the state of the tools at the start of the project. This challenge suggests that the pair can best evolve their ideas through a sequence of creative projects.
There’s a tension around the size of the projects in the sequence. Smaller projects will support more dramatic iteration in the tools—a higher “learning rate,” if you will. But small projects may not be serious enough to develop the tool ideas. Ideally, I suppose, the pair pursues the smallest sufficiently-serious projects they can.
I see these dynamics play out in practice as I speak with authors and teachers in the context of potential collaboration. They’re often excited about the medium ideas I’ve expressed, and so they suggest projects or contexts which make use of the concepts I’ve published. Very naturally, their ideas for projects skew towards the most understandable paths for those new medium concepts. But of course, the way to push these ideas forward is to focus on the least well-understood notions.
If I want to make that happen, I need to make those ideas more concrete and graspable—in other words, I need to add them into the shared armory. And, of course, I need to much more deeply internalize the creative domains of my collaborators, so that I’m stocking the armory with concepts best suited for their problems.