Chris asks “How do you pair?“, so here’s my top tips when it comes to pair programming:
Understand each other’s working styles
I like to understand how the person I work with prefers to work and I like to share how I like to work. Understanding each other’s preferences helps you not get frustrated when your pair needs to do something different. Some people like to draw diagrams (class/sequences), or use CRC cards, whilst others like to analyse the code. I know that I like to break things down into Tiny Tasks, so that I know when done is done. Make the implicit things explicit.
Relax, and count to 3
I tend to be a fast typist. I’m not saying this because I want to boast. I recognise that when I pair with people who don’t type as fast, I need to be patient when it comes to things like spelling mistakes and syntax errors. Nothing says, “I don’t trust you,” like a pair who is constantly nit-picking over these things when the other pair is still translating the design into code. I trust my pair for them to pick up spelling mistakes, and I wait for a long gap before I point out any of these. I recognise when I go to interrupt, and count to 3 in my head to give them some space. Sure, spelling mistakes are annoying, but they’re easy to fix and they’re not the end of the world.
Swap constantly
Swapping frequently enough creates a sense of shared ownership however swapping too frequently to start with can break someone’s flow. When I start pairing with people, I try to give them as much time on the keyboard, suggesting appropriate times to swap (end of test, end of a piece of major functionality). Ping pong pairing helps with this.
Ensure both parties understand *why* they are pairing
Pairing brings many benefits and I read a great book with fantastic advice when I first started pair programming. It’s difficult to understand why you are pairing sometimes, but think about if you are getting benefits from shared understanding, continuous code reviews, considering more than one design or onboarding someone new. If you are doing it by rote, then consider asking how you can link these benefits into the pairing activities. Without understanding why you pair, many people never achieve the results.
Recognise that pairing is not the solution for all problems
It bothers me when I hear, “we need to pair on this” without recognising what the problem is. Sometimes problems are better solved by the team, or a standard needs to be agreed as a team, not just as an individual pair. On the other hand, I don’t believe all tasks need two people sitting there doing things such as reading documentation, or scouring the interweb for an answer to some problems. I think it often takes another level of awareness (that many people don’t make) to know when to pair and when not to pair. Understanding why you pair will help with this.
The navigator is looking wider than the current task
I strong temptation for a navigator is to focus too much on the task at hand (i.e. pointing out typos). Taking the racing car metaphor, it would simply be like a classic backseat driver. The value of the navigator is to think beyond the current task, to what lies ahead, be it danger or direction. When I take the navigator role, I am thinking of the consequences of what the current task has to other parts of the systems, considering what other tasks we may have missed, or what other test scenarios we still need to generate. I’m also thinking as I watch the code unfold whether or not the task we set out to do makes sense and is consistent with the rest of the system. I am looking to see how much closer it brings us to our final destination, or if there is a better way.
