Tech Lead Handbook
  • 👋Introduction
  • People
    • Space for Growth
    • One on Ones
    • Manage Conflicts
    • Deal with Passive Aggressive
    • Give Feedback
    • Performance Management
    • Manage Up
    • Talent Matrix
  • Engineering
    • Pair Programming
    • DCI Framework
    • Code Ownership
    • ADR
  • Leadership
    • Leadership Competencies
    • The Communication Pyramid
    • Anti Patterns
  • Prioritisation
    • Types of Decisions
    • Pros and Cons
    • Decision Matrix
  • Hiring
    • Hiring Process
    • Prepare a Hiring
    • Position Description
    • Shortlisting
    • Case Study
  • Product
    • Working with Product Managers
    • Assumptions Mapping
    • Decision Making
    • Practice vs Process
    • Nemawashi
    • OKRs
    • Consensus vs Consent
  • Project
    • The Triple Constraint
  • Strategy
    • Tech Strategy
  • Communication
    • Use Positive Language
  • Shortlist
  • ...
Powered by GitBook
On this page
  • The What
  • The How
  • For Ramping Up New Team Members (effective)
  • For Upskilling Juniors (pretty common)
  • For Firefighting (it's a must)
  • To unblock yourself or your colleagues (do it)
  • Troubleshoot Defects (can be helpful)
  • Avoid Bugs (okay but costly)
  • Red Flags
  • Tips
  • Pitfalls
  1. Engineering

Pair Programming

Why pair programming? What should we use it for, and when should we not?

PreviousEngineeringNextDCI Framework

Last updated 1 year ago

The What

What is pairing programming really for?

Pair programming to exchange knowledge among people

The main goal of pair programming is knowledge sharing - an activity through which knowledge is exchanged among people.

Pair programming to the rescue

Check out Eric Elliott's post about pair programming

The How

For Ramping Up New Team Members (effective)

It is not uncommon to pair an existing team member with a brand new team member. Information like domain knowledge, internal tooling, and existing ways of working can be passed along to the new team member.

For Upskilling Juniors (pretty common)

Kind of like knowledge sharing, but focusing on upskilling juniors. I'd say pairing isn't the most productive way to upskill juniors. There are other alternatives like code review, training, knowledge sharing sessions, etc.

For Firefighting (it's a must)

The production environment is on fire and needs to be fixed as soon as possible. How you apply the hotfixes is an anti-pattern and in a rush. e.g.,

  • ClickOps

  • Deploy the latest working image on your dev machine

  • Run SQL scripts to fix broken tables

  • Run shell scripts to fix a broken node

To unblock yourself or your colleagues (do it)

It is what pair programming is for. Do it often. Do it whenever you need help. Do it regardless.

Troubleshoot Defects (can be helpful)

Sometimes, an extra pair of eyes help you find more clues about what you're looking for.

Avoid Bugs (okay but costly)

It shouldn’t be the goal, instead, it is the happy outcome we got by accident. Bugs should be captured via code review, unit test, integration test, end-to-end test, and monitoring and alerting system.

  • Paring can be exhausting.

  • Pairing doesn't work for everyone

  • 100% pair programming can harm productivity and responsibility. Don't do that.

  • Shared responsibility is no one’s responsibility

Pair programming is excellent and we should definitely use it when appropriate, but don't go too far on that track as its drawbacks are clear.

Red Flags

Tips

Pitfalls

🔴
📜
🕳️
👉
here