Zen and the Art of (Pair) Programming

Since this book is so general, it can be interpreted in many different ways. I choose to interpret some of the advice it offers in terms of programming.

Programming is an intellectual activity. It takes sufficient intellect, great concentration and lots of patience. And there are some things that can easily sap a programmer's concentration and patience. Robert Pirsig, author of Zen and the Art of Motorcycle Maintenance uses the term gumption as a reference to the gasoline that motivates a person to continue working on what he needs to get done. And he calls the little things that retard the progress of work gumption traps.

Anyone who has done programming before is certainly aware of some gumption traps. When your IDE that has been working fine for the whole day suddenly starts throwing peculiar errors and exceptions, you feel infuriated. Or when you try to chase down a bug that prevents your program from working only to discover that you had somehow used a stale version of the source file and that the bug had already been fixed. It is not the encounter with these incidents that causes you to lose your zen as you are programming; rather it is your reaction to these incidents that cause the state of zen to be broken.

An anecdote would illustrate this better. Pirsig uses the South Indian Monkey Trap parable to illustrate this:

The "South Indian Monkey Trap" was developed by villagers to catch the ever-present and numerous small monkeys in that part of the world. It involves a hollowed-out coconut chained to a stake. The coconut has some rice inside which can be seen through a small hole. The hole is just big enough so that the monkey can put his hand in, but too small for his fist to come out after he has grabbed the rice.

Tempted by the rice, the monkey reaches in and is suddenly trapped. He is not able to see that it is his own fist that traps him, his own desire for the rice. He rigidly holds on to the rice, because he values it. He cannot let go and by doing so retain his freedom. So the trap works and the villagers capture him.

The normal reaction a programmer has for a gumption trap is to lash out and probably try to find the solution fast. However, like the case of the monkey trap, sometimes even when the solution is apparently within your grasp, you tend to forget that there could be a different solution. It takes a great amount of brain power (to use the cliche term) to perform a paradigm shift and try a different route even if the end goal is within your grasp.

As a concrete example, think of how many times you had fixed a bug only to realize that it was but a tiny manifestation of a bigger bug? Or that the bug that you are seeing could be a transient one that exhibits itself every 500 hours and that it would be better to provide some tolerance for it rather than trying to fix it?

Look one way and you see a duck. Look another way and you see a rabbit. Different ways of looking at the same thing requires a paradigm shift. And programmers need to be able to do this numerous times each day.

This idea of taking a step back from what you are doing to actually think about your actions is also highlighted in Edward De Bono's Six Thinking Hats. De Bono proposes six different colored hats: white, red, black, yellow, green and blue. The blue hat captures this notion that you need to be cognizant of the bigger picture and how to react accordingly.

Which brings me to my point: pair programming might help alleviate some of the gumption traps. After all, it is rather unlikely that two programmers with completely different mind sets would fall into the same trap at the same time. Having someone watch over your shoulders does prevent some rather embarrassing episodes of barking up the wrong tree since you now need to convince your partner to do the same.

Even if you do not have the luxury of having someone to pair program with, you can easily just keep a log of all the tiny mistakes or observations that you have encountered during your programming sprint. It's those moments of "a-ha" that seasoned programmers reflect upon to give them the edge over the newbies.

You can find more information about gumption from Chapter 26 of the book. It's a book that has continuation from chapter to chapter but you can easily grasp the advice that Pirsig dispenses by reading each chapter independently. Like I mentioned in the beginning, the book is general enough that you can interpret it differently and mould it to fit various situations.