Reflections on pair programming [Part 2]

Over the last five weeks, I have been learning to code at Makers Academy. Every day of these five weeks has been spent pair programming, which is where two people work on the same piece of software. One person plays the role of ‘navigator’; giving direction and dictating the strategy, and the other plays the role of ‘driver’; typing out the navigator’s instructions. Both partners ensure to swap roles at regular intervals, normally when a set of tests passes. I wrote up some of my thoughts on pair programming a few weeks ago after a difficult day, and I wanted to take pause again to give an update on some of my more recent feelings on this style of working.

I was discussing this topic with my pair partner earlier in the week, who remarked that pair programming seems to have been somewhat of an elephant in the room for our cohort. I am inclined to agree. There has been a lot of discussion about how we are coping with the challenges, how we are getting on with the people and our thoughts on specific new technologies we have learned, but little-to-no discourse on the style of learning. I believe there is a lot to be said here, so below I will outline some of the principal takeaways, pros and cons I have personally felt while pair programming over the last month.

Last week we studied databases, which involved getting accustomed to a lot of abstract and complex ideas very quickly. One particular example I remember is discussing join tables with my pair partner. We both understood this to some degree, and I found it useful to explain and diagram how I envisioned them working. It turned out that the inbuilt solution DataMapper provided for this was different to the ideas we had discussed, and it took some time thinking and experimenting to build up a mental picture of how this worked. Understanding this took a lot of mental effort, and I found myself at times expending more effort on thinking through this problem than providing the clearest explanations to my pair partner. I hypothesise that when a week’s task involves learning many complex ideas in a short amount of time, a good approach would be to require students to explore the ideas involved before pairing over a project, or at least taking some time to experiment on their own in addition to time spent pairing.

This week has been dedicated to learning Javascript, and in particular, to rewriting one of our challenges from three weeks ago in Javascript. Many of the tasks boiled down to identifying exactly what we needed to do (be it write a test case or function, or refactor the code), and needing to find a specific piece of syntax to do it with. Pair programming is in general well suited to working out a problem in your brain with the help of a partner, however I found it quickly became tedious for both parties when the task at hand was reduced to finding the exact order of commands to use.

When our program was a little more developed and we were using on the web via a controller, we debugged and troubleshooted via the console using Google Devtools. This turned out to be a trying exercise in itself, as it often involved instructing your pair partner to make very small changes to the code and specifying exactly what you wanted them to type symbol-by-symbol. Debugging is often more fiddly than writing code, and a process that involves being sensitive to getting feedback very quickly and repetitively to small tweaks that you make to your code. In the case of debugging via the console on Devtools, it took a lot of effort to overcome the inbuilt social mechanism telling me to not be annoying and repetitive in order to give directions that would help to solve our problem.

Despite these downsides, I have found pairing an overall valuable experience. One of the key benefits that I feel has presented itself every week has been the value of explaining new concepts to your pair partner. When we learned databases it was helpful to talk through the structure and diagram out the relationship between the database and the model with a partner. When learning Javascript, it was valuable to be able to explain new concepts to each other, especially when completing tasks that were new to only one of the pair partners. Had I not had the opportunity to talk these ideas through with another person I am very doubtful I would have learned as much, no matter how well I thought I understood them.

Another aspect of pairing I think has been particularly valuable has been that it helps foster creativity. When working on our JS Thermostat, by the end of the week most pairs had the opportunity to style their view independently, and use their imaginations. It was a great help to the creative process to be able to bounce ideas off another person who could answer every suggestion I had with another equally cool one. I feel that this aspect of pairing is going to reveal itself even more as the weeks go on, we become more confident in our coding ability and we take on more creative endeavours.


I think that the main difficulties I have found with pair programming boil down to one common cause: pair programming pushes you out of your comfort zone. Working with another person constantly ensures that your style of work and output is visible. This is not an easy experience for me, as I have often found it difficult in the past to work while being watched by someone else. I suspect that this facet of pairing is at the heart of some of my earlier concerns, and that my aversion to the more straining aspects of pairing stem from an aversion to being put in an uncomfortable position. I actually find pairing hugely valuable for this reason. Every Makers graduate I have spoken to so far has confirmed the idea that working full time as a developer involves communication and collaboration as a core part of the job, be in in code reviews, giving feedback or collaborating on a project. Improving my ability as a pair programmer will go a long way to improving my capability in these core skills. There is a lot to discuss and potentially to tweak in the methodology of using pair programming as a learning tool, but I’m going forward confident in the knowledge that it is making me a better developer.