Pairing with Intent

Why did you pair program today?

No, I’m not asking why you pair program in general. Anyone can list the benefits. I’m asking “Why did you pair program today?”

The articles I’ve read all claim that when pair programming is done right, participants will reap a host of benefits, including:

  • Increased Discipline (Less goofing off)
  • Better Code (2 brains are better than one)
  • Resilient Flow (One pair handles an interruption while the other maintains the flow)
  • Improved Morale (More enjoyable than programming alone)
  • Collective Code Ownership (Less finger pointing, more shared trophies)
  • Mentoring (Natural way to share knowledge)
  • Team Cohesion (Definitely will know each other. Hopefully will like each other.)
  • Fewer Interruptions (People know you’re busy because you’re thinking out loud)

I’m not disputing the accuracy of the list. YES, these benefits result from effective pair programming.

The mistake is in the assumption that all pair programming sessions will produce all of the benefits.

I assure you that is not the case. In reality, each session delivers a small subset of these benefits. The benefits produced depend on several things:

1) The participants’ relative skill levels

2) Their personalities and relationship with each other

3) The goal of the pair programming session.

Let’s look a few of the team roles and how they benefit most from pairing:

The Junior Developer

  • Benefits most when:
    • working on an issue just above his/her current level of knowledge
    • paired with a person who excels in mentoring others
    • NOT paired with the most senior team members (the gap in knowledge becomes frustrating for both)
    • given solo time to fight through simple issues on his/her own (builds confidence)

The Senior Developer

  • Benefits most when:
    • working with someone who has domain-specific knowledge
  • Provides most benefit when:
    • Working on complex or critically important issues
    • Paired with a developer who is only slightly less experienced
    • Paired with the express intent to mentor

The Mid-Level Developer:

  • Benefits most when:
    • Paired with a Senior Dev on a complex issue
    • Paired with another mid-level dev on a standard-complexity issue
  • Provides most benefit when:
    • Paired with a Junior Dev with the express intent to mentor
    • Paired with another mid-level dev on a standard-complexity issue

The Shy Dev

  • Benefits most when:
    • Paired with someone who forces him/her to socialize

The Introverted Dev

  • Benefits most when:
    • Encouraged to pair, but given the freedom to work alone to get a break from socializing

The Extroverted Dev 

  • Insufficient data for analysis.

Pairing is an incredibly effective tool, but it is just that: a tool. No tool is right for every job, and not having a pair can be better than having the wrong pair.

It’s time we start asking ourselves: What am I trying to accomplish with this pairing session? What pair will benefit most from tackling this specific issue? Would pairing be helpful or wasteful on this particular issue with this particular pair?

One thought on “Pairing with Intent

  1. Pingback: Pair Programming | whatilearntfromrunning

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s