What can a forty year old book about motorcycles teach us about being successful in the tech field? If the book is Robert M. Pirsig’s Zen and the Art of Motorcycle Maintenance (Amazon | Library), quite a bit.
The book, first published in 1974 in the wake of the cultural upheaval of the 1960s, presents a careful study of values and presents a roadmap for pursuing “Quality” in our thoughts and actions. Pirsig grounds his intellectual search for meaning and understanding in his approach to motorcycle maintenance, which he discusses during a motorcycle trip from Minneapolis to San Francisco with his twelve-year-old son.
While my experience with motorcycles begins and ends with one ten-second ride of my friend’s dirt bike directly into his fence when I was thirteen, many of the ideas in the book resonated with me. One particular section even provided a number of insights into my experience learning to code and building Booma: Pirsig’s discussion of Gumption Traps.
Throughout the book, Pirsig describes the advantages of becoming your own motorcycle mechanic, which are mainly that learning how your machine works and how to fix it provides deep satisfaction while riding it and your ability and knowledge provides enormous independence–not so different from the advantages of knowing how to build your own websites and write your own code.
Of course, like learning to code or building a complex project, learning how to maintain a motorcycle is difficult and full of potential pitfalls. Overcoming these takes gumption, but, as Pirsig explains, the process is full of traps that can drain your enthusiasm.
Like anyone who has ever jumped into a project bursting with enthusiasm only to later find her- or himself feeling completely defeated, I am familiar with many of these traps. I first began thinking about Booma as a project almost three years ago. Pursuing it has introduced me to numerous people in a wide range of fields, given me an opportunity to reconnect with old friends and former students, led me through a 10-week incubator in Tucson, encouraged me to learn coding for myself, given me the opportunity to lead an annual entrepreneurship camp for teenagers, and helped me transition after teaching English for 15 years into a computer science classroom. But, it has also required me to constantly reevaluate what I am doing and why I am doing it, and to overcome many of Pirsig’s Gumption Traps to keep going.
Pirsig identifies two types of traps: external traps, which he calls setbacks; and internal traps, which he calls hangups. Let’s first look at his three setbacks.
External Traps: Setbacks
In the book Pirsig describes the sinking feeling that comes when you have finished rebuilding a part of a motorcycle only to discover some piece that was not put back where it belongs. In coding this reminds me of the moment after you have dug into your code to fix some minor bug and realize that you have now completely disabled the entire project.
In this case, the first thing Pirsig recommends doing is taking a long break. The danger now is that you rush back into the work and make more mistakes. When you do return to it, slow down.
To avoid this mistake in the first place, work meticulously. When coding, subscribe to the rule of only changing one small thing–a line of code, a single function–at a time. If the change doesn’t fix the problem, change it back; check to make sure things are returned exactly to their previous state; then try something else. Have you ever been trying everything to fix some issue, finally discovered the exact answer you needed and implemented it, only to find that nothing happens? I have, and then realized thirty or forty painful minutes later that I had forgotten a semicolon or misspelled a word in an unrelated line that I retyped too quickly.
Pirsig also distinguishes between two reasons for having to rebuild a component. The first is purposeful–to test something, you need to make a change and then test it to see if it works. If it doesn’t, you go in, change it back, and try something else. This isn’t a misassembly trap because with each attempt you are learning something and making progress.
In the second case, when you just mess up, all is not lost either. Each time you take something apart and rebuild it you are memorizing all sorts of things that will make you more efficient in the future. I may have spent four hours one night trying to figure out why my map kept disappearing from a div before I realized I had accidentally removed the “width” declaration for one of the responsive screen sizes, but I never forget to set my widths anymore.
2. Intermittent Failure
This happens when you notice a problem–or more often in web development, someone tells you about a problem–but when you go to fix it, the problem isn’t present. Last year one of my classes helped redesign our school’s counseling department web pages. I have received a few messages now from one of the counselors mentioning the fact that our embedded calendar isn’t showing up when she visits the site. After each email I visit the site, and each time the calendar displays fine. If I can’t see the problem it’s hard to fix it.
Pirsig points out that this only becomes a Gumption Trap when you think you have solved the problem and then it reappears. His advice: don’t think that the problem has gone away until enough time has passed that you are absolutely sure it’s gone. As long as you don’t make that assumption, you are no worse off when the problem reappears than you were when it first appeared.
On a motorcycle, he attributes many of these problems to changing conditions on the bike: for example, an electrical issue might appear when you are riding down a bumpy road or when the machine is hot. In web development, these problems often occur because there are so many different environments–different browsers, different devices, different screen sizes–that can affect how a design element behaves. When diagnosing the problem, he suggests correlating the problem to other things that are present or happening at the time the problem appears; the same advice fits when diagnosing a tech issue.
3. Parts Setback
A major Gumption Trap when working on a motorcycle is not having the part you need to make a repair, or purchasing a part and then discovering that it is the wrong part. Pirsig goes into some depth about the nature of marketing and selling motorcycle parts that has little bearing on writing or deploying code. However, finding and picking the right tools–the coding language, a snippet of code, a third party app–are similar problems.
To lessen the risk of buying the wrong part, Pirsig recommends (1) finding the most cooperative parts person around and (2) bringing the part with you when possible, along with some machinist’s calipers to make comparisons. To be useful for us, this advice needs some translation: (1) Foster relationships with people who are knowledgeable, supportive, and articulate. I have asked for tons of help over the last few years, and some of the people have been patient and clear while others have for one reason or another led me astray. People in the former group are invaluable, so when you find them be kind, don’t abuse their generosity, and listen carefully to what they tell you. (2) Try to understand your problem or situation as completely as possible, and continually revise your understanding with new knowledge. I am sure we have all spent hours reading through answers on Stack Overflow slowly closing in on how to describe a problem before finding a useful answer. The better you can articulate your problem the easier it is for you to find help.
Let me throw in one more piece of advice when asking for help. In my experience, many people who have knowledge are happy to share it with people who are genuinely interested in learning, but, not surprisingly, they are wary of people trying to lure them into doing work. Asking, “Hey, can you build this for me?” is almost never successful unless you are offering some type of compensation; but saying, “Hey, I have been trying to figure this out and I keep getting stuck,” often leads to help.
Internal Traps: Hangups
Pirsig describes three Internal Gumption Traps–Value Traps, Truth Traps, and Muscle Traps–paying particular attention to the Value Traps, which he calls the most dangerous.
1. Value Traps
Value Traps almost always stem from value rigidity, “an inability to revalue what one sees because of commitment to previous values.” How many times have you been in a situation where you are sure of why a problem exists or what path you should take only to discover much, much later that you were completely wrong?
As we were working on the counselor’s web pages last year, the page layouts were a mess on some of my students’ machines. Content was overlapping and throwing sidebars out of line. The pages looked fine when I was logged into a lab computer or accessing them from my laptop, but on most of the student’s machines they looked terrible.
All year we had experienced design issues because most of our machines only have an old version of Internet Explorer, a browser that has an earned reputation for needing specific code to produce certain results, and most of our monitors could only support relatively low resolutions. We were using Bootstrap for the project, though, which should have overcome those earlier problems. Still, I was sure this was the cause, and in the back of my mind I began to panic. Almost no one outside the school would access the site with this version of IE, but most of our visitors would come from campus computers. I began to think we might have to write significant custom code just for IE, and I worried about how many hours I would need to spend unwinding the problem just to be able to explain it to my students.
In the end, luckily, none of this was necessary. There were plenty of facts that should have helped me see this–the site looked fine when I viewed it with Internet Explorer, Bootstrap was specifically designed to respond to different screen sizes and resolutions. I could not see any of those facts though because I already had a rigidly held belief about the cause of the problem.
Fortunately, before I spent hours beating my head against the wall, someone noticed that most of the students were accessing the site through an intranet address, rather than the internet address where I was viewing the site. When I had updated the links to the CSS files, those changes had not shown up on the intranet. Once I knew this, it was relatively easy to fix the problem.
This is what Pirsig means by value rigidity: our adherence to previously held values prevents us from seeing new and important facts. I had even suspected a CSS link issue early on based on the evidence but quickly dismissed it thinking it was probably the same culprit that has been causing trouble all year.
In this case, Pirsig’s advice is simple: slow down, go over ground you have already covered, re-evaluate what you think is important and what you think is not. If necessary just stare at the problem for a while, the way you might stare at a fishing line. Sooner or later you are likely to get a nibble from a new fact. Explore that fact–if the site looks good on your computer but not on a student’s computer, explore it. The fact might not be important, but make sure before dismissing it. And, even if it isn’t the fact you are looking for it might lead to the one you are.
If you become interested in exploring all these new facts, he says, you will become a motorcycle scientist rather than a motorcycle mechanic, or in our case a computer scientist rather than just a technician–a transformation that will completely overcome this Gumption Trap.
Value rigidity is such a common and dangerous problem that Pirsig even explores some underlying causes:
The Ego Trap: This situation occurs when your high opinion of yourself weakens your ability to see new facts and lessens your willingness to admit when you made a mistake. The solution is to be humble, even if you have to fake it until you genuinely learn it.
The Anxiety Trap: This one occurs when you are so sure that you will do everything wrong that you are afraid to do anything. It is often this reason, rather than laziness, that prevents you from getting to work.
This is the trap I suffer from most. When I look at all the things I want to accomplish with Booma, I am overwhelmed by all that I don’t know and am often confused at where to start the next step. Right now, for example, I am trying to set up my own database system to store information that users can access and edit through an interface–but I have so many questions that I just grope around the internet looking for ideas, then ask people I trust all the questions I have formulated, which only leads to even more questions.
Pirsig’s advice: work out your anxieties beforehand–read everything you can about the subject, write down your steps on little slips of paper (I prefer Workflowy), then add more steps as you think of them until you have a clear path forward. And, he says, remember that everyone makes mistakes, even the experts. It’s important to remember that every mistake is a learning experience.
The Boredom Trap: As soon as you notice you are becoming bored, stop what you are doing. Pirsig says you have lost your “Beginner’s Mind,” the wonder and excitement you had that you drew you into the process initially. If you proceed while you are bored, you are likely to make mistakes that will lead to other Gumption Traps, so go do something else for a while–get some sleep, drink some coffee, or attend to whatever else is distracting you from the task at hand.
The Impatience Trap: This situation is similar to the boredom trap, but occurs when you underestimate how long a job will actually take. When it takes longer, impatience is your first response to setbacks, which can quickly lead to anger and more Gumption Traps.
I understand this one too–when I started Booma three years ago, I imagined that by now I would have a fully functional site with tons of content, and I would be traveling the world talking about local literature; instead I’m trying to find time to write content for 200+ locations from Dante’s Inferno and hoping next summer I will be ready to build a system for user accounts.
Everything takes longer than we expect, especially when we are starting a job that is unfamiliar to us. Pirsig’s advice is to allow indefinite time for jobs when possible, or to at least double our time predictions when we must plan. Also, scale down the importance of overall goals and increase the importance of immediate goals, which will keep you focused on moving forward. If you feel yourself growing impatient, do some scaling down activities to help you refocus–clean up the indentations and spacing in your code, add comments, clean off your desk, find other minor aspects of your project that will benefit you down the road but aren’t pressing. Working on these can calm you down and make your life easier later on.
2. Truth Traps
Truth Traps are the result of how we’ve been taught to see the world in simple dichotomies–yes or no, black or white, one or zero. Sometimes when we run an experiment we receive an answer that isn’t yes or no. Pirsig uses the Japanese term “mu,” which translates roughly to “no thing,” to describe this type of result. Often, in this situation, we think that we have run a bad experiment and we don’t understand what is happening.
A “mu” result, however, means one of two things: “that your test procedures aren’t doing what you think they are or that your understanding of the context of the question needs to be enlarged.”
I can give a simple example. Because most of my coding knowledge has been self-taught, I sometimes have basic gaps in what I know. When I began setting up my first project page, I created a simple set of navigation buttons to move through the locations on the map. After some tinkering and with a little help, the buttons seemed to work except when I went directly to a location; then the advance button would jump randomly to another location rather then the next one in the sequence. Because I had dealt with some minor issues in using the modulo operator, I ran experiment after experiment, tweaking my formula but never understanding the results. Finally it dawned on me while talking through the problem with a friend that the issue wasn’t related to the mathematical operations at all but to the fact that in that particular case I was taking in a string type rather than an integer, which threw everything off.
Pirsig says, don’t throw away “mu” results; they are often the most important ones in helping you grow. Instead, check your tests and restudy the question.
3. Muscle Traps
Muscle Traps refer specifically to situations that block effective psychomotor control. Some of Pirsig’s examples refer to how an experienced mechanic learns how different materials respond to force and torque and so avoids ruining parts that a beginner might accidentally destroy. Excepting for the mounting screw that a colleague and I recently broke off in the back of a monitor, most times working in computer science doesn’t require a delicate physical touch. Gaining a sense of when a problem needs a big solution or just a little one, however, is equally important and can be gained through thoughtful reflection on our experiences.
Another aspect of Muscle Traps relates to your working environment. If it is too hot or too cold, it can be difficult to concentrate and easy to become angry. If we can’t find reference materials on a sloppy desk or concentrate in a noisy space, if we can’t review our code without constantly scrolling or see our results without switching back-and-forth between windows that don’t fit on a single screen, we won’t do our best work and can lose our gumption. Take some time to think about your environment and, as much as you can, make it a space conducive to doing quality work.
These are all the Gumption Traps that Pirsig describes, and I have done my best to translate them to the tech space, but as he readily acknowledges, there are countless more. In fact, I am sure that we could come up with plenty of coding specific traps that he doesn’t describe.
Recognizing the traps and actively taking steps to avoid them will make it easier to keep your enthusiasm as you learn skills and take on larger and more complex projects. Overcoming the Gumption Traps, though, is just one part of accomplishing anything. You still need to do the actual work, which is, as many of the solutions to these problems suggest, easiest when you are in the right mindset.
Pirsig’s larger point in this section is that you can’t be sloppy in your thinking most of the time and then expect to be sharp when you are working on your motorcycle. If you want to be good at something, you have to make yourself better in general. He finishes by saying, “What I am trying to come up with on these gumption traps, I guess, is shortcuts to living right. The real cycle [or project] you are working on is yourself. 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.”
If you think some of these ideas are useful, I’d encourage you to give the whole book a try. It is a worthwhile read for anyone who wants their work to be about more than just doing tasks.
And, I would love to hear about the Gumption Traps you have encountered in the tech or startup space and how you’ve learned to deal with them. Please share in the comments below, or send me an email at firstname.lastname@example.org.