The content of this cheatsheet was gathered and distilled from the awesome Tuple’s Pair Programming Guide.
- Sit directly next to each other, with the monitor equidistant between you.
- Plug in one keyboard per person.
- Use an editor/IDE that you both know reasonably well.
- Bump up the text size a little.
- Don’t bring your phone. Silence it if you do.
- Disable notifications on the machine you’re using to pair.
- Close email/Slack/Twitter/IRC. Never keep something distracting on a second monitor.
- Pairing should involve constant two-way communication.
- When navigating: ask questions rather than making demands.
- When driving: dictate what you’re doing and why.
- Take lots of breaks.
- Swap roles frequently.
Unless you already know what works best for you, try the Pomodoro Technique:
- Code for 25 minutes.
- Take a 5 minute break.
- Switch drivers.
Probably the most common type of pairing.
The driver types the code and stays focused on the current task.
The navigator thinks ahead, ponders edge cases, spots bugs, suggests refactorings, asks good questions, stays zoomed out.
- Unless you’re sure your pair is keeping up, don’t manipulate code quite as fast as you’re able.
- If you get the sense that your pair’s attention is drifting, stop and sync up.
- Ask good questions: "Which part of this is hardest to follow?” vs bad questions: “You understand this, right?”
- If your navigator is making a suggestion, consider taking your hands off the keyboard. Even better: turn and make eye contact.
- Give your driver a chance to notice their own syntax errors and typos.
- If you have a suggestion for the driver, communicate it at the highest level of abstraction they’ll understand.
- If you find yourself dictating code (or worse, individual keystrokes), stop and see if you can communicate your idea at a higher level.
Spend a few minutes after your session reflecting on the experience.
First, discuss what went well.
Then, consider what would make the next session 1% better.
Possible areas for improvement:
- Focus: did distractions sneak in?
- Communication: were there long stretches of no talking?
- Pacing: did the session feel like a grind at any point?
- Division of responsibility: did you split the work up well?
- Code quality: was your end-product high-quality?