Reflections on a Week of Pairing

This week was the first time I’ve pair programmed all day every day for a week, since Makers Academy. I thought it would be worth reflecting on the process, to try and gain some insight on how I approached it, what I did well and what I think I could have done better.

I think the most obvious thing to state is that it was a tiring week. Pairing is remarkably demanding. I think both Mollie and I recognised this sensation. I think that the difficulty in the process comes from the time that is spent with your brain fully active. There is less room for your brain to wander when pairing.

In a typically solo coding session, my brain will tend to wander occasionally, it will slow and accelerate depending on the ease of the problem being solved. I’m also pretty sure that is by design, the brain will tend to wander when it needs a break.

What I cannot quite work out is why certain types of focus are not comparable in terms of inducing tiredness. By way of example, I have spent in the region of 8 hours this past weekend, trying to find a way to fix my TTT test suite. After introducing sessions to the controller, it broke all my tests, and seemingly there is no way to fix them easily. During that time though, my brain was frustratedly focussed on solving the problem. The sensation I felt here was not tiredness, since seemingly an unsolved problem will actually prevent me some sleeping, but probably more frustration that I could not make progress.

In pairing then, I have while writing this, considered what might be the cause of increased brain activity. My thoughts are drawn to peoples differents ways of thinking. When pairing, not only do I need to try and solve the problem at hand, but also (as a good pair partner) I need to listen, consider and understand my partners idea’s for solving the problem. It’s almost like solving the problem twice. It’s necessary to recognise at this juncture that, the multiple solutions to the problem are in fact the key reason why pairing is productive, and why the final solution is typically cleaner, and better.

Assuming then, that I’ve now talked about tiredness for long enough, I’d like to talk about the other aspects that are more relevant to being a good pair partner. Sarah’s recent talk spoke of 5 principles of a dysfunctioning team. I think all of those principles can be applied to pair partners as well, I’d like to touch on them in the ways I think they are most relevant. Trust is required to allow pairing to function at all, without trust each person is essentially coding solo. Conflict, as I’ve alluded to above is the source of the best results, but also the most difficult part to endure. The key to managing the conflict of opinion is to be commited on the results (code). That last sentence really touches on two parts of the pyramid, but I think in this case they go hand in hand. Finally, accountability, I’m struggling to think of how to apply this, since in a pair both people are accountable of the output. So it’s tough to frame this from the perspective from one partner to the other. Perhaps then it’s fair to say that, as with a focus on results, both people should hold themselves and each other accountable for the output, in order that neither person feels as though a decision they make (right or wrong) will come back to bite them.

It has been great to get back into pairing, I’m learning a lot from a technical perspective, but also from a human one. I am going to work this week on improving the way I communicate, how I listen and respond, and how I explain my opinions. I’m convinced theres a lot of room for improvement, and hopefully it will improve the output of my next blog post!