There are two kinds of tools: user-friendly tools, and physics-friendly tools. User-friendly tools wrap a domain around the habits of your mind via a user-experience metaphor, while physics-friendly tools wrap your mind around the phenomenology of a domain via an engineer-experience metaphor. Most real tools are a blend of the two kinds, but with a clear bias. The shape of a hammer is more about inertia and leverage than the geometry of your grip, while the shape of a pencil is more about your hand than about the properties of graphite. The middle tends to produce janky tools unusable by everybody.
Physics-friendly tools force you to grow in a specific disciplined way, while user-friendly tools save you the trouble of a specific kind of growth and discipline. Whether you use the saved effort to grow somewhere else, or merely grow lazier, is up to you. Most people choose a little of both, and grow more leisured, and we call this empowerment. Using a washing machine is easier than washing clothes by hand, and saves your time and energy. Some of those savings go towards learning newer, cleverer, more fun tools, the rest goes to more TV or Twitter.
Physics-friendly tools feel like real tools, and never let you forget that they exist. But if you grow good enough at wielding them, they allow you to forget that you exist. User-friendly tools feel like alert servants, and never let you forget that you exist. If you grow good enough at wielding them, they allow you to forget that they exist. When a tool allows you to completely forget that you exist, we call it mastery. When it allows you to completely forget the tool exists, we call it luxury.
The nature of a tool can be understood in terms of three key properties that locate it in a three-dimensional space. One we have already encountered: physics-friendliness to user-friendliness. The other two dimensions are praxis and poeisis.
The praxis dimension determines how a tool is situated in its environment. The poeisis dimension determines its intrinsic tendencies.
Shell scripting is high praxis, low poeisis. Shell scripts live in the wide world, naturally aware of everything from the local computer’s capabilities to the entire internet. Scripting in a highly sandboxed language like Matlab is low praxis, high poeisis. Matlab scripts are naturally aware of nothing except the little IDE world that contains them.
The shape of the range of a tool in this 3-dimensional space might be called its gamut, by analogy to the color profiles of devices like monitors and printers in 3-dimensional colorspaces (which are variously defined in terms of user-friendly variables like hue/saturation/value, or their more physics-friendly cousins like “La*b*” CIELAB color space).
What we think of as the “medium of the message” is a function of this gamut. Extremely specialized tools, such as say wire strippers, have a tiny gamut, but are very precisely matched to their function. They are the equivalent of precise Pantone shades used by color professionals. Other tools, with very large gamuts, like hammers, are not very precisely matched to any particular function, but are roughly useful in almost any functional context.
I am bad at learning new physics-friendly tools. In my entire life, I’ve really only learned three to depths that could be called professional-level (but still well short of self-dissolving mastery): Matlab, LaTeX, and WordPress. Matlab is high poiesis, low praxis. WordPress is the opposite. LaTeX is somewhere in the middle. I’m much better at learning user-friendly tools, but then, so is everybody, and what makes an engineer worth the title is their ability to pick up physics-friendly tools quickly and deeply.
I’ve learned dozens of physics-friendly tools in a very shallow way, up to what might be called hello-world literacy. Deep enough to demystify the nature of the tool, and develop a very rough appreciation of its gamut, but not enough to do anything useful with it. I can do this very quickly, but run into my limits equally quickly. This makes me a decent technology manager and consultant, but not a very good engineer.
In the last couple of years, through the pandemic, I self-consciously tried to change this, and learned several physics-friendly tools in deeper ways. For a while, I was calling myself a “temporarily embarrassed 10x engineer” on my twitter profile, a joke reference to a John Steinbeck line that was mostly lost on people. A more honest assessment is that I’m a 0.1x engineer who might make it to 0.5x with effort.
Most of the tools I learned through the pandemic were tools I’d previously learned to hello-world level, while a few, such as crimping and 3d printing, were entirely new to me. Here is a partial list:
- CAD (with OnShape)
- Soldering
- Electronics prototyping
- Embedded programming (with Arduinos)
- 3d printer use
- Working with a Dremel tool
- Python
- Animation with Procreate
Right now, I’m trying to pick up a few more — PyTorch (a machine learning framework in Python), 3d design/animation with Blender, and the basics of Solidity, the programming language for Ethereum. I hope to get to amateur levels of competence in at least a dozen tools before I turn 50, spanning perhaps 2-3 different technological stacks and associated tool chains. I have a sort of nominal goal for this middle-aged tool-learning frenzy converging towards “garage robotics” capabilities, but I’m not very hung up on how quickly I get to the full range of skills needed to build interesting robots (and yes, my current conception of robots includes machine learning and blockchain aspects). It’s going to take me a while to acquire a garage anyway.
This is uncomfortable territory for me because I’m by nature a tool-minimalist. Getting good at even one tool feels like an exhausting achievement for me. That’s why, despite being educated as an engineer, I am primarily a writer. Writing typically requires you to work with only a single, simple toolchain. If you’re good enough, you can limit yourself to just pen and paper, and other people will trip over each other trying to do all the rest for you, like formatting, editing, picking a good font, designing a good cover, getting the right PDF format done, and so forth. I’m not that good, so I have to work with more of the writing toolchain. Fortunately, WordPress empowered writers enough that you can get 90% of the value of a writing life with about 10% of the toolchain mastery effort that old-school print publishing called for, and I am perfectly happy to lazily give up on that last 10%.
So why try to gain competence at dozens of tools? So many that you have to think in terms of “stacks” and “toolchains” and worry about complicated matters like architecture and design strategy? The reason is simply that doing more complex things like building robots takes a higher minimum level of tooling complexity. We do not live in a very user-friendly universe, but we do live in a fairly physics-friendly one. So you need something like a minimum-viable toolchain to do a given thing.
There’s fundamental-limit phenomenology around minimum-viable tooling. A machine that flies has to have a certain minimal complexity, and building one will take tooling of a corresponding level of minimal complexity. You won’t build an airplane with just a screwdriver and a hammer like in the cartoons you see in Ikea manuals. In an episode of Futurama, there is a gag based on this idea. Professor Farnsworth buys a particle accelerator from Ikea that comes with a manual that calls for a screwdriver, a hammer, and a robot like Bender.
Periodically, there is a bout of enthusiasm in the technology world for getting past the current limits of minimum-viable tooling, and so you get somewhat faddish movements like the no-code/low-code movements that move complexity around without fundamentally reducing it. Often, such efforts even lead to tools that are overall harder to use. Even generally lazy people like me, who eagerly await the convenience of more user-friendly tools end up preferring more “geeky” tools in such cases. This is something like the tool equivalent of a popular science book making an idea much harder to understand by refusing to include even basic middle-school mathematics. So instead of a simple equation like a+b=c, you get pages of impenetrable prose.
Premature user-friendliness is the root of all toolchain jankiness perhaps.
Fundamentally reducing the complexity of tooling required to do a thing requires understanding the thing itself better. Simpler, more user-friendly tooling is the result of improved understanding, not increased concern for human comfort and convenience. You have to get more engineering friendly to generate such improved understandings before you can get more user friendly with what you learn. Complex tooling usually gets worse before it gets better.
If you try to skip advancing knowledge, you end up with tools that try to be more user-friendly by becoming less physics-friendly, and the entire experience degrades.
About Venkatesh Rao
Loved your essay. Would you say more about the meaning of praxis and poeisis? What makes them high or low?
I’ll try to explain what I’ve taken away. I think Praxis is the measure of how broad the environment in which the tool is usable, and Poeisis is the measure of how exclusive/unique the tool’s implied use case is.
For eg., a knife has high praxis as it is used majorly in a culinary context, but it is also usable as a weapon or to cut down deadwood branches while you go camping. It is very malleable in its inherent reason of usability.
A vegetable-peeler on the other hand has low praxis as its usage isn’t as wide when compared to a knife. It is used to peel vegetables and is rarely used outside the culinary context.
A vegetable peeler’s designed output is to peel things, such as an apple. But in reality, a knife can also be used to peel an apple. The difference here is the better user experience of a peeler. Therefore, the poeisis of a peeler is also low as the problem it was designed to solve doesn’t always need a peeler, the problem can also be solved using another tool such as a knife.
A high poeisis tool I can think of is the security tag detacher seen in shopping malls while your clothes are being billed. A tag-detacher was designed to remove a security tag. Because this tool has a very exclusive use-case, and there are not many other tools available to do the same job, its poesis becomes high. And also since this tool cannot be used outside a sales context, its praxis becomes low.
I’ve thought a lot about this also, but in different terms (obviously).
What you call ‘physics friendly tools’ I think of as “intstruments” i.e. tools which allow the user to “become one and the same” with the tool. The instrument becomes an extension of the user or in your words “allow the user to forget they’re there”.
The other tools, like the washing machine, IMO are really ultimately very specific niche servants. Imagine a washing machine that requires an operator to do things like “trigger soap release” or “flush water and begin rinse”. That’s the ‘user’ of this tool, except that in the washing machine example this is automated by a robot.
When this gets really interesting is when the tool under analysis is a programming language, because as these are more like instruments (which are used as tools to create the robots!), they become extensions of the user. From here it’s easier to jump (but still a jump) into the idea that “language is a tool/instrument” which makes us forget ourselves in it.
“Premature user-friendliness is the root of all toolchain jankiness perhaps.”
It also builds up a cognitive barrier between the user and the domain. This is especially agreggious when the user is engaging the domain creatively over time. You end up just creating a secondary ‘interface domain’. One that the user has to develop intuitions and habits around that often compete with intuitions and habits they have or could be developing in the for the target domain.
When this gets really interesting is when the tool under analysis is a programming language, because as these are more like instruments (which are used as tools to create the robots!), they become extensions of the user.
A programming language exists in the intersection between tools and media. It is a tool because it is tied to an end goal which is a set of actions ( a tool “in the last instance” ) but it is a medium of expression for writers / readers. There have been funny ways to stretch PLs to become natural language like ( COBOL ) or perceiving them in the opposite way and design them with linguistic theory in mind ( Perl ). Personally I’m most fond of hybrid NL-PL systems such as Cucumber | Behave, which knot them together without striving to make one the other. The mapping from a phrase to a function ( to a “step” ) is arbitrary. Specification and implementation are forever separated ( although there exists a recursion in that phrases may exist in steps ). It is as if this it was a a refection of an ironic / pomo theory of language. I think it is the best which came out of Agile but that’s for another discussion.
Great post. I need a ‘cogitation while’ – to absorb your ‘high abstraction above tools’ analogies.
A question. With AI interfaces – say Open AI Codex and Deepmind, will they allow for the user’s idea to override / subsume your stated tool “basic to mastery” levels enabling us mere mortals to make our oerception of an outcome to a problem / solution / new tool without the need for learnung said tools?
Eg you as a kid in 2100 deciding to make a robot assistant to solve a problem, reversing your stated learning, and gaining mastery via feedback of created tool?
Learn by doing without having to learn tools to do?
I am just about to ask Open AI Codex to let a 14yo create a program without all tool interface and mastery – natural language is the tool needed. And a seasoned racing driver ro create novel tracks and vehiclles again without learning tools, just experience. All it seems is needed is the training sets.
Apologies for simplistic questions above as this is straight off the top of mind upon reading this.
Venkat: as a physics-friendly tool user by nature I immediately grasped this distinction. Definitely a “I should have thought of that!” moment. The praxis and poesis dimensions were less clear to me. Something like “scope” and “opinionatedness”?
You mThis was a very intriguing read, thank you for writing it. You mention using the no-code example how sometimes the complexity is just moved instead of reducing it, and often just makes the tool harder to use. Can you mention some of these respective challenges using no-code? I’m curious as I don’t have first-hand experience using it.
Why do you end up preferring the ‘geeky’ tools, is it because in the end you just need to get the job done out of necessity? or do you like the feeling of pride/confidence that comes with understanding a ‘geeky’ tool and doing the job yourself?
What would be an example of a tool fundamentally reducing complexity while also maintaining user-friendliness?ention how
> My current conception of robots includes machine learning and blockchain aspects.
Could you please expand on this?