Perhaps you are a programmer, or you work in the software industry. If you are reading this blog, it’s pretty sure that you have some interest in meditation or buddhism. If these statements are true for you, then it’s also quite likely that you’ve heard of Christian Grobmeier, his blog, and his 10 Rules of Zen Programming. His book The Zen Programmer, which has grown out of his programming, his blog and his practice, is a personal story of burnout and recovery. It describes the kind of mistakes we can make in our programming careers, their consequences, and how we can find a new way of doing our jobs that does not require us to pay with our peace of mind.
This is not a very polished book from a stylistic point of view. The English can be a little quirky as the writer is a fluent but non-native speaker. I personally enjoyed hearing Grobmeier’s German cadences coming through the pages. The unexpected turns of phrase can even act as mindfulness bells to the reader. But for all that, the book does flow. It has direction and it engages from start to finish. All this without losing its sense of being a collection of blog entries. In part this is down to Grobmeier’s unpretentious language and his straightforward message. I imagine his writing technique is informed by the famously sparse nature of Zen aesthetics.
It will raise a smirk, or perhaps roll some eyes, to suggest that programmers live a dangerous life! We don’t fight fires (at least not real ones) or deal with armed sociopaths every day (though perhaps a few unarmed ones). But every occupation has its hazards, and software development is no different. Programmers work in abstractions. Not the standard everyday abstractions that we all lean on to navigate this world – but another layer again. In order to code, we push abstractions beyond a point that is normal, healthy and useful in everyday life. And because we do it all day every day, we are in danger of living further away from direct experience than most people. Grobmeier points out the various stresses and strains involved in working at the software coalface every day. Although most or all of them are common to other professions, he frames them in a way that software developers can recognise. And then he explains how these factors can lead to burnout.
After a few introductory chapters explaining what the author means by Zen Programming, the body of the book contains a great number of sections with high-minded titles but very practical content. Titles like Egoless Programming, You Cannot Separate Your Mind from Your Body and Karma Code might seem to indicate self-indulgent philosophical conjecture, but instead each of these headings is followed by some very simple advice that can be put into practice by anyone. Egoless Programming, for example, points out the difficulties of doing code reviews, and points out how much easier and more enjoyable this process would be if we could avoid identifying ourselves with the code we produce. Karma Code points out the dangers of hiring ‘brilliant jerks’ – something every developer (except perhaps ‘brilliant jerks’!) can relate to.
The book closes with a section that reiterates Grobmeier’s original post on the 10 Rule of a Zen Programmer. The ‘rules’ combine productivity advice of the kind you will find elsewhere (Focus, Keep a Clear Mind), tips on how to stay mentally healthy when practicing software development (There Is No Career Goal, There is No Boss) and some salutary warnings on how not to be a pain in the ass for your colleagues (Shut Up, There Is Nothing Special). Each one has value and they complement and balance each other nicely.
Zen Programming can be practiced without becoming a buddhist, or learning the bamboo flute, as the rules stand up to secular scrutiny and are accessible. I believe that the more developers who grasp Grobmeier’s message and put it into action, the happier and more productive our work environments will become. And for this reason, among others, I recommend this book.