Zen and the Art of Software Engineering
As part of my on-boarding as software engineer at Nuvi, I had the opportunity to read the classic book Zen and the Art of Motorcycle Maintenance: An Inquiry into Values by Robert M. Pirsig. While the book delves deeply into abstract philosophical concepts, there were a number of concrete principles that I felt had direct application to writing high-quality software.
The efficacy of a machine
Pirsig points out that a machine (or system or tool) really has no inherent efficacy; but rather its efficacy is measured by how satisfied we are with it. I thought this was a compelling point of view because it provides us with a useful measuring stick for our software. For example, I could build a beautiful UI that I believe to be streamlined and intuitive, but if our users have different needs, the tool is not effective for them.
This also applies to developers as they build the software. The book discusses how the true artisan is actively involved in their work, being one with the material (the tools, technologies, and code), and has peace of mind when producing good work. If there isn’t peace of mind, it could be a sign of subpar work or an ineffective environment.
Being stuck isn’t a bad thing
An eye-opening point brought up in the book is the idea that being mentally stuck is not a bad thing. It’s so common in day-to-day software work to run into roadblocks, and they are justifiably seen as annoyances that keep engineers from their goal to deliver software. However, these roadblocks provide opportunities for creativity—to think “laterally” as Pirsig calls it—to find new solutions and to innovate.
Gumption is psychic gasoline
Though nearly 40 years later the word “gumption”—defined as shrewd or spirited initiative and resourcefulness—seems somewhat outdated, it accurately describes the creative fuel we need to produce quality work. We should work to ensure that our proverbial tanks of gumption don’t deplete. Pirsig dedicates a significant amount of time in the book to discuss the sources and drains of gumption. These are the ones that stuck out to me:
- Don’t try to regain gumption by working furiously to make up lost time. It doesn’t work for motorcycles or for software.
- Sometimes making your own motorcycle parts will build gumption. In the software world, I think of this as finding and building the right abstractions in code.
- Ego is a gumption trap. So is anxiety about failure.
- Bad tools are also a gumption trap.
Creating quality work is an all-encompassing act, requiring conscious effort that is more often focused inwardly rather than on the work itself. To adapt Pirsig’s own words: “The real [software] you’re working on is the [software] of yourself.”