Chapter 2. Getting Started

You don’t take on the 10-meter dive at your first visit to the pool, and neither do you need to plunge into spending all your working time as part of a pair. Pairing is a very different style of working; wade in gradually, timebox your pairing sessions around specific goals, and give yourself (and your teammates) time to adapt.

Nothing about pairing is particularly hard, but an open mind is crucial. In this chapter, we’ll walk through some of the tips and tricks that I’ve seen from successful pairs. Be ready to bring your whole self to the task as you and your partner adjust.

When to Pair

It makes the most sense to work as a pair when you’re making decisions and dealing with complexity. That encompasses most of what we do as programmers, even when we’re not writing actual code, so it might surprise you to hear that full-time pairing isn’t the goal. As a practical matter, at my company we aim for 50 percent pairing. Everyone gets exhausted by pairing to some degree or another. Yes, the more experience you have pairing, the stronger those muscles become and the more endurance you’ll have. The more of an extrovert you are, the more naturally it comes. But it doesn’t always make sense to pair and even when it does, it might not be practical to get a pair’s undivided attention.

Not-quite-pairing

The work quality is always better with a pair, but if you can’t get a pair or you’re looking to start with a few baby steps, these are some alternatives that are better than nothing.

• Having someone talk through a problem with you for fifteen minutes before diving into a solo task can be enormously helpful. Sometimes a brief conversation will save you days of building something the wrong way.
• “Rubber ducking,” or talking something through to understand it better, is another thing we sometimes do in our office. Even if the listener has little knowledge of the problem domain (or happens to be a yellow plastic bath toy), just articulating it can help solve the problem.
• You might try “passive pairing,” where both people are working separately but look at the shared screens often enough to keep up with what’s happening on the other side. You don’t get nearly as much benefit as active pairing because you’re not engaged in the same creative act, but at least you can’t get as far down a bad path as you might on your own.

Passive pairing is a weak form of pairing and is best suited to programming tasks that aren’t super critical. It runs dangerously close to what software engineering and process coach Alex Harms calls “side-by-side pairing,” where the advanced developer works on something else and the person who is identified as “junior” does all the work and gets to ask questions once in a while. “We call things like this pair programming,” says Alex, “and then people say, ‘Pair programming sucks and I don’t want to do it.’ Duh! Pair programming takes work!” (http://bkaprt.com/ppp/02-01/, video)

These alternatives can be helpful when you can’t pair. Just don’t mistake any of them for the real deal—if it doesn’t require two people’s full attention, it’s not pairing!

Splitting up: “It’s not you, it’s the task”

This brings us to tasks that are a poor fit for pairing: Research, reading, chores like manually converting templates between languages, and lots of copying-and-pasting. These kinds of tasks should be few and far between—we are programmers, after all, and automating mundane tasks is what we do—but when they do come up, it’s usually obvious that overall throughput will be higher if the job is split up.

The cost of error should be low as well. If you make a mistake while soloing, it should be the sort of tactical defect that’s caught by your test suite, compiler, or linter. If you’re producing strategic defects (going down the wrong path), then you should get back to pairing.

When you transition from active pairing to another form of work, clearly communicate your intentions. It’s easy to say, “How about we split up for five minutes to search for answers?” If you wordlessly start typing on your laptop, how is your pairing partner supposed to know whether you’re abandoning them or doing something useful?

When we split up for a few minutes while pairing at Promptworks, we tend to mumble what we’re seeing and reading, or at least make expressive noises. By this, you keep tabs on how close each of you feel to an answer and tacitly communicate when it’s time to share what you’ve found. Keep a chat window open to paste links back to the shared screen.

Sharing Time and Space

When you’re on top of your pairing game, you’re both so focused on the code that you hardly notice who’s typing. It’s like you’re sharing a brain among four hands, sometimes trading control back and forth several times in a handful of seconds, yet rarely typing over each other. It’s powerful and magical in a way that begs for intense gesturing from Jony Ive (http://bkaprt.com/ppp/02-02/, video).

This level of “flow” might seem pretty far-fetched, but I can attest that I often feel it when I get an hour or two into a pairing session with a colleague. To get there, equality and fairness are key—and there are some basic starting points that will help any pair get off on the right foot.

Agreeing on your objectives

You should agree on the objective of your pairing session at the outset. If one of you thinks the goal is to fix bugs as fast as possible and the other thinks it’s to learn Python, you might both be disappointed by the lack of progress you make in either direction.

In many pairing sessions, the goal is simply to complete stories quickly and elegantly, but there may be some secondary goals you want to talk about. Perhaps you want to also get better at test-driven development or to clean up some smelly code as you go. Once you have these objectives in mind, take a moment to mention them as you’re starting and ask if your partner agrees.

Setting a schedule

Working together with shared controls to accomplish a task means you have to be working at the same time. This can be a challenge when pairing across time zones, when you have different obligations outside of work, or when you simply have different preferences for work time. Be intentional about your pairing sessions: coordinate starting and ending times with your pair so you can work effectively and negotiate schedules with family and extracurriculars in mind.

A laissez-faire attitude to scheduling can result in missed expectations and lots of soloing by default. When less-attached team members work whenever they want, the team members who are also parents and caregivers may feel marginalized if they miss out on the best collaboration moments.

Taking turns

Dynamic, effective pairs feel empowered to call out disparity: “You’ve been driving (typing) for a while. Mind if I have a turn?” When my partner says this, I don’t hear, “Gosh, you’re such a keyboard hog!” but more like, “I feel bad that you’ve been typing for so long. You must be ready for a break.” Speaking for myself, I’m always relieved to pass the baton.

While you’re still getting comfortable with pair programming, you might use a timer to take turns driving; this ensures equal time at the controls and helps break any habits of being a keyboard hog or a comfortable spectator.

You might also trade control by tying each turn to a cycle like that of test-driven development (TDD). Under TDD, you first write a test for the tiniest change in behavior, watch it fail, then write the minimum code that makes the test pass. You next take the opportunity to refactor the production code and the test code, and only then move on to the next small change in behavior. “Ping pong” pairing, as Ward Cunningham describes it, simply alternates who writes the test and who makes it pass. After perhaps many iterations, you will have satisfied all the acceptance criteria for the story and can consider the feature done (http://bkaprt.com/ppp/02-03/).

By working in this fashion, you ensure that both of you not only have equal time driving, but you get to challenge each other to only make small changes to the codebase, have the test suite passing after every change, ensure high test coverage, and collaborate on refactoring at each step.

Checking in and taking breaks

Spending multiple hours in a car with only one traveling companion tests anyone’s patience; the same is true of pair programming. An important part of not getting fed up with a pairing partner is taking breaks, having a snack, getting some air, and generally giving each other space to be quirky, flawed human beings.

Take some of your breaks together to check in on how the work is going. If you’re growing into the pairing relationship, reflecting on the pairing process is important. Do you type noticeably more (or less) than your partner, and do they mind the discrepancy? If you’re pairing remotely, are you able to hear them clearly enough to communicate, or are they drowned out by background noises?

It’s tricky to not get fixated on annoying noises and habits, and trickier still to bring them up in a helpful and sensitive way. Psychologists and counselors have made careers out of this stuff. Don’t let it fester; speak to pairing partners about it with empathy and non-judgment. Be aware of subtle hints coming in your direction, too.

Taking a walk around the block is a great way to spend a five-minute break. I cannot overstate the value of looking away from a screen and into the distance. It’s not just good self-care, it’s pair care!

Sharing Power

For those of us who recognize the value in working alongside colleagues as diverse as the users we’re serving, pair programming can be a fantastic vector for leveling the playing field—if its participants are mindful of the power dynamics between them.

Software engineer Sarah Mei identified the problem with unexamined pair programming in heterogeneous groups:

Pairing has nothing to say about how to structure an interaction to avoid taking unfair advantage of power dynamics. One of its basic assumptions is that everyone feels empowered to contribute.

When this is true, pairing is amazing. When it’s not, it’s a nightmare. (http://bkaprt.com/ppp/02-04/)

Tech is a predominantly White cis male industry, and beyond the obstacles underrepresented groups face just getting a job, there are dozens of ways White men have privilege that they take for granted at work every day (http://bkaprt.com/ppp/02-05/).

When you feel comfortable in your pairing environment, check in with your partner rather than assume that your feelings are shared. If you’re part of a dominant group, be it according to gender, race, or another characteristic, remember that people in underrepresented groups often find it risky to voice concerns that fall outside of the lived experience of their colleagues.

When you’re the old pro

Aside from sociocultural factors, discrepancies in professional experience are a fundamental source of power imbalances. The experience and practical knowledge that comes from more years as a programmer or more time on the codebase can be valuable; drawing on a solution from ten years ago sometimes saves the day. But the less experienced person may also feel behind in skill, not valued, and at a disadvantage in every disagreement; they may not feel comfortable voicing a contradiction. As Malcolm Gladwell pointed out in Outliers:

In commercial airlines, captains and first officers split the flying duties equally. But historically, crashes have been far more likely to happen when the captain is in the “flying seat.” At first this seems to make no sense, since the captain is almost always the pilot with the most experience. But…planes are safer when the least experienced pilot is flying, because it means the second pilot isn’t going to be afraid to speak up.

The privilege of having more experience can shut down valuable lines of inquiry and stifle innovation with old habits, so make sure you’re deferring to a person with less power or status, even if you have to literally sit on your hands. Give them more time driving and make sure you’re using interrogatives, not imperatives. Far better to allow yourselves to explore the wrong path together than to split up in frustration and head off through the wilderness in different directions.

When the “pro” leaves you in the dust

If you find yourself being undermined by your partner, an effective intervention is to paraphrase what’s going on: “I feel like you think I’m wrong more often than I am,” or “We always seem to try your way first.” Describing the imbalance makes them aware without ascribing a motive.

Impact statements can help redirect their attention to how their actions made you feel: “I felt like you didn’t think what I had to offer was worth considering.” You can also take an inquiring approach to explore where they’re coming from or use humor to defuse a tense situation. These are just a few techniques experts suggest to interrupt verbal microaggressions, and with a little adaptation, they can be used to correct pair power imbalances that diminish the contributions of one partner (http://bkaprt.com/ppp/02-06/, PDF).

Bring Your Whole Self

I know pairing for the first time can be daunting. You have to decide when to pair, how to pair, agree on objectives, coordinate a schedule, share the keyboard, keep your sniffles in check, take healthy breaks, and make sure everyone feels empowered to contribute. With all this to juggle, wouldn’t it be easier to keep working alone and not risk disappointment?

Don’t worry; you’ve got this! It all just boils down to bringing your whole self to the programming task and expanding your definition of success to more than lines of code produced. Remember, it’s also about team resiliency, better code choices, and ultimately better business outcomes.

With a few dozen pairing experiences under your belt, it becomes routine enough that you start to see ways it could be even better with a few tweaks. You’ll want to get more out of the experience and give more to your partners. You might be facing your first pair that really tries your patience or having difficulties and wondering if you’re the problem. That’s perfectly normal! Our next chapter looks at ways you can be an even better pairing partner.