AoAD2 Practice: Pair Programming

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Revised: July 16, 2021

Pair Programming

Developers, Whole Team

We help each other succeed.

Do you want somebody to watch over your shoulder all day? Do you want to waste half your time sitting in sullen silence watching somebody else code?

Of course not. Luckily, that’s not how pair programming works.

Pair programming involves two people working at the same computer, at the same time, on the same thing. It’s one of the most controversial Agile ideas. Two people working at the same computer? It’s weird. It’s also extremely powerful and, once you get used to it, tons of fun. Most programmers I know who tried pairing for a month found that they preferred it to programming alone.

Collective Code Ownership

More importantly, pair programming is one of the most effective ways to achieve collective code ownership and truly collaborate on code as a team.

Why Pair?

There’s more to pairing than sharing knowledge. Pairing also improves the quality of your results. That’s because pair programming doubles your brainpower.

When you pair, one person is the driver. Their job is to code. The other person is the navigator. Their job is to think. As navigator, sometimes you think about what the driver is typing. (Don’t rush to point out missing semicolons, though. That’s annoying.) Sometimes you think about what comes next. Sometimes you think about how your work best fits into the overall design.

This arrangement leaves the driver free to work on the tactical challenges of creating rigorous, syntactically correct code without worrying about the big picture, and it gives the navigator the opportunity to consider strategic issues without being distracted by the details of coding. Together, the driver and navigator produce higher-quality work, more quickly, than either could produce on their own.1

1One study found that pairing takes about 15 percent more effort than one individual working alone, but produces results more quickly and with 15 percent fewer defects. [Cockburn and Williams 2001] Every team is different, so take these results with a grain of salt.

Pairing also reinforces good programming skills. Delivering practices take a lot of self-discipline. When pairing, you’ll have positive peer pressure to do the things that need to be done. You’ll also spread coding knowledge and tips throughout the team.

Surprisingly, you’ll also spend more time in flow—that highly productive state in which you’re totally focused on the code. It’s a different kind of flow than when you’re working alone, but it’s far more resilient to interruptions. To start with, you’ll discover that your office mates are far less likely to interrupt you when you’re working with someone. When they do, one member of the pair will handle the interruption while the other continues working. Further, you’ll find that background noise is less distracting: your conversation with your pairing partner will keep you focused.

If that isn’t enough, pairing really is a lot of fun. The added brainpower will help you get past roadblocks more easily. For the most part, you’ll be collaborating with smart, like-minded people. Plus, if your wrists get sore, you can hand off the keyboard to your partner and continue to be productive.

Pairing Stations

To enjoy pair programming, a good workspace is essential, whether your team is in-person or remote. For in-person teams, make sure you have plenty of room for both people to sit side by side. Typical cubicles, with a monitor located in a corner, won’t work. They’re uncomfortable and require one person to sit behind the other, adding psychological as well as physical barriers to what’s meant to be peer collaboration.

You don’t need fancy furniture to make a good pairing station. A simple table will do. It should be six feet wide, so two people can sit comfortably side by side. Each table needs a high-powered development workstation. Plug in two keyboards and mice so each person can have a set. If people have a preferred mouse and keyboard, they can bring it with them. Make sure the USB ports are easily accessible in this case.

Splurge on large monitors so both people can see clearly. Be sure to respect differences in people’s vision needs, particularly with regards to font sizes and colors. Some teams set up three monitors, with the two outer monitors mirrored, so each person can see the code on a monitor in front of them, while using the middle display for additional material. If you do this, try installing a utility that makes the mouse wrap around the edges of your desktop. It will let both programmers reach the center screen easily.

If your team is remote, you’ll need a collaborative code editor and a videoconference. Make sure you have multiple screens, so you can see each other and the code at the same time.

There are a variety of IDE add-ins and standalone tools for collaborative editing, such as Code Together, Tuple, Floobits, and Visual Studio’s Live Share. You can also share your screen in your videoconferencing tool, but a collaborative code editor will allow you to switch drivers much more easily. If you have to use screen-sharing, though, you can hand off control by pushing the code to a temporary work-in-progress branch. Write a little script to automate the process.

Jeff Langr has a good rundown of remote code collaboration options in [Langr 2020].

How to Pair

I recommend pairing on all production code. Teams who pair frequently, but not exclusively, say they find more defects in solo code. That matches pair programming studies, such as [Cockburn and Williams 2001], that find that pairs produce higher quality code. A good rule of thumb is to pair on anything that you need to maintain, which includes tests and automation.

When you start working on a task, ask another programmer to work with you. If someone else asks for help, make yourself available. Managers should never assign partners: pairs are fluid, forming naturally and shifting throughout the day. Over the course of the week, pair with every developer on the team. This will improve team cohesion and spread skills and knowledge throughout the team.

Get a fresh perspective by switching partners.

When you need a fresh perspective, switch partners. I usually switch when I’m feeling frustrated or stuck. Have one person stay on task and bring the new partner up to speed. Often, even explaining a problem to someone new will help you resolve it.

It’s a good idea to switch partners several times per day even if you don’t feel stuck. This will help keep everyone informed and moving quickly. I switch whenever I finish a task. If I’m working on a big task, I switch within four hours.

Some teams switch partners at strictly defined intervals. [Belshee 2005] reports interesting results from switching every 90 minutes. While this could be a great way to get in the habit of switching pairs, make sure everybody is willing to try it.

When you sit down to pair, make sure you’re physically comfortable. If you’re colocated, position your chairs side by side, allowing for each other’s personal space, and make sure the monitor is clearly visible. When you’re driving, place the keyboard directly in front of you. Keep an eye out for this one—for some reason, people new to pairing tend to contort themselves to reach the keyboard and mouse rather than moving them closer.

Take a moment to check in with each other about each other’s preferences, too. When driving, do you want your navigator to give you time to think things through on your own? Or would you rather that they keep on top of things so you never have to stop and think? When navigating, do you want your driver to verbalize what they’re thinking, so you understand where they’re going? Or do you want to be able to concentrate on what’s next? Do you want strict separation of driver and navigator roles? Or a casual, informal approach?

Expect to feel clumsy and fumble-fingered, at first, when it’s your turn to drive. You may feel that your navigator sees ideas and problems much more quickly than you do. They do—navigators have more time to think than drivers do. The situation will be reversed when you navigate. Pairing will feel natural in time.

Test-Driven Development

Pairs produce code through conversation. As you work, think out loud. Take small steps—test-driven development works well—and talk about your assumptions, short-term goals, general direction, and any relevant history. If you’re confused about something, ask questions. The discussion may enlighten your partner as much as you.

As you pair, switch the driver and navigator roles frequently—at least every half hour, and possibly every few minutes. If you’re navigating and find yourself telling the driver which keys to press, ask for the keyboard. If you’re driving and need a break, pass the keyboard off to your navigator.

Energized Work

Expect to feel tired at the end of the day. Pairs typically feel that they have worked harder and accomplished more together than when working alone. Practice energized work to maintain your ability to pair every day.

Effective Navigating

When navigating, you may feel like you want to step in and take the keyboard away from your partner. Be patient. Your driver will often communicate an idea with both words and code. They’ll make typos and little mistakes—give them time to correct themself. Use your extra time to think about the bigger picture. What other tests do you need to write? How does this code fit into the rest of the system? Is there duplication you want to remove? Can the code be more clear? Can the overall design be better? Is there friction that should be polished away?

Pay attention to your driver’s needs, too. Somebody’s who’s unfamiliar with the IDE or codebase may need specific guidance. But resist the urge to micromanage. Give them room to figure out things on their own, if that’s what they prefer.

As navigator, your role is to help your driver be more productive. Think about what’s going to happen next and be prepared with suggestions. When I’m navigating, I like to keep an index card in front of me. Rather than interrupting the driver when I think of something, I write my ideas on the index card and wait for a break in the action to bring them up. At the end of the pairing session, I tear up the card and throw it away.

Spike Solutions

Similarly, when a question arises, take a moment to look up the answer while the driver continues to work. Some teams keep spare laptops on hand for this purpose. If you need more than a few minutes, pause coding to research the solution together. Sometimes the best way to do this is to split up, pursue parallel lines of inquiry, and come back together to share what you’ve learned. Spike solutions are a particularly powerful approach.

Although the navigator generally has more time to think than the driver, that doesn’t mean the driver is a mindless automaton. They’ll have design ideas too. Encourage your driver share their thoughts, and when they have a design idea for later, offer to make a note. Also, if you get to a tricky design question, it’s okay to stop coding, grab a whiteboard, and spend some time working through ideas together.

Teaching Through Pairing

Although pairing works best as a peer collaboration, sometimes people with different levels of experience will work together. In this situation, it’s important to restore the peer balance. Highlight the skills each person is bringing to the table. Even if one person needs to teach the other about the code, treat it as a lack of knowledge that’s easily rectified, not a lack of ability on the part of the learner, or sign of superiority on the part of the teacher.

The goal is to maximize the team’s performance.

If you need to bring your partner up to speed on some part of the code, remember to be patient. Teaching your pair partner how the code works slows you down, but the goal isn’t to maximize your performance... it’s to maximize the team’s performance. A good developer works quickly and well, but the best developers help everyone do so.

To use pairing to teach someone about the code, start by letting them drive. That will allow them to control the pace. As you guide them, refrain from telling them exactly what to do. Instead, provide big-picture direction—maybe even start with a whiteboard diagram—and give them space to figure out the details.

For example, when making changes to a service, don’t say, “We need to change SuperMailClient. Click source... now click infrastructure... now click rest...” Instead, provide context and direction: “Our task is to replace our transactional mail vendor, SuperMail, with BetterMail. They both provide REST APIs, so all we need to do is change our SuperMail wrapper to use BetterMail instead. (Sketches the project structure on the whiteboard.) All our REST clients are in the infrastructure/rest folder and each service has its own wrapper.” Then let your partner navigate through the project files and find the file to work on themselves.

Once the person you’re teaching can find their way around, you can switch roles. Ask them to navigate and tell you what needs to be done next. Be careful, though: when you’re driving, it’s tempting to rush ahead and just do what you know needs to be done. For it to work as a teaching technique, you have to suppress that desire and let your partner set the pace.


Pairing can feel awkward or unpleasant at first. These feelings are natural and typically go away after a month or two. Here are some common challenges and how to resolve them:


It bears repeating: pairing is no fun if you’re uncomfortable. When you sit down to pair, adjust your position and equipment so you can sit comfortably. Clear debris off the desk and make sure there’s room for your legs, feet, and knees. Check in with your partner about font sizes and monitor position. If you’re pairing remotely, take time before you begin to make sure all your tooling is set up and frictionless.

Some people (like me) need a lot of personal space. Others like to get up close and personal. When you start to pair, discuss your personal space needs and ask about your partner’s.

Similarly, while it goes without saying that personal hygiene is essential, remember that strong flavors such as coffee, garlic, onions, and spicy foods can lead to foul breath.

Introversion and social anxiety

Introverts often worry pairing won’t work for them, but—as an introvert myself—I haven’t found that to be true in practice. Although pairing can tiring, it’s also very focused on ideas and results. There’s no need to engage in small talk, and you’re typically working with people who you know well and respect. It’s a very productive, very cerebral collaboration, and that can be a lot of fun. Most introverts I’ve met who have tried pairing have liked it, once they got past the initial learning curve.


Of course, people don’t fit neatly into predefined personality trait boxes. Pairing—and Agile in general—can be difficult for people with social anxiety. If you think pairing might be difficult for you or someone on your team, talk about ways to make pairing more comfortable, or if there are other ways your team can achieve collective code ownership. The alignment session is a good time for this conversation.

Communication style

New drivers sometimes have difficulty involving their partners; they take over the keyboard and shut down communication. To practice communicating and switching roles while pairing, consider ping-pong pairing. In this exercise, one person writes a test. The other person makes it pass and writes a new test. Then the first person makes it pass and repeats the process by writing another test.

Another approach to try is strong-style pairing. In strong-style pairing, invented by Llewellyn Falco, all ideas must pass through the other person’s fingers. [Falco 2014] So if you come up with an idea, you have to pass the keyboard to the other person and tell them how to implement it. Then when they come up with an idea, they pass the keyboard back to you and tell you what to do. Even if this isn’t something you want to do all the time, it’s a great way to practice communicating with your partner.

The flip side of too little communication is too much communication—or rather, too much blunt communication. Frank criticism of code and design is valuable, but it may be difficult to appreciate at first. Different people have different thresholds, so pay attention to how your partner receives your comments. Try transforming declarations (such as “This method is too long”) into questions or suggestions (“Could we make this method shorter?” or “Should we extract this code block into a new method?”). Adopt an attitude of collaborative problem solving. See “Learn How to Give and Receive Feedback” on page XX for more ideas.

Tools and keybindings

Even if you don’t fall victim to the endless vi vs. emacs editor war, you may find your coworkers’ tool preferences annoying. Try to standardize on a particular toolset. Some teams even create a standard image and check it into version control. When you discuss working agreements during your alignment discussion, discuss these issues as well.

Keyboards and mice can be another source of contention. If they are, you don’t have to standardize. People with strong input device preferences can take their devices with them when they switch pairing stations. Just make sure they have easily-accessible USB ports.


Isn’t it wasteful to have two people do the work of one?

In pair programming, two people aren’t really doing the work of one. Although only one keyboard is in use at a time, there’s more to programming than typing. One person is programming and the other is thinking ahead, anticipating problems, and strategizing.

How can I convince my team or organization to try pair programming?

Ask permission to try it as an experiment. Set aside a month in which everyone pairs on all production code. Be sure to keep going for the entire month, as pair programming may be uncomfortable for the first few weeks.

Don’t just ask permission of management; get the consent of your fellow team members, too. They don’t have to love the idea, but do make sure they’re not opposed to it.

Do we really have to pair program all the time? Some code doesn’t need it.

If you’re bored while pairing, it’s an indication of a design flaw.

Some production tasks are so repetitive, they don’t require the extra brainpower a pair provides. Before abandoning pairing, however, consider why your design requires so much repetition. It’s a common indication of a design flaw. Use the navigator’s extra time to think about design improvements and consider discussing it with your whole team.

How can I concentrate with someone talking to me?

When you navigate, you shouldn’t have too much trouble staying several steps ahead of your driver. If you do have trouble, ask your driver to think out loud so you can understand their thought process, or ask to drive so you can control the pace.

As driver, you may sometimes find that you’re having trouble solving a problem. Let your navigator know—they may have a suggestion that will help you through the roadblock. At other times, you may just need a few moments of silence to think through the problem. It’s okay to say so.

Test-Driven Development
Spike Solutions

If you find yourself in this situation a lot, you may be taking steps that are too large. Use test-driven development and take very small steps. Rely on your navigator to keep track of what you still need to do (tell them if you have an idea; they’ll write it down) and focus only on the few lines of code needed to make the next test pass.

If you’re working with a technology you don’t completely understand, consider taking a few minutes to work on a spike solution. You and your partner can work on this together or separately.

What if we have an odd number of programmers?

Mob Programming
Blind Spot Discovery
Zero Friction

If your team room includes a mobbing station, you can form a “mini-mob” of three people. Otherwise, there are many ways for a programmer flying solo to be productive without touching production code. They can research new technologies or learn more about a technology the team is using. They can pair with a customer or tester to review recent changes, polish the application, or do exploratory testing. They can take care of administrative tasks for the team, such as responding to team emails.

Alternatively, a solo programmer may wish to improve the team’s capacity. They can research solutions to friction the team is experiencing, such as slow builds, flaky tests, or unreliable deployment pipelines. They can review the overall design—either to improve their own understanding or to come up with ideas for improving problem areas. If a large refactoring is partially complete, the team may wish to authorize a conscientious programmer to finish those refactorings.


Pairing requires a comfortable work environment. Most offices just aren’t set up that way. Before trying pairing full-time, adjust your physical space. If your team is remote, get your tooling in place.

Make sure everyone wants to participate before you try pairing. Pairing is a big change to programmers’ work styles and you may encounter resistance. I usually work around this by asking people to try it for a month or two, then decide. If that doesn’t work, you can try pairing part-time, or with just the people who are interested, although I find that pairing works best when the whole team does it full-time.

Mob Programming

Mob programming tends to be less intimidating than pairing. If people don’t want to try pairing, see if they’d like to try mobbing instead.


When your team pairs well:

  • You’re focused and engaged throughout the day.

  • You enjoy the camaraderie of working with your teammates.

  • At the end of the day, you feel tired and satisfied.

  • For small interruptions, one person deals with the problem while the other continues working. Afterwards, they slide back into the flow of work immediately.

  • Internal quality improves.

  • Knowledge and coding tips travel quickly through the team, raising everyone’s level of competence.

  • New team members integrate into the team quickly and easily.

Alternatives and Experiments

Pairing is a very powerful tool. Other than mobbing, I’m not aware of any other technique that’s as effective. Give pairing (or mobbing) a real try before experimenting with alternatives.

When you look at alternatives, don’t make the mistake of thinking that pairing is just a fancy type of code review. To truly replace pairing, you need to replace all these benefits:

Collective Code Ownership

Code quality. Because pairing brings so many perspectives to the code, and results in so much conversation about the code, it reduces defects and improves design quality. The frequent pair switching shares knowledge amongst team members, which enhances collective code ownership. By having people work together, it helps people focus, supports self-discipline, and reduces distractions. It does all this without sacrificing productivity.

Formal code reviews can also reduce defects, improve quality, and support self-discipline. In a sense, pairing is just continuous code review. Code reviews don’t share knowledge as thoroughly as pairing, though, so if you’re using collective code ownership, you probably need to supplement code reviews with additional design discussions.

Flow. Pairing’s benefits to flow are more subtle. Because it focuses two people on the same problem, pairing is sort of like having a backup brain. If one person gets distracted, the other person can “reboot” their attention and get them back on track quickly. It’s also easier to ignore the ever-present distractions provided by smartphones, email, instant messaging, and the other demands on our attention. In an environment without pairing, you’ll need another way to help people stay focused.

Collaboration. Pairing’s resilience to distractions makes intra-team collaboration easier. Ideally, when one team member gets stuck on a question that another team member can answer, you want them to ask for help rather than spinning their wheels. If you’re pairing, there’s very little cost to answering a question, because your pairing partner keeps working. It makes sense to ask for help any time you need help.

If you aren’t pairing, interruptions are much more costly. Now you have to decide whether the time saved by asking the question is worth the disruption to someone else’s flow. In practice, there’s far less collaboration on a team that doesn’t pair.

Noise cancellation with situational awareness. Pair programming has another benefit that’s even less obvious. In a physical team room, pairing creates a low buzz of conversation. You might expect this to be distracting, but it actually recedes into the background as your brain focuses on your interaction with your partner. But the background conversation still enhances your situational awareness. It’s the cocktail-party effect: When somebody says something important to you, your subconscious picks it out of the background and brings it to your conscious attention.

For teams that don’t pair, side conversations are distracting and can make it hard to concentrate. In that situation, independent offices or cubicles—or headphones—can be better. But now you don’t have the same situational awareness.

In other words, pairing has a lot of unobvious benefits that reinforce other Agile practices. Although it’s definitely weird, and can be a lot to ask, it’s worth putting in the effort to give it a real try. Don’t just dismiss it out of hand. If pairing isn’t a good fit, try mobbing instead.

Further Reading

Pair Programming Illuminated [Williams 2002] discusses pair programming in depth.

“The Costs and Benefits of Pair Programming” [Cockburn and Williams 2001] reports on Laurie Williams‘ initial study of pair programming.

“Promiscuous Pairing and Beginner‘s Mind: Embrace Inexperience” [Belshee 2005] is an intriguing look at the benefits of switching pairs at strict intervals.

“Adventures in Promiscuous Pairing: Seeking Beginner‘s Mind” [Lacey 2006] explores the costs and challenges of promiscuous pairing. It‘s a must-read if you plan to try Belshee‘s approach.

XXX Peer Reviews in Software: A Practical Guide (Wiegers)?


XXX Avi Kessner recommends discussing "accidental diminishers." From Multipliers: How the Best Leaders Make Everyone Smarter (Wiseman, Liz, McKeown, Greg)? (Put in Team Dynamics instead?)

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.