---
# System prepended metadata

title: Paired Programming

---

# Paired Programming

*Based on a talk in Tech Time on 1st August - thanks to all contributors and attendees!*

## What is paired programming?

Pair programming essentially means that two people write code together on one machine.

## The benefits

There are plenty of benefits:
- **Knowledge sharing**: helps the team spread knowledge on technology and domain on a daily basis and prevents silos of knowledge.
- Better **problem solving**: When two minds understand and discuss a problem, we improve the chances of finding a good solution. Different experiences and perspectives will lead to the consideration of more alternatives. 
- **Reflection**: forces us to discuss approaches and solutions: speaking out loud ensure right understanding, and gain that instant feedback on them
- Keeping **focus**: less distractions and less rabbit holes
- **Code review** on the go: more errors get caught on the way. Easier to refactor as can discuss approaches
- **Two modes of thinking** combined: tactical and strategic view
- **Collective Code ownership**: makes anyone on the team feel more comfortable changing the code (esp if junior or new joiner). More consistent as well
- **Work in progress limit low** so can focus on the important tasks 
- **Fast onboarding**


![benefits of paired programming](https://martinfowler.com/articles/on-pair-programming/benefits_overview.jpg)

Read in detail the benefits [here](https://martinfowler.com/articles/on-pair-programming.html#Benefits)

---

## Classic set up
- One person who is the **Driver** (person at the keyboard). Focussed on completing the tiny goal and talk through what she is doing while doing it.
    - More tactical thinking about the details
- Other person is the **Navigator** in the observer position. Review code on-the-go, give directions and share thoughts. 
    - Thinking more stategically with the big picture in mind

### Approach
1. Start with understanding the reasonably well-defined task
3. Agree on one tiny goal at a time.
4. Switch keyboard/screens and roles regularly.


## Ping pong technique
Alternative to the classic setup, this technique is good for clearly defined tasks that can be implemented using TDD (Test Driven Development)
- **Ping**: Dev A writes a failing test
- **Pong**: Dev B writes the implementation to make it pass
- Dev B starts the next Ping
- Each Pong can also be followed by refactoring code together before continuing

---

## General paired programming tips
-  Ask for any preferences on pairing
    -  E.g. whether they prefer ping pong, how often they'd like to have breaks. Regularly ask to check if preferences have changed.
- When starting to pair: review the story
    - Can help to create clearly broken down tasks, and collaborate on the order
    - Discuss and agree an approach if there are multiple ways to approach the story
- Plan the day
    - Start with a calendar check, communicate availability and pairing times with each other before hand
    - Agree to divide and conquer when needed if research crops up
- Things to avoid:
    - Distractions: keep your eyes on the prize. Try and avoid reading emails/checking phone whilst pairing
    - Micro managing: leave room for the other person to think
    - Being impatient - use 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 - the driver might already have it in mind, then you are needlessly interrupting their flow.
- Swap between driving and navigating regularly
- Take regular breaks! Combat zoom fatigue!
    - [Pomodoro](https://www.toptal.com/project-managers/tomato-timer) is a good technique to remind you to take a break.
    - If you've been going a while - ask your partner if we can go on a break - it'll be beneficial for both!
- If you get stuck:
    - Walk away - take a break and return with fresh eyes
    - Treat partner as [rubber duck](https://en.wikipedia.org/wiki/Rubber_duck_debugging) - Just explaining the problem out loud can help with finding the solution.
    - Agree how long to keep going before seeking out others
- Some tools can help with pairing (e.g. Zoom annotate, code sharing tools)
- Timebox explorations - if you find something interesting to look into, timebox and if it turns into a [rabbit hole](https://medium.com/@create_self/brb-im-going-down-a-rabbit-hole-how-i-learned-how-to-read-code-documentation-a664c94e91d7) then think about putting it in the backlog and circling back if you have the time. 
- Get feedback post pairing on how it went - a 'de-brief'
    - Challenge and be open to be challenged

## Pairing with someone who might be more disengaged
- Try to enforce regular pair swapping
    - Before starting a ticket, work out all the different tasks to do and ask which they’re most interested in driving
    - When planning the day: can suggest at what points can aim to swap
    - If you've been driving for a while, suggest swapping at the next logical point (after the next break/lunch/meeting etc) 
    - Also can try a different technique: follow ping pong mode of pairing, where coder is switched more often
- Speak out loud a lot to keep them on board - perhaps they just got lost along the way
- Try and engage them
    - Ask them questions (even if you know the answer) or ask for suggestions even if it might seem straightforward — spark discussions
    - - Get pair to play the problem back, to ensure we're on the same page
- If they're really unresponsive - ask for a break, perhaps they're really burnt out
    - Engage with them after coming back and starting
- Get Feedback on how sessions have gone/their pairing preferences

## Pairing with someone who might be more junior
- Be selective of which stories to pick up together
- Align on what pairing is - get people on the same page about the benefits of pairing and why
- Help them see a bigger picture or value of why we are doing the task in hand
    - sharing of context while pairing
- Get them comfortable
    - Build a safe space where they feel its okay to make mistakes and learn things anew. There are no stupid questions - in fact questions are encouraged. 
    - Emphasis they're not holding anyone back: in teams interest to get them up to speed
    - Proactively checking if they have any questions or doubts
    - Sometimes splitting and letting them explore on their own (setting clear goals first and when to regroup)
    - going slower and taking time to explain things
    - Remember the 5 second rule
    - Not assuming anything about knoweldge levels, avoiding sounding patronizing 
- Try and get them to drive more
    - Best way to learn
    - Go more into the mentoring mode - let them drive more to build confidence if they are willing
        - First demonstrating how to drive the task and asking them to review the code and encourage giving feedback and then helping them getting comfortable driving the task
- Celebrate accomplishment of tasks, however small
    - Can help energize and build confidence

### There is not "THE" right way
- It depends on your styles, personalities, experience, the situation, the task and many other factors.
- In the end, the most important question is: Do you get the promised benefits out of it? If this is not the case, try out something else, reflect, get feedback and adjust.

---

## Recommended reading
- [Martin Fowler Blog post on Paired Programming](https://martinfowler.com/articles/on-pair-programming.html)
    - [Thoughtworks slides on paired programming](https://docs.google.com/presentation/d/14mN8c8v9c-Tl75XWs6uUusEAWnIltKxJOgICjwWyiYU/edit#slide=id.g35e10f078d_0_19)
- [Thoughtworks sensible defaults section](https://central.thoughtworks.net/home/sensible-default-practices/software-dev-sdp#pd)