Main takeaway: How to incorporate intuitive thinking (ZAMM series)
Intro
There’s a lot I could say about Zen and the Art of Motorcycle Maintenance from a technical writer’s perspective. For example, I could start by summarizing research previously done by tech comm scholars. There are some excellent articles by Charles Beck and Daniel Jones. However, in many ways, more academic interpretations of Zen and the Art of Motorcycle Maintenance aren’t my goal here.
My larger goal is an experiential exploration of the book, attempting to incorporate an intuitive, implicit knowledge into my practices with technology. More than just critical insights from the reading, I want to know: does integrating zen into technical tasks (akin to motorcycle maintenance) actually work? Can it work in writing complex documentation? Has anyone tried? What were the outcomes?
Doing your own motorcycle maintenance
One of the book’s earliest anecdotes about doing your own motorcycle maintenance illustrates this central theme of the book. The narrator takes great care to tune and adjust his own motorcycle. However, his friend John refuses to do any of the maintenance or repair work on his motorcycle himself. John rides an expensive BMW bike and takes it to the shop for even the smallest of repairs. Meanwhile, the narrator rides a Honda that seems to need constant attention, from tune ups to oil changes and more. It’s clear that the narrator likes working on his bike, while John refuses to engage with it.
The narrator interprets John’s attitude toward technology in a larger context, musing on why some people have an ugly relationship with technology and refuse to engage with it but instead run from it. The narrator explains:
“What’s wrong with technology is that it’s not connected in any real way with matters of the spirit and of the heart. And so it does blind, ugly things quite by accident and gets hated for that. People haven’t paid much attention to this before because the big concern has been with food, clothing and shelter for everyone and technology has provided these.
But now where these are assured, the ugliness is being noticed more and more and people are asking if we must always suffer spiritually and esthetically in order to satisfy material needs.”
In other words, the narrator wonders why our relationship with technology needs to be seen as a spiritual and esthetic compromise, as kind of an ugly deal in exchange for the basic necessities it provides. Much of the book’s trajectory explores how to change this ugly relationship with technology to one of harmony and oneness.
Historical context
It’s worth adding some context to the publication of Zen and the Art of Motorcycle Maintenance (ZAMM) because this will illuminate the feelings people had toward technology at the time. In The Buddha in the Machine: Art, technology, and the meeting of east and west (2014), Williams explains that ZAMM arrived during the seventies post-countercultural movement. During the sixties, with the countercultural movement associated with hippies, there was a strong distrust that technology had introduced destructive and controlling capabilities, with dehumanizing war machines (in the context of Vietnam) and government surveillance, leading to manipulation and mass control. There was a Luddite sentiment toward technology. The post-countercultural movement sought to reconcile that attitude about technology with something more positive, embracing the more creative, connective, and liberating aspects of technology.
Pirsig’s book integrates eastern themes of Zen Buddhism with technology as a way to reconcile these attitudes. He argues for a more harmonious relationship with technology as a bridge forward. He even traces technology back to the word’s original meaning, “technê,” which the Greeks understood as a fusion between art and manufacture. A constant theme in Pirsig’s book is to heal our relationship with technology. The narrator explains:
“Their flight from and hatred of technology is self-defeating. The Buddha the Godhead resides quite as comfortably in the circuits of a digital computer or the gears of a cycle transmission as he does at the top of a mountain or in the petals of a flower. To think otherwise is to demean the Buddha — which is to demean oneself.”
To see Buddha in the machine (that is, to see a more spiritual and aesthetic dimension to technology) posed a new idea that synthesized two opposites. This was part of the appeal of the book.
The barbecue instructions
One anecdote in ZAMM illustrates this central theme of reconceptualizing our relationship with technology. The narrator visits an old friend, Deweese, who teaches abstract art (at the same college where the narrator used to teach). Deweese’s inability to follow some barbecue assembly instructions makes him frustrated, and he turns to the narrator to confirm that the barbecue documentation is poorly written.
However, the narrator doesn’t find anything particularly wrong with the instructions except a sense of disjointedness. The narrator explains that instructions should be seen as one path through a task, not the only one. He then references a memorable quote in a Japanese bicycle manual: “Assembly of Japanese bicycle require great peace of mind.”
This leads the narrator to reflect on the importance of “peace of mind” in technical work:
Peace of mind isn’t at all superficial, really … It’s the whole thing. That which produces it is good maintenance; that which disturbs it is poor maintenance. What we call workability of the machine is just an objectification of this peace of mind. The ultimate test’s always your own serenity. If you don’t have this when you start and maintain it while you’re working you’re likely to build your personal problems right into the machine itself.” (166-67)
Here again we see the integration of eastern modes of thought on technology. The larger theme is to blend the rational and intuitive modes, the classic versus romantic. Start with peace of mind before proceeding through a step-by-step technical manual. Whether you’re writing documentation, fixing your motorcycle, or assembling a barbecue grill, you can’t always expect to proceed methodically in a step-by-step way through the task.
Bringing in another state of consciousness
Now let’s transition over to applying some of these ideas. As a technical writer, most of my work involves writing documentation for complex topics that are hard to understand (the reason technical writers are hired in the first place). I write API documentation for developers, even though I’m not a developer myself. Most technical writers find themselves constantly faced with complex information that they somehow must explain in a clear, easy-to-follow manner — even though they’re almost never the user, don’t have the same technical level, and can barely use the systems they’re documenting themselves.
As a technical writer, you’re frequently in an uncomfortable position intellectually — always trying to understand something that’s hard to grasp. Requests for documentation aren’t typically for obvious processes but rather for those processes or concepts users don’t find intuitive.
It’s hard to operate comfortably in this mode. This is why you see so many technical writers constantly posting on Slack and other forums — because sitting down to write something you don’t understand, which invariably requires a lot of learning, outreach, interfacing with others, information gathering, etc,. in short, some heavy-duty learning and mental processing, etc. — isn’t something we naturally gravitate towards. Only by the pressure of deadlines and other work demands do we produce text for these scenarios.
In these moments, I find it’s easy to get uneasy — to feel all balled up inside, to feel resistance in my brain in going down this broken, patchy road. Learning difficult concepts can be frustrating and test my patience.
To illustrate, see this video I took of my wife years ago as she struggles to cancel an Amazon order. She’d ordered some books on Amazon but accidentally selected an outdated address and was frantically trying to figure out how to cancel the order before the books shipped. In the video you can see her frustration and anguish at not finding the right information for the task. In this case, she was operating within a small window of time — working against a deadline — and the stress filling her body was palpable. Here’s the video: https://vimeo.com/3432290. And the post I wrote at the time: Emotional States of Computer Users in Times of Frustration. And
This same emotion can easily fill me when I’m trying to figure out a complex technical subject (to varying degrees), especially against a deadline. Reading Pirsig’s book made me think of another approach. He talks about following Quality as a guide, which is a way of saying to proceed more intuitively, with implicit knowledge. In many scenarios, there isn’t a step-by-step sequence to follow, as much as technical writers would like there to be one. There’s no clear path to go down. You have to feel your way through the solution, in much the same way I’m feeling my way through the ideas in this post. I know where I want to go, but I’m not sure how to get there.
There’s a certain peace of mind one needs to get there. You can’t arrive at a solution when you’re full of stress and frustration. This is why my wife, brilliant as she is, would probably not enjoy technical writing. She’s smart and accustomed to immediately understanding things; her brain processes and analyzes information rapidly. She scored 5s on all her AP tests in high school. But most technical writing scenarios aren’t ones where you quickly grasp how a system works.
To proceed with calmness, peace of mind, in the face of steep knowledge cliffs requires an attitude that is difficult to cultivate. But it’s exactly the state of mind that you need to cultivate to be successful as a technical writer.
Throughout the book, Pirsig advances the notion of Quality, which is similar to the Tao or Dharma. He also ties it to the Greek word arete, meaning striving for excellence/virtue. It’s not something you can define rationally. Yes, Pirsig writes about Quality for 400 pages without ever defining Quality, but this is because defining it would subvert the whole notion of its undefinability. To define Quality would mean to subject it to rational dissection and logical explanation.
Despite the lack of a definition, you know it when something exudes quality — perhaps when it works seamlessly, is delightful, when it produces some end result you want with little effort. Quality’s very nature is to be outside rational, logical dissection — just like with writing, you can try to dissect why an essay resonates with you, but when you attempt to pinpoint the reasons (the flow? the reasoning? the imagery? the language choices?), you can’t say why the combination of different techniques and aspects yields the result it does. You just know intuitively.
To fully follow Quality, Pirsig says you have to clear your mind of previous assumptions and start to see the world anew. Reason being, we tend to operate with a priori filters that define the selection of facts and details we observe around us. This can keep us trapped in cycles of misunderstanding. When you’re troubleshooting, you must clear your mind of these assumptions and let Quality guide you intuitively through the solution.
Cultivating this state of consciousness is something I want to learn to do. The whole idea resists a specific process, making it difficult to model. But I’m going to try some experiments.
Experiences trying to cultivate a peace of mind
Last week at work, I tried to cultivate this peace of mind before starting a documentation task. I had to document a new feature for an API. Developers were implementing a new parameter that would change the responses they received from the API. Rather than continuing to build on the old way, the team needed me to document this new parameter and approach. I loathed having to learn a new way of using the API — didn’t the old one already work? The old parameter made sense. I didn’t know how much documentation I would need to rewrite.
Recognizing this inner frustration, I tried to slow down and cultivate peace of mind. I didn’t want to get all caught up in stress and trying to grok the new method quickly to crank out the new docs.
With this peace of mind, I calmly gathered up some engineering documents and started reading them. I deliberately tried to go slowly rather than hurriedly. After 30 minutes of reading, the new method came more clearly to me and it became easier to understand. I started pulling out details here and there into a text document, and after a couple of hours, that initial state of not knowing something and feeling hostile towards it dissipated. A new paradigm started to come into focus.
Before the afternoon finished, I’d written the documentation for this new feature and later had the whole bit reviewed, with few changes before submitting it. I even used Bard to kick out a first draft and easily shaped and edited it because I had a newfound understanding of the parameter and response.
Granted, this documentation task was a simple use case. But each day this is what technical writing consists of: bending your mind around some new detail. Some concepts are harder to learn than others. Mark Baker describes this kind of learning as rearranging your mental furniture:
In the end, learning is about rearranging our own mental furniture, finding our way through the thickets of our own minds. The expert can help us enormously at certain key junctures in that process, but most of it we simply have to do for ourselves. (Chatbots are not the future of Technical Communication)
A better metaphor might be reimagining and re-organizing where everything is placed in your kitchen (making it impossible to unload the dishwasher). The rearrangement can be painful. Just like chatbots can’t always deliver easy answers, sometimes the learning requires one to internalize new understanding.
Technical writing can be an experience involving some mental anguish. Zen and the Art of Motorcycle Maintenance mostly focuses on motorcycle maintenance as a concrete example in which to apply intuitive thinking. Pirsig describes his mental process, noting that you can’t always proceed through a series of steps to find the solution. You can’t blindly follow a sequence of steps to troubleshoot. You have to cultivate inner calmness and learn to clear your mind, slow everything down, and learn to see details that you’re missing. He says:
“What you have to do, if you get caught in this gumption trap of value rigidity, is slow down…you’re going to have to slow down anyway whether you want to or not…but slow down deliberately and go over ground that you’ve been over before to see if things you thought were important really were important.”
If you’re stuck, that’s okay. This is a state that precedes understanding:
“Stuckness shouldn’t be avoided. It’s the psychic predecessor of all real understanding.”
The book isn’t about motorcycle maintenance. “The real cycle you’re working in is a cycle called yourself,” the narrator says. “The machine that appears to be ‘out there’ and the person that appears to be ‘in here’ are not two separate things. They grow toward Quality or fall away from Quality together.” The motorcycle could just as easily be ourselves or a technical document we’re working on.
Troubleshooting a stuck wheel
Although it’s been 30 years since I rode motorcycles, I regularly ride a bicycle to work. The other week my back wheel wasn’t turning properly. I couldn’t figure out why, but it didn’t seem to spin around the axle smoothly anymore. Rather than just take my bike to the shop, I decided to have a go at troubleshooting it myself. I sat down and tried to cultivate some peace of mind. I started by loosening screws in my hydraulic disc brake to see if maybe the disc brake pad had become tilted or repositioned in a way that was slowing the disc. It wasn’t.
I took a few deep breaths and decided to remove the back tire and examine the axle. I removed the quick release lever and spun the wheel. I got out some cone wrenches and first tightened the cone nuts, then loosened the cone nuts. I took one of the cone nuts off and put it back on. Then I put the wheel back on my bike, and somehow, the wheel spun freely now.
In the process of tinkering with my disc brake, I also realized that I’d loosened let hydraulic mineral oil drip out of a loosened caliper bolt, making my brake go slack. So that’s something I’d need to fix later. But I was floored that I’d avoided getting frustrated in troubleshooting and was able to approach it with peace of mind, going slowly and intuitively. I didn’t proceed methodically, moving through a sequence of troubleshooting steps listed in a manual to fix the problem. I just sort of looked at the bike and tried different things, taking components apart and examining them on my own to look for problems.
Alternating modes
In relating this, I’m not saying intuitive thinking avoids reading the manual or omits rational processes. Troubleshooting might very well involve reading the manual, but it will most likely involve naturally moving between the manual and intuition as you interact with the machine. In research on how people use API documentation, researchers have observed that people proceed this way. Some might start by reading the manual first (a behavior they call “systematic”), others start by experimenting first (an “opportunistic” behavior), and others bounce back and forth between the two (hybrid behavior). I think hybrid behavior is the most common pattern.
But the larger point is that there’s not a set list of steps to follow: you might start out with one approach, find yourself pulled into the manual for a while to better understand the system, and then continue on tinkering. Then when you hit another obstacle, you might go back to the manual again. Or maybe by reading the manual you learn something new and decide to try it out. The movements are fluid and you’re guided by implicit knowledge.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.