As a software engineer, the thought of breaking bones in my hand makes me wince. It's a worst nightmare that I'd really rather not think about. Apart from the pain involved, my hands are the essential conduit that I use to manifest my ideas as code. As I approached a fallen tree at full speed on my bicycle on the commute home, this was the farthest thing from my mind. Moments later, my body lighting up with pain after hitting the trail hard, I knew without a doubt that my hand was broken. Little did I know that this would be the start of a great discovery.

Broken Hand

A week later, after surgery to immobilize my fifth metacarpal in my right hand, I began to consider my options. With a splint immobilizing my wrist and fingers, typing was not really feasible. When I reached out to my team for ideas, I was excited to find out that they were game to try pairing in earnest. This came as both a relief (I might be able to contribute after all) and a slight sense of apprehension. Would two of us as a pair be as effective as one? What would my pair buddy think of my approach, my way of thinking? Having a broken hand was a great forcing function to push me past these inhibitions, so we jumped in with both feet.

Ryan and I chose a story to work on that seemed small enough for an experiment, but had enough complexity to be interesting. We paid attention to some of the small details before starting, so that we would be free to focus on the problem at hand. We agreed on suitable space, chairs that met our personal preference, and a space where we would not be interrupted. We also spent a few minutes discussing the epic, the story, and agreed on an approach before getting started. Finding a starting point that we could agree on was an essential element to kicking off the coding effort.

Ryan agreed to be the driver (that choice was really made for us) and I was to be the navigator. This idea of driver/navigator was new to me; I had always assumed that pairing would be performed with each of us having the same role but only one with control of the keyboard. It turns out that differences in roles actually help, with the driver thinking more about the mechanics of the code and the navigator thinking more about the overall strategy, the implications of what we were doing and what was likely to come up next.

As we proceeded with coding I was surprised at how little time it took for us to get used to each others styles. I was expecting quite a lot of friction, assuming that we'd each want to approach the problem differently. Within about 30 minutes we hit our stride and we were making great time.

As each commit rolled off the keyboard, Ryan pushed the change up to our Gerrit code review server. Normally we'd spend quite a lot of time reviewing each others work - but since Ryan had written this code with my input, as a team we agreed that the pair could +2 the review without anyone else on the team having to comment. I reviewed Ryan's code, which really felt like a formality at this point. It felt good though to double-check our work before merging it.

As the story moved closer to completion, progress was really fast. As ideas came to us, we discussed trade-offs and explored alternatives. We each caught mistakes as they happened, and noticed tests that should be created. The flow of thought was fast, and the context for these discussions was always present - there was no need to bring anyone up to speed for a discussion, nor was there a need to interrupt a team member in order to discuss an idea. The flow of ideas was natural, and the code evolved much faster than I expected.

The most obvious potential pitfall of the pairing approach was that it was possible to miss knowledge sharing with the rest of the team. Discussions happen very quickly in a pair, and it's not always obvious to others how decisions were reached.

The result of our pairing was that we completed a story and the related epic within two days. This kind of speed was unexpected (to me at least) and very satisfying. Both Ryan and I came out of it with a smile on our faces. Not only were we productive and effective, it was great for morale and created a shared sense of achievement.
I'm now well into the healing process and with a smaller splint can use the keyboard effectively. Despite being able to code again, I don't think I'll need a broken hand to continue pairing.  And yes, I highly recommend it - not breaking your hand, but pairing - it could be the start of something great.