Preserving a Pair Programming Culture

I’ve written about how I like Square’s pairing interview process: it’s hands-on, it allows for a more realistic environment for writing and running code, and it can be a learning experience for both the interviewer and the interviewee. The feedback from our candidates has generally been positive as well.

In talking to a friend about how we interview and how we write code, I pointed out that we’ve evolved the development requirements, at least on my team, to not require pairing all the time but to still keep a pairing culture. Starting with the interview and continuing via the first few weeks of onboarding, we make sure the new guy is pairing with a seasoned engineer, and that we continue to provide the support, e.g.,

  • Having people available,
  • Setting up pairs or scheduling pairing sessions,
  • Investing in pairing machines1

To make pairing as painless as possible.

A part of the change comes from realizing that not all tasks are appropriate for pairing; sometimes, a simple change is better executed asynchronously with a pull request, and some rote and uninteresting work does not benefit from another set of eyes while it’s performed. It also got more difficult to coordinate and schedule pairings for the entire team as it grew, with remote pairing being particularly hard to reconcile.

But instead of canning the practice completely, we’re hoping that selective pairing and beginner’s indoctrination will preserve the spirit of pair programming, and allow it to happen when necessary. It’s all too easy to revert to a headphones-on-all-the-time culture, one where inexperienced programmers fear to ask for help and pull requests become long, overbearing threads of point and counterpoint, and communicative context gets lost in a chat room.

Pairing is still a valuable tool, but one that’s prone to rust and decay all too often. Cultivating and maintaining a culture where anyone can ask for a pair on any given problem is a challenge, particularly when previously strict requirements are softened. Ultimately, it’s up to an individual’s judgement, but we trust each other to do the right thing.

  1. For us, it’s a 27″ fully-loaded iMac with two keyboard and mice attached. Some prefer two monitors, but having individual input devices is what’s essential.

Share this article
Shareable URL
Prev Post

The Horrible Designs of an Apple TV Clone

Next Post

User-Centric Development Revisited

Leave a Reply

Your email address will not be published. Required fields are marked *

Read next