Culture of Pair Programming

March 29th, 2014

Now in the third week into the DBC pre-prep phase, I've had the opportunity to pair program with other cohort members 5 times, and wanted to write down a few thoughts on the value of the activity.

Go Solo or Play in a Band?

To start off, pair programming is one of those kind of activities that if you choose not to do it, you probably would do fine. There are many programmers out there that program solo and make some great software. But if you do choose to try pairing, it has salient yet immense benefits to expand your breadth of knowledge with help from others. It's just really hard to realize the benefit unless you really do it.

I like the analogy of music to explain - although one can really excel as a solo guitarist or vocalist, they could alternatively learn some new tricks or grow in different ways by forming a band together and interactively collaborating with them. And most times the end output will be wonderfully vibrant because that interaction happened. The challenge of course, is that some bands work together better than others, and there is definitely a test of patience when there is a gap in skill/experience.

Benefits and Rewards

In pair programming, it is common to split up responsibilities between a "driver" and a "navigator". There are various interpretations to what exactly each role does, but I generally think of a driver to be the person actually coding, while the navigator focuses more on the story telling and narrative of what to code along the way. The right path to go can be an open collaborative discussion between the two along the way.

The particularly fun or redeeming aspect of this kind of collaboration is, that by doing this a few times it will be apparent that there are so many ways to solve a problem. Even for solving the same problem in different rounds, by changing who you pair with or which driver/navigator role you play, you might come up with a completely unique solution that wasn't apparent from the previous round. This is a very powerful reward that you would not get by going solo.

Patience is Key

After pairing up a few times, I have noticed that it may be easy to fall into trap of frustration when there is a gap in understanding of subject matter or skills between partners. Luckily, I have not felt this yet myself since I'm on the learning end, but I could easily imagine this problem bubbling up if I paired with a brilliant programmer in a different league than me. The only thing I can say to this is that regardless of expertise/skill, both sides of the pair should be patient in working together, and see the gap as an opportunity to learn new things. Regardless of skill, I feel like there is always something new to learn in either driver/navigator role, whether it be coding more efficiently or narrating the story in a different way.

Feedback and Criticism

To get the most out of pair programming, you have to really be prepared to get the fire hose as far as feedback goes. On one end, you want to foster a good trust relationship so your partner feels comfortable in providing feedback. On the other end however, that also means that you have to be really prepared to receive it, and that is sometimes challenging to not take personally. I definitely had two specific moments where I had some trouble processing some feedback no matter how good the intent was, because it felt too candid or I unconsciously took it too personally.

The common understanding is that feedback should be Specific, Actionable, and Kind. Specifically for 'kindness' - there are many ways to interpret what kind means, but my interpretation is that the most kind feedback is where the giver doesn't go in with expectations that the person 'should' or 'must' change just because the feedback was given. I think this is a very important principle - for example, I would not expect someone to change their belief system or religion just because I gave them feedback that their system had a lot of drawbacks. I would just want that person to at least understand my perspective, and let them decide for themselves.

So in closing, to prepare the mind to receive whatever feedback comes your way is very important as a receiver, and understanding that it's the receiver's choice to decide how the feedback should be applied is important as a giver. I think this mental approach makes feedback more useful, and allows the pair to avoid falling into the trap of generating unkind criticism or pushing personal views - which are not really the objective of feedback in the first place.