If you have never pair programmed, or if you have, and had a bad experience with it, I am here to urge you to give it another chance. Here I will introduce you to some easy to follow guidelines to make pair programming successful through a technique called Strong-Style pairing.
Strong-Style Pair Programming
Strong-Style Pair Programming shares many of the ideas common in Mob Programming. The underlying premise is that, for an idea to make it into the code, it has to be verbalized and go through someone else’s hands. The usual way of representing this is by using the driver/navigator analogy. The person at the keyboard is the “driver”, and the person telling them what to implement is the “navigator”.
The driver is responsible for implementing the navigator’s ideas. This requires the driver to trust the navigator as they might not agree with the directions the navigator is taking. Being comfortable with incomplete understanding is also needed. This is because, when you are implementing the navigators idea, the driver may not completely understand the reason why. That is okay. The driver can ask questions to clarify what the navigator is telling them to do as needed, but should save the “why” questions until the idea is out of the navigator’s head and into the code.
The navigator is responsible for telling the driver what to implement. This should be done one instruction at a time, only giving the next instruction when the driver is ready. This should be done in the highest level of abstraction the driver can understand. An example would be telling the driver to create a function to do some needed calculation. If the driver is unsure what is meant, they can ask for more detail. This would lead the navigator to become more detailed in their instruction, possibly even describing the syntax and line numbers, if that is what was needed for the driver’s understanding.
Working in this way, the pair can get an idea into the code and then decide if there is a better way. Following this process helps in overcoming common pairing pitfalls such as: one person working and the other watching, fighting over the keyboard (if you have an idea to express you should not be typing at the keyboard), and guessing what the other person is thinking. This also gives the navigator time to organize their thoughts while the driver is implementing the last instruction.
Go Forth and Pair
In my experience, using this process has increased the quality of the code written, shortened the amount of time stuck on problems, and increased the learning and knowledge shared.
At Greater Sum we have a policy that if someone asks you to pair program on a problem they can’t say no. With that, I implore you to try pair programming. If they don’t pair program where you code, just go up to someone and ask them to pair program. Just be sure to remind them that the rule is they can’t refuse.
More information on this topic can be found in the following posts from Lewellyn Falco http://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-pairing.html, and Arlo Belshee http://arlobelshee.com/a-pairing-phrasebook/ .