Emotion management when pair programming

Pairing is challenging but worth it, for the know-how sharing and the steady/predictable progress. Doing it well takes time, so be patient. With respect and some techniques, 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 consolidating knowledge;
  • The psychological well-being is improved as both 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 (e.g. you won’t be checking your phone every time); 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 much more, as you may be pairing 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; on-boarding/off-boarding is not a pain.

Let’s now go through some tips for the driver (the one writing the code) and the navigator (the one specifying).

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).
  • Time box 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 tracks (ensuring focus at 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 getting the tests green. Also, be aware if the refactor is too big or unrelated with the user story; that means it’s time to create a specific story for that.
  • Do not keep interrupting the driver with early optimizations/improvements (e.g. typos, code repetitions). Think of time split in 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 ping-pong game. 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 sentence rather 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 “non-sense Google searches” made by the driver; that’s part of the research. If you let the driver finish thoughts, there’ll be two perspectives to face the problem.
  • Avoid condescending explanations. Try to teach within the context and in small chucks rather that shoving/showing off your immense knowledge about the project.
  • Avoid repeating “I know that”, “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”. Just say them if they’re facts.
  • The driver is responsible for the implementing 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”.
  • If you enjoyed the day, finish it saying “thanks for the day” or “it was nice pairing with you today”.


  • Don’t stress if you don’t understand everything, specially 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, on both roles. Coding is just a tool; not a personal trait.
  • Be open about your weaknesses from the start; mention your strengthens 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 the other’s 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 welcomed. Strive for empathy and 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.