Practice : Pair Programming

Purpose and Strategic Importance

Pair Programming is a collaborative development technique where two engineers work together at the same workstation - one writing code (the driver), the other reviewing and guiding (the navigator). It enhances code quality, accelerates learning, and fosters shared ownership.

This practice reduces bugs, spreads knowledge, increases team cohesion, and improves engineering discipline. It’s a key enabler of continuous improvement and resilience in complex systems.

Description of the Practice

  • Two engineers collaborate in real-time to solve a problem and write code.
  • Roles switch frequently - alternating between driver and navigator.
  • Can be applied during feature development, refactoring, debugging, or onboarding.
  • Variants include remote pairing, strong-style pairing, and ping-pong TDD.
  • Tools include screen sharing, collaborative IDEs, and shared terminals.

How to Practise It (Playbook)

1. Getting Started

  • Select a small or moderately complex task where collaboration adds value.
  • Define clear roles and switch regularly to balance participation.
  • Use shared context tools - consistent editor setup, real-time chat, or voice.
  • Debrief after each session: what worked well, what to try next time?

2. Scaling and Maturing

  • Incorporate pairing into your team’s delivery rhythm (e.g. daily or planned slots).
  • Pair across roles (e.g. backend/frontend, engineer/designer) for broader perspectives.
  • Track improvements in code quality, onboarding speed, and team cohesion.
  • Apply pairing to high-risk work - production changes, tech spikes, or complex refactors.
  • Encourage variety in pairings to avoid silos and build empathy.

3. Team Behaviours to Encourage

  • Prioritise psychological safety and respect - all voices matter.
  • Embrace shared problem solving over perfectionism or control.
  • Value learning, mentoring, and real-time feedback as outcomes.
  • Create inclusive norms around when and how to pair.

4. Watch Out For…

  • Burnout from prolonged or forced pairing without breaks.
  • Power imbalances or overbearing behaviours in pairs.
  • Using pairing as a productivity metric instead of a learning tool.
  • Assuming all work must be paired - mix solo, pair, and mob programming as needed.

5. Signals of Success

  • Code quality improves and bugs are caught earlier.
  • Engineers learn faster and onboard more smoothly.
  • Collaboration feels energising and effective - not exhausting.
  • Teams develop a shared understanding of systems and decisions.
  • Feedback loops shorten and engineering culture strengthens.