The other day, I commented on how I had participated in my first proper pair programming session. Compared to the “pairing” session I had back in November, (where I was, more often than not, the back seat passenger instead of Navigator) this experience beat it hands down. As keen as I have been in the past to attempt pair programming, project constraints have never really been conducive to real pair programming. Luckily I had been preparing for this opportunity unwittingly by reading “Pair Programming Illuminated“. The book that Brett had kindly loaned me was an excellent resource for describing constraints that hinder and identifying techniques to improve pair programming practices.
Participants in pair programming can take one of two roles, and should be swapping relatively frequently. These two roles are:
- The Driver – The person who is currently driving the keyboard/mouse and translating the design into actual bits of code.
- The Navigator – The person who is currently analysing, commenting, discussing and providing constant feedback to the driver.
Anyone that has not experienced proper pair programming will probably not be able to understand how successful it can be. The book discusses how, although not everyone will be suitable for pair programming, it does not mean that pair programming will only work with the “right” people. Perhaps those who had a bad experience also had a poor environment to practice it in, or just may not have the personality to be able to work so closely with other people. Fortunately I had an excellent partner to code with for two days.
Successful pair programming can be easily identified by the synergy that is created when both the Driver and Navigator are interacting seamlessly, producing results that are better than would be produced by the two individuals separately. Although I tend to be pretty productive normally, I noticed a significant increase in both the quality and amount of the functionality that was written. Although I felt drained at the end of the day, it was not the drained feeling you get from simply being tired. Instead it was that feeling you get after triumphing over something, like after you reach the summit of a mountain or after running a personal best in a marathon.
It’s very difficult to articulate what made the session so successful. Perhaps it was the seemingly uncommon, yet natural way in which we just kept ticking off each bit of functionality so quickly, all while committing code that felt like it was continually improving the quality of the entire codebase. I think it would have been very interesting to observe our interactions throughout the session. For example, when I was the Driver, I would find myself explaining what I was doing and why I was doing it. I stopped writing the code if it didn’t make sense, or if the Navigator suggested we do it a better way. When I found myself not completely understanding the Navigator, we would swap and the same thing would ensue. I found that there was no fear (and should be no fear) to admit you don’t understand something that your partner is doing and get them to explain it to you. It not only improves your knowledge but if your partner cannot explain it, then it highlights that their approach might be flawed. It was all too easy to bounce ideas back and forth, eliminating bad ones and then staying on track to add it to the codebase.
I think this experience was made even all the more gratifying with our almost perfectly-textbook development loop. Working on a very specific bit of functionality, we would add the unit test, watch it fail, add the code to make it work (refactoring where necessary). We would then run all the tests (which were all blazingly fast!), commit the work and then repeat.