Challenges of pair programming

Today was my first difficult day. I feel like the pairing experience is what made it difficult, because looking back, the concepts we dealt with today were not significantly harder than others I’ve encountered. This isn’t to say that it’s either my pair’s or my fault, but I think that looking back on the day I can identify some of the reasons why the experience was stressful and what might help in the future. I realise I have been diarising my pair programming experience for a week now, and I have not actually written anything about pair programming itself. Most of this post will be about my experience today, followed by some more general observations.

When the day started, my pair and I discussed how we would work together, as well as how we were both feeling. We both agreed that while we would regularly swap the keyboard between us, both people would contribute ideas and suggestions as we went, compared to a more formal driver-navigator dynamic. The first half of the day was relatively productive, and we made steady progress through three exercises. I had covered these topics before the previous day, but had completed them far too quickly, so it was useful for me to go over them and think more carefully about what was going on and why.

After lunch it was my turn to drive, and the task at hand was to write a module to feed into a new class we were making. I was excited about taking this on, as I had skipped over this part of the assignment yesterday, and was looking forward to getting it working. I had thought I understood what to do initially, and that it wouldn’t take too long, however I found myself confused by the syntax I needed to employ when defining my methods and writing my test cases. This was compounded by the fact that I made some pretty basic mistakes when using hashes.

As a result, we both spent a lot of time feeling confused and trying to fix the problems we encountered when testing the module. I was trying to focus on thinking about the problem, but I was very conscious of the fact that there was someone else there, and that I hadn’t communicated to them well enough what I was doing up until this point. I felt like I wanted to work through the problem in my mind, but that I had the responsibility of explaining exactly what was going on, and keeping the other person engaged. What made this difficult was the fact that I did not understand myself what was going on. As a result, I did not explain my thought process clearly enough, even though that’s exactly what I needed to do. We got the code working but the whole process took about two hours.

Afterwards we were both drained and found it difficult to formulate the next steps. We took things slowly and I did most of the navigating. During this time I felt like things were going slightly artificially slowly, but that we were making some progress. At the end of the day it was difficult to concentrate, and we ended up abandoning the code despite failing test cases, as it would not have been productive to go on looking at them.

I don’t want to repeat today’s experience of pairing, but I’m also aware that it has taught me that pairing is not always an easy experience. Working through difficult concepts with another person is challenging, especially when it’s part of an intensive ongoing process. Below are some of the more general themes I have noticed in my first week of programming full time as part of a pair:

  • Talking through every element of my thought processes with another person has been different from what I am used to. In university I did most of my problem sheets as part of a pair, and we discussed the problems a lot, but there were still long periods of silence, where we thought the concepts through, and worked on our own solutions. I am pretty confident that pair programming is more useful than this strategy for developing useful pieces of software, but I’m less sure about which is best for my learning.
  • Pair programming is a great vehicle for teaching someone else as you write your code. I find this very rewarding, both when I am doing it, and when I am the one being taught. However I find it hard when neither me nor my partner have a clear grasp of the task at hand. When this happens, it’s often most useful to talk through and explore concepts together.
  • When you use a piece of code that works, but that you don’t fully understand, a conflict often arises between moving on with the task, and stopping to talk through the idea until you can both grasp why you used it. There is a balancing act to perform between these two options. Learning often takes place through picking up habits and noticing patterns, rather than stopping to dissect every concept. However I have in general always felt like I have learned something important about the workings of ruby from conversations when we have stopped to figure out exactly why we used a certain piece of code. When you’re both tired, this conflict becomes quite fraught, and it’s often a sign that you both need a break.
  • The feeling of wanting to grab the keyboard from your partner does not often happen, but when it does, it can be frustrating. It doesn’t generally arise from a desire for control, but from the feeling that either; I could explain my thoughts better in code than verbally, or that I want to experiment with some ideas and can’t give the answer in words right now.
  • Talking through your thought process as you go is very important, but harder than it sounds.
  • Taking breaks really help. I feel like a day of too much continuous coding isn’t good for productivity, especially in a pair. This is one of the reasons I am incredibly grateful for 2pm meditation breaks. The fact that they give us a break is just as valuable as the life lessons we learn from the mindfulness practice.
  • In general, I work faster in pairs than I do by myself. I think this could be for a number of reasons, such as: I spend much less time reading and thinking about the ideas I am using; I have the extra brainpower of another person to get through the work; I am less distracted and more focussed on the task at hand.


There are definitely lessons I can learn from the pair programming experience we had today. Potentially one of the most obvious things I can improve upon is to be more mindful of sticking to traditional driver-navigator roles. As pair programming is a relatively unfamiliar experience to me, I have found it interesting to experiment with styles of the roles each person takes. However in this instance I think that straying too far from a clear-cut balance of power in the pair was partially responsible for what made the day difficult. I also think it would help to focus more on talking through problems that we are both finding challenging, rather than attempting to independently reason through them.

Pairing is a great way to collaboratively program for many reasons; it facilitates learning, communication and knowledge sharing, and it improves code quality by ensuring that both programmers question their decisions and hold themselves to a higher standard than they may have done independently. By experimenting with styles and getting a range of experiences of how pair programming can work, I am learning more about it, and I am looking forward to more effectively using pair programming to improve my standards and understanding.