Zen and the Art of Software Maintenance pt 2
Welcome to the second part of my summary of the concepts of Zen and The Art of Motorcycle Maintenance by Robert Pirsig as they apply to software development. You can read the first part here.
In the book Pirsig outlines a motivating force he defines as “enthusiasm.” In the previous post we covered external forces (or “setbacks” as Pirsig calls them) that can erode your enthusiasm for a project over time. Today we’ll be covering internal forces (or “hangups”) that can drain enthusiasm.
The first hangup is the value trap. This is where you’re convinced that all the symptoms of a problem point to a single cause, which just so happens to be incorrect. Pirsig recounts one such instance where his motorcycle sputtered to a stop. Confused, he sways his motorcycle side to side and confirms that there is still gasoline in the tank. This leads him to believe that he needs to replace his spark plugs. In reality his main tank was out of gas and the sloshing he heard was the fuel in his reserve tank, which he had not yet switched on. In software this is more commonly known as a following a “red herring.” The fix that Pirsig recommends is to just stop and stare at the problem for a while. Write down everything you observe and start the diagnosis over from first principles.
The second category of hangup is ego. A quote that particularly stuck with me was “a mechanic who has a big ego to defend is at a terrific disadvantage.” This is because the troubleshooting and solutions of these mechanics becomes an extension of their ego, which they then strive to defend even as evidence contradicting their conclusions begins to accumulate. This makes them incredibly susceptible to the value trap mentioned previously. The fix fortunately is pretty simple: humility. Even if you aren’t naturally a humble person, at least pretend to be. Basically “fake it until you make it.”
Anxiety, unsurprisingly, is the third hangup. This is so common in software that we even have a specific term for it in the industry, “imposter syndrome.” The symptoms of the amateur motorcycle repairman are remarkably similar to the amateur software developer. You become so intimidated by the prospect of making a mistake or appearing incompetent in front of others that you don’t even start. The fix Pirsig recommends is study. Read the documentation. Take handwritten notes summarizing what you’ve read. Type your handwritten notes out into a digital format. Rephrase your notes and turn them into a blogpost explaining them to others. Then write presentations about what you’ve learned and give technical talks at software conferences or to coworkers at your job. If you can’t tell already, this is something I’ve been doing for years now with this blog. I’m naturally a pretty anxious person, bristling with nervous energy. By harnessing this energy in a constructive fashion I’ve found that I can replenish my enthusiasm much faster than I would otherwise.
On the polar opposite end of the spectrum from anxiety is our next hangup: boredom. Developers (and mechanics!) who have been at the same job for years often struggle with this problem. After seeing the same problems day in and day out they just get to a point where they can’t be bothered. This is natural. Humans in particular and animals in general are drawn to and driven by novelty. Pirsig’s fix is to take a break. Drink some coffee. Take a walk. Oftentimes afterwards you’ll be able to come back the problem with fresh eyes. The other solution is to make a ritual or habit of boring tasks. I do this with my workouts. I don’t particularly enjoy running or lifting weights. So every morning the first thing I do after waking up is to do my workout. After doing this for years it now feels wrong if I _don’t _workout.
The final hangup Pirsig covers is the truth trap. The inventor of quicksort and the ALGOL and Occam programming languages, Tony Hoare, called this The Billion Dollar Mistake. Pirsig explains it by recounting a Zen koan: “One day a troubled monk approached the Zen Master Joshu intending to ask him for guidance. A dog walked by. The monk asked Joshu, ‘Has that dog a Buddha-nature or not?’ The monk had barely completed his question when the Master shouted ‘Mu!'” What the master meant by this outburst was that the monk had fallen into the truth trap. The monk had framed the question as a true/false dichotomy, when no such dichotomy actually existed. This is effectively the real world example of the programming NPE, or Null Pointer Exception. The solution is to realize that the real world is more than ones and zeroes, trues and falses. Many programming languages have this concept built into them now, whether it’s Javascript’s or Python’s “truthy” comparison, or Swift or Kotlins optionals. To overcome the truth trap you have to understand the philosophy behind these tools and use them as appropriate.
That sums up the internal and external motivation traps that mechanics and software developers alike can experience on a day to day basis. Pirsig himself admitted that these traps and their fixes are are in no way comprehensive and in their totality are really just a collection of gimmicks. The ultimate secret for being a good programmer (or any skilled profession for that matter) is to continually care for and pursue Quality in the work that you do. I hope that you find these reflections helpful in your own career. Until next time!
Photo by Mufid Majnun on Unsplash
comments powered by Disqus