"Pair programming is a conversation. You're always talking. You're always explaining. You're always trying to combine your knowledge." - Sarah Mei
- Pair programming is vital for collaborative teamwork and high quality software.
- What it's not.
- It's not as simple as "two people working at a single computer".
- If your pair programming involves arguing, jockeying for position/influence, or trying to prove something, it's not actually pairing.
- If your pair programming involves one person typing while another person silently watches, it's not actually pairing.
- If your pair programming is on a computer where one of you is the "owner" and one of you is the "guest," it's not actually pairing.
- How to pair?
- Driver & Navigator. The person at the wheel (keyboard) and the observer (the person who reviews the code on-the-go, gives directions and shares thoughts).
- Ping Pong. This technique embraces TDD. Ping writes a failing test (red) and then Pong writes the successful implementation (green).
- Strong-Style Pairing. This is a technique particularly useful for knowledge transfer. In this style, the navigator is usually the person much more experienced with the setup or task at hand, while the driver is a novice (with the language, the tool, the codebase,...). The experienced person mostly stays in the navigator role and guides the novice.
- How to pair?
- Start with a reasonably well-defined task.
- Agree on one tiny goal at a time.
- Park next steps, potential obstacles and ideas on sticky notes and discuss them after the tiny goal is done.
- Understand the problem -> Come up with a solution -> Plan your approach
- Pairing can be an exhausting practice, so it is helpful to get a reminder to take breaks and switch keyboard and roles regularly.
- Pairing requires a certain level of scheduling and calendar coordination.
- Start with a reasonably well-defined task.
- Physical Pairing.
- Make sure both of you have enough space.
- Being that close to one another requires a certain level of respect and attention for each other's needs.
- Check with your partner if they have any particular preferences or needs (e.g. larger font size, higher contrast, ...). It is beneficial if your team can agree on a default setup, so that you don't have to discuss these things again and again.
- Remote Pairing.
- Setup:
- For remote pairing, you need a screen-sharing solution that allows you to not only see, but also control the other person's machine, so that you are able to switch the keyboard.
- Use video: since people communicate a lot through gestures and facial expressions.
- Use collaborative online visualization tools, to reproduce the experience of sketching out things on paper or a whiteboard.
- Look for a quiet area and use a good headset (noise-cancelling headphones are your friend).
- Working remotely with someone you haven't met and do not know creates an additional challenge. Be polite.
- Setup:
- Things to avoid:
- Avoid to read Slack or to use your phone. These distractions might come across as disrespectful to your pair, and they distract you from the task you are working on. If you really need to check something, make it transparent what you are doing, and why. Make sure that everyone has enough time to do this by taking enough breaks.
- Avoid Micro-Management Mode. It leaves no room for the other person to think. It doesn't make sense to reduce pairing to someone telling their pair instructions like (do this, do that): "Now type 'System, dot, print, "...
- Impatience. Apply the "5 seconds rule": when the navigator sees the driver do something "wrong" and wants to comment, wait at least 5 seconds before you say something. If you intervene immediately, this can be disruptive to the driver's thinking process.
- Watch out if you're "hogging the keyboard": this can be a really annoying experience for your pair and might cause them having a hard time focussing because of limited "active participation".
- Power Dynamics.
- Benefits.
- Knowledge Sharing.
- Reflection: pair programming forces us to discuss approaches and solutions, instead of only thinking them through in our own head. Saying and explaining things out loud pushes us to reflect if we really have the right understanding, or if we really have a good solution.
- Code review on-the-go.
- Collective Code Ownership: consistent pairing makes sure that every line of code was touched or seen by at least 2 people. This increases the chances that anyone on the team feels comfortable changing the code almost anywhere. It also makes the codebase more consistent than it would be with single coders only.
- Fast onboarding of new team members.