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 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 lean 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 Export / The Novice
That’s when a ‘lone wolf kind of’ expert pairs with a junior. The expert picks the keyboard, dashes through the tasks, doesn’t make sure his pair follows (which usually means it 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 must be to make his pair finish the task … It can be very frustrating at first. Nevertheless, the overall skill level in teams doing that increases so fast that’s it’s very fulfilling for the team as a whole.
The Skill Zone
The 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 and by sometimes doing differently than what they’d alone.
The Mentor & The Apprentice
Other times, there can be a real difference in skills for what the pair is attempting to do. 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.