CODEX

Tips for better pair programming

Pairing is not just two people working together. Mutual respect, emotion management, and other psychological factors come into play. Doing it well takes time, so be patient, and repeat it properly until you can reach the “pairing zone”.

If you don’t understand the advantages of pairing, perhaps you should start with that. Let’s quickly recap them:

• You’re “forced” to articulate your thoughts and ideas, which contributes to solving problems and helps you consolidate knowledge;
• Pairs complement/help each other (e.g., you don’t get stuck for hours in a bug); you move steadily and with increased predictability; you feel useful at the end of the day;
• The focus is higher since you have to respect your pair’s time and effort (e.g., you won’t be checking your phone every time), and you’ll have someone helping to manage time (e.g., who can tell you when you’re sliding away);
• Code reviews and decisions happen “on the fly” (with the ideal context) rather than in a separate phase; quality is improved as you’re actively reviewing; you skip the bureaucracy of code reviews, branches, PRs, etc.
• You learn on the job, as you may be paired with an expert. When joining a team, you don’t need onboarding sessions to understand the codebase, architecture, or domain since everything happens naturally as you bump into it as a pair.
• The knowledge is spread across the team; you share solutions and patterns; there are no preassigned tasks; the team doesn’t depend on specific people to move forward; onboarding/off-boarding is not a pain.

Let’s now go through some tips.

Discipline and focus

• Clear out the assumptions before starting. Make sure you understand the user story in detail. Don’t rush to start. Agree on a strategy beforehand.
• Timebox experiments. If one needs to make some code experiment or a small spike, propose a time slot to try it out (e.g., 15 min., 1 hour, till lunch). That will help keep focus.
• As the driver dedicates more mental power to interact with the computer, the navigator has more responsibility to keep things on track (ensuring focus on the story). It’s easy to detour, but you can say: “Is that related to the story? Could we do it later?”. Otherwise, you’ll keep “opening brackets without closing any”.
• Try to understand if the driver is refactoring too soon. Refactoring should always happen after or before the feature. Also, be aware when the refactoring is too big or unrelated to the user story — it might need to be done within other stories.
• Do not interrupt the driver with early optimizations/improvements (e.g., typos, code repetitions). Think of time split into small slots and wait for one to end to expose them. In TDD, you should only do optimizations/improvements when the tests are green. Write them in a notebook to mention them when possible (and you can relax meanwhile). Interestingly, many of my notes are scratched as the code evolves.
• Respect pauses. Realize and enjoy when you accomplish something and propose a pause. Focused and intense moments should be followed by pauses (try the Pomodoro technique if it helps).

Respect and empathy

• Ask the driver to think aloud but respect that not everything needs to be put into words. Sometimes, go along and/or wait for the experiment to finish. Try to follow it, but interrupt if you’re lost.
• Create empathy with the navigator, and keep probing if your pair is still on board. While listening, please wait till the end of the sentence rather than guessing it. If pairing in the same physical space, look at your pair sometimes when speaking/listening.
• Have the initiative to switch roles. You can propose the ‘specifier/implementer’ technique (one writes the spec, the other implements) if you need to explain a complex topic or feel the navigator is lost.
• Do not criticize the apparently “nonsense Google searches” made by the driver; that’s part of the research. If you let the driver finish their thoughts, there’ll be two perspectives to face the problem.
• Avoid condescending explanations. Try to teach within the context and in small chunks rather than shoving/showing off your immense knowledge about the project.
• Avoid repeating “I know that”, or “Yes I saw that”. Even if true, you might be preventing future teachings. Just move on. Prefer to say “interesting” when you learn something.
• Avoid sentences that start with “in my last company” or “given my experience”. Go directly to the underlying facts.
• If you see the driver stuck for a while, you may politely say, “Can I try something?” so you can switch roles.
• Be aware, from time to time, if the navigator wants to say something. He/she may be holding to avoid interrupting you, so pause sometimes to listen.
• Make questions. Every question is valid, but not all answers are. Challenge the driver. Phrase questions without looking like a “smart ass”.
• Don’t dictate code: if you know what you want, type it down yourself. Dictating is tiring to understand and can seem condescending.
• If you enjoyed the day, finish it by saying “Thanks for the day” or “It was a nice pairing with you today”.

Emotions

• Don’t stress if you don’t understand everything, especially when you’re the new guy. Try to help somehow (code contributions aren’t the only contributions). Your mental models will iterate and refine with time.
• Don’t get too personal; pairs work closely, which can be emotionally hard. For example, it’s easy to feel attacked if someone criticizes your code, but you can learn how to deal with it in both roles. Coding is just a tool, not a personal trait.
• Be open about your weaknesses from the start; mention your strengths later.
• Be gentle and tolerant. Don’t make the other feel threatened for not knowing something. Never say, “Didn’t you know that?”. Don’t judge others’ knowledge. Pairing is a symbiosis, not a competition.
• Behavior generates behavior, so don’t let feelings escalate in the wrong direction. Making fun isn’t welcome. Strive for empathy and a positive mood.
• People are different, so adjust to your pair. You want to be treated that way, so think, “What if I was in his/her shoes?” often.
• Accept that you’ll be slower sometimes, so manage anxiety. You feel you could go so much faster on your own, but recall that you belong to a team that desires no single points of know-how. Be patient. You’re not only building software but also a team that can do it.

In the end, if you’re making a lot of effort, you may be doing it wrong, or your pair may be making things hard. If that’s the case, ask for a personal feedback session where you clearly state the areas of improvement.