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 put your thoughts and ideas into concrete words, 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” rather than in a separate phase (better context, less long discussions); quality is improved as you’re actively reviewing;
You learn on the job, as you may be paired with an expert on the topic;
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 read the user story in detail. Don’t rush to start. Agree on the strategy beforehand (using flowcharts, ‘to-do’ lists, mental maps, and other diagrams).
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 keep interrupting 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 so you can mention them when possible (and you can relax meanwhile). Interestingly, many of my notes are scratched as the code evolved meanwhile.
Respect pauses. Realize and enjoy when you accomplished 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, just 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, wait till the end of the sentence rather than guessing it. 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.
The driver is responsible for the implementation but if you see him/her stuck, 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, just type it down. 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 and it 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 having 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.