We’re doing pair programming almost all the the time in our team. A few weeks ago, we went to Devoxx Paris, and 2 team mates used pair programming at a hands on session : they finished way before the others and had the time to take a 30 minute break. Pair programming delivers more … when it works.
Flavors of Pair Programming
Throughout our experience, we have identified some situations where it does or does not work :
|Pain Zone||Skill Zone|
|Expert / Novice||Mentor & Apprentice|
The Pain Zone
Pair programming can be painful. It can feel like a waste of time or become extremely frustrating. Here are the typical situations and how to fix them.
The Wandering Buddies
That’s what you’d get if you asked to newcomers straight out of school to pair program on existing source code on day 1. They’d be dabbling here and there, without going anywhere. Each one would try to get the keyboard to try his way, but in the end, no general direction would be followed.
The cure in this case (as often) is to stop and think. At least one in the pair needs to learn how to pair program. It’s not difficult, that’s just :
- Discuss and agree on a general plan first
- Keep a todo list
- Track your advancement on your todo list while you don’t have the keyboard
- Stop and discuss from time to time
By starting that, the pair will quickly move into the ‘mates’ state.
The Expert / The Novice
That’s when a ‘lone-wolf’ expert pairs with a junior. The expert picks the keyboard, dashes through the tasks, and does not wait for his pair to follow (which usually means he does not).
Regular pair programming means a change in job responsibilities for such expert programmers. If they were expert doers before, they should now become expert mentors or coaches. That’s quite a difference to them: it means that their goal becomes to make their pair finish the task! It can be very frustrating at first. Nevertheless, the overall skill level increases so fast that’s it’s very fulfilling for the team as a whole.
The Skill Zone
This is where we want to be. When it happens, pair programming feels productive, interesting and fulfilling. Contrary to what is often thought, this can happen whatever the skill levels of the 2 programmers.
The programmers have equivalent skills on the subject at hand. They organized in a way that they are both learning from each other:
- By having to verbalize what and why they are doing things
- By challenging each others assumptions
- By regularly trying a different way than what they would have done alone
The Mentor & The Apprentice
Other times, there can be a real difference in skills about the topic at hand. In this situation, the goal of the most knowledgeable is to train his pair, who’s goal is to learn. The task becomes some kind of exercise on which to practice.
During a typical pairing session, a pair might switch many times between mentor and mates states. Each one in the pair might assume the mentor’s role for different aspect of the work. At the end of the day, everyone should feel as if they had learned and accomplished good work.
Last Word of Caution
Pair programming is exhausting. Don’t expect to be able to do 40 hours of pair programming per week. After 6 hours in a day, one usually starts to get a lot less efficient.
Both juniors and experienced programmers also need some time by their own, to experiment things by themselves or to complete a simple task without having worry about explaining everything.