Practical Pair Programming

Two heads are generally better than one. Collaboration leads to more thoughtful designs for users. Fewer errors and bugs reach production. And you often end up with a better implementation that more than 1 person understands. If pair programming has so many potential benefits, why don’t we see more developers taking advantage of it?

I recently read Practical Pair Programming by Jason Garber, and I wanted to highlight what I learned from the reading.

What pair programming isn’t

Pair programming does not mean twice the amount of developers for half the amount of time. Nor does it mean twice the amount of cost to get the same output.

What pair programming is

I like to think of pair programming as twice the amount of developers for a feature that’s twice as good. I do not consider pair programming to be any faster than developing alone nor am I really concerned with the speed and output of features while pair programming, instead I concern myself with the quality of the conversation between myself and my partner.

I think the true value of pair programming comes from good conversation. Good conversation can result in: a more thoughtful design, keeping focused, fewer bugs, collective code ownership, knowledge transfer, and more.

Getting started with pair programming

Work quality is generally better with a pair, but if you can’t get a pair or you’re looking to start with a few baby steps, these are some alternatives that are better than nothing:

1. Talk with someone for 15 minutes before diving into a solo task. A brief conversation could end up saving you days of building something the wrong way.
2. “Rubber ducking” or talking something through to understand it better. Even if the listener has little knowledge of the problem domain (or happens to be a yellow plastic bath toy), just articulating your thoughts out loud can help solve the problem.

How to make pair programming more effective:

• Agree on your objectives — If one of you thinks the goal is to fix as many bugs as possible and the other thinks the goal is to refactor legacy code, you might both be disappointed by the lack of progress you make in either direction.
• Setting a schedule — this will make pair programming more likely to happen and allows each person to schedule around their family life and extracurriculars.
• Taking turns — use a timer if you’re still getting comfortable with pair programming. Otherwise, feel empowered to call out disparity: “you’ve been driving (typing) for a while. Mind if I have a turn?”
• Checking in and taking breaks — ask one another how it’s going, take food breaks, try going for a short walk, etc.

Being a better partner

Being a better partner comes down to good communication. Things like:

• Using reflective articulation as the driver and constantly think out loud — silence is fine, but prolonged periods of silence may indicate a disconnected pair and lack of trust between partners.
• Be open to experimentation, don’t spend too much time debating hypothetical principles.
• Assume good intent: everyone is trying their best and 99.99% of the time people are not acting out of spite.
• Employ non-confrontational questions to keep yourselves in a critical-thinking space without putting each other in defensive mode.
• Don’t underestimate the power of curious, genuine inquisitiveness. Good questions are open-ended, asked with genuine curiosity, and non-judgmental.

Questions I like to ask while pair programming

• “Hey can you catch me up with what you’re thinking” is a friendly prompt to break silence or sync back up with your partner.
• “What lead you to make that decision” acknowledges that there were multiple approaches and your partner selected one. And you get to hear why they rejected other approaches.
• “Can I offer some feedback?” or “Can I bring up something I noticed” allows you to soften the criticism by asking permission first.
• “To clarify my understanding, what you’re saying is …” can help you stay on the same page as your partner by restating what they have told you using your own words.
• “So I’ve noticed we have been doing a lot of X. I wonder if that’s something we should be doing?” Framing your question as an observation can be more sincere, even if you’re sure what your partner has been doing isn’t correct.

Additional Resources

• Practical Pair Programming by Jason Garber — short book
• On Pair Programming by Martin Fowler — online article