I'm feeling philosophical today, so rather than sharing with you some advice on solving a particular problem, I'm going to touch on why I think Pair programming is fantastic, and how English Comedian John Cleese helped convince me. As you are presumably aware, Pair Programming involves one programmer who drives and one who observes, critiques and thinks ahead. The advantages of this style of development are said to range from increased morale to increased code quality at the expense of development time. But why?
I had always attributed the increase in code quality to the simple explanation of "two sets of eyes are better than one". Perspective surely helps you spot mistakes and come up with more optimal solutions; a common sense anecdotal conclusion that lends itself to encouraging the use of Pair Programming. However, after watching John Cleese - a lecture on Creativity I came to realise that the Pair Programming dynamic is in fact rooted in the fundamentals of Human Creativity, and that it is to an extent, a necessity for the development of great software.
I'd encourage you to go ahead and check out the video as I think it is an essential watch for anyone. However the point I'd like to hone in on is Cleese's idea of the "Open" and "Closed" mental modes. The Open mode being a state of mind in which creativity is possible and the Closed in which is it impossible.
Cleese describes the Closed state as a mode in which we are focused on a task at hand. In this mode we are purposeful and determined but cannot be creative. He goes on to describe the Open mode in which we are less focused, more relaxed and as a result more inclined towards curiosity, playfulness and as a result, creativity.
In his discussion he concludes that both modes are a necessity for any creative pursuit:
We need to be in the open mode when we're pondering a problem but once we come up with a solution, we must then switch to the closed mode to implement it. Because once we've made a decision, we are efficient only if we go through with it decisively, undistracted by doubts about its correctness.The truth of Cleese's take on creativity can easily be observed in the creative pursuit of Software Engineering.
I often find myself completely zoned into a task, eyes glued to walls of code and headphones blasting my favourite Meshuggah track. Although this state of mind is fantastic for productivity, I've often found that being so focused has allowed me to lose awareness of the big picture and how my changes propagate through a code base; sure signs of being sucked into Programmer Tunnel Vision. In this state we can quite easily make questionable design decisions or introduce bugs that are overlooked in the shadow of a successful current task.
Thankfully at Orion Health, we're pretty strict with Code Reviews. I've often shown a supposedly complete task to a peer only to find my relief shattered by their observation of a new edge-case to test, a scenario I didn't think to cover or the potential for a bug, leaving me wondering how in the world I even began to think that my work was complete. Similarly, I've often found myself dishing out a grilling at code reviews, often spotting issues that seem very plainly obvious.
Going back to Cleese's mental states, we can see that the concept of a Closed mode marries quite well with the idea of Programmer Tunnel Vision. Staring at a screen and blasting your ears with Death Metal seems to work wonders for productivity at the cost of not always asking the "what if" questions and considering the alternatives. Being in a mindset of productivity makes it difficult to be creative. However, casually strolling over to a colleague's desk and discussing their latest code commit seems to fill you with a million constructive questions and thoughts about what their solution may lack. Being in a relaxed mindset free from pressure allows creativity to flow.
It seems the ideal Super-programmer would be able to zone in to a problem and zone out to the big picture at will, switching between the Closed and Open mental states to facilitate the optimal balance between unadulterated focus and playful creativity.
From here, we finally arrive at the point. Pair Programming facilitates exactly this by separating the zone in from the zone out using two developers. The Driver is afforded the freedom to focus on the implementation of a problem, while the Observer is afforded the freedom to consider the big picture.
As a driver I've found silly mistakes and misunderstandings cleared rapidly with a second pair of eyes looking over my shoulder. I've found the observer realising issues with my designs that result in complete changes in direction. As an observer I've found myself constantly considering how the driver's changes propagate and what alternatives to consider. Where the driver focuses on the implementation of the solution, the observer can sit back and let their curiosity do its work.
Pair Programming allows for the creative pursuit of Software Development to occur simultaneously in the Open and Closed mental states.
In addition to now having a deeper understanding of my many creative pursuits, watching John Cleese's presentation has solidified my advocacy for Pair Programming. I cannot speak for the exact situations in which it is practical and which pairs of colleagues would make great Pair Programming teams. Perhaps that's a discussion I'll return to in a future blog post. However, understanding its effectiveness in terms of the fundamentals of Human Creativity makes me think it should be exercised whenever possible. At the very least, Code Reviews should be mandatory. Although they may not be as thorough, Code Reviews do allow for the same relaxed mode of thinking for an onlooker.
That's it from me today! Be sure to check out John Cleese - a lecture on Creativity in full for more invaluable perspective on creative and professional environments,
Cheers,
Shrek
