What Pair Programming Actually Is

Pair programming is a working method where two developers write code together at a single machine. While the mechanics are simple, the practice involves continuous communication: pairs plan their work, discuss approaches, and make decisions while they code. It has existed in some form since the earliest days of programming — Jean Bartik, one of the ENIAC programmers, described working as a pair in the 1940s because two people could criticise each other, spot each other's errors, and combine the best ideas. The term became widely known decades later when Kent Beck described it in his 1999 book Extreme Programming.

Pairing is straightforward in principle: two developers sit together and write one piece of code. In practice, however, there are several modes of collaboration, and the benefits only show clearly in the medium and long term. Because it can feel awkward at first, many teams dismiss it before the advantages become visible. But pairing is a foundation for collaborative teamwork and consistently high-quality software.

How to Pair

There are several ways to structure a pairing session, and the most suitable approach depends on the people, the task, and how much experience each developer has with the codebase.

The most common arrangement is the driver-navigator split. One person — the driver — writes the code and focuses on the immediate mechanics: syntax, method names, and the current line of work. The other person — the navigator — thinks ahead, scans for errors or edge cases, and plans the next steps. The navigator is not a passive observer; this role involves active review and strategic thinking. The pair should switch roles regularly to avoid fatigue and keep both developers engaged.

This mode works best when both people are at roughly similar levels of familiarity with the codebase, and it is especially effective when both want to be continuously involved in writing and reviewing the same code. Experienced practitioners often say the balance of think-aloud discussion and shared keyboard time is what differentiates pairing from simply having someone watch you work.

Ping-Pong Pairing

For teams working test-first, a useful variation is ping-pong pairing. One developer writes a failing test, then passes the keyboard to the other developer, who makes the test pass and writes the next failing test. The roles alternate in a rhythm that keeps both people actively involved in the test-code loop.

Expert-Novice Pairing

When one person knows the domain and the other knows the tooling, or one knows the codebase and the other is new, the pairing serves a mentoring function. The more experienced person steers the design while the less experienced person drives the keyboard, or vice versa. The goal here is not just the code but the transfer of knowledge. This mode requires patience and explicit attention to explaining decisions as they are made.

Yes-And Pairing

Some pairs abandon fixed roles altogether and simply work side-by-side, thinking aloud and sharing ideas fluidly. Both developers are fully engaged in every line, critiquing and refining the code as it emerges. This mode is Improv-inspired: the participant must accept what the other has written and build on it rather than starting over. It works best when both developers are confident in the codebase and comfortable with extended, unstructured dialogue.

The Benefits of Pairing

Some benefits of pairing are immediate, such as reduced code review cycles and fast feedback on design decisions. Others are longer-term, and it is these that make pairing a worthwhile investment for many organisations.

First, pairing improves quality. Two developers looking at the same code find design issues, edge cases, and bugs earlier than a single developer working alone. The immediate, continuous code review during a pairing session catches problems before they become expensive to fix. Teams that pair consistently produce cleaner, more maintainable code because each line is effectively seen by two people before it lands.

Second, pairing builds shared knowledge of the codebase. When two people work together and change roles, the knowledge does not stay in one head. If one developer leaves the team or changes focus, the other can take over without a long knowledge transfer. Legacy solutions, quirks, and unspoken conventions become part of the shared mental model of the team, not just the memory of one individual.

Third, pairing supports onboarding. New team members join and learn the conventions, tools, and structure of the project much faster when they pair with an experienced developer in their first weeks. The newcomer gets context that would take far longer to absorb by reading code alone, and the experienced developer gets another perspective on the codebase.

Finally, pairing — done well — contributes to team awareness. Each person has a better understanding of what others are working on, which improves coordination and planning. In our experience, teams that pair better understand the overall shape of the product and the codebase, leading to better integration and fewer surprises at merge time.

Untangling the Challenges

Pairing, despite its advantages, has genuine challenges. It is tiring to work this closely with someone for hours, and not everyone responds to this kind of sustained cognitive load in the same way. Pairs need to take breaks, and pairing sessions should not stretch for an entire day. Sustainable pairing requires reserving pair sessions for tasks where the collaboration is genuinely useful — not forcing a pair onto trivial changes, or pairing two people who are not ready to work well together.

A common complaint is that pairing slows everyone down because there is only one keyboard. In the early stages on certain mechanics-heavy tasks, a driver will indeed work slower because they need to explain and think aloud. That is a deliberate trade-off; the resulting reduction in review cycles and defects usually compensates. But pairing also needs to be adjusted to the situation: someone who is deeply focused on a complex, solitary problem may work better alone for a while, as long as the product is shared concrete between the two of them.

Personality friction or a mismatch in working styles can also sour a pairing experience. Pairing requires respect for the other person's approach, and a willingness to switch between driving and navigating or accepting the other's idea for a moment. When people resist pairing because they prefer to work alone, it's usually because they fear losing autonomy or do not yet see the value of the sustained collaboration.

Distance complicates pairing further. Remote pairing is possible, but only if both people take extra care with tooling and with speaking up. Text-based communication and share screens can lag, and the loss of body language makes it harder to read whether the other person is engaged or lost. For more on this, we have compiled a separate set of materials on remote pairing.

Pairing is not an all-or-nothing choice either. The reality in our teams is that there are tasks which greatly benefit from pairing, and there are tasks which are better done alone. The art is to choose deliberately.

To Pair or Not to Pair?

Still, pairing brings its full value only when used consistently, not merely for the occasional complicated task. The most pronounced positive impact on team flow and knowledge distribution appears when the more common activities are also paired — the design sessions, the test writing, the bug analysis — so that collaboration becomes the default behaviour of the team rather than a special event.

As a team, agreeing on when to pair and when to work alone in an explicit, respectful way is important. The planning meeting is a good time to allocate time for solitary work on tasks that need deep concentration, and pair sessions for tasks where collective knowledge or review is valuable. This separates the decision from the moment of implementation, reducing friction and making both ways of working acceptable.

But Really, Why Bother?

Looking at pairing in the grand scheme of team flow and collaboration, the long-term benefits touch much more than the final line count of the production code. Pairing strengthens the team's communication, and communication is what drives software quality in large codebases. When a team understands how its members work, when decision-making is distributed across several heads, and when knowledge does not reside in just one developer, the team and the product become far more robust in the face of change and personnel turnover.

Pairing is not a panacea. It is not a technique for every hour of every working day. But when used as a tool by a team that sees it as a foundation for its collaborative craft, it pays off more than it costs — in better code, in better understanding, and in a healthier team.

Pairing goes back a long way. There are reasons why the first programmers worked in pairs and why a major agile methodology enshrined it as a practice. The question is not whether pairing works, but how a team uses it to its own advantage.

The Mechanics of Good Pairing Sessions

Once you've decided to pair, the next question is how. Most pairing styles build on two familiar roles, though the way those roles interact varies considerably depending on what you're trying to achieve.

Role-Based Styles

The classic Driver and Navigator split is the foundation for many approaches. The driver sits at the keyboard and focuses exclusively on the small tactical goal in front of them, narrating their actions as they go. The navigator, watching over the driver's shoulder, reviews the code in real time, keeps the larger objective in view, and notes upcoming obstacles or next steps without getting lost in implementation details.

A typical flow works like this:

  • Start with a reasonably well-defined task.
  • Agree on one tiny goal at a time—defined by a unit test, a commit message, or even a sticky note.
  • Switch keyboard and roles regularly to keep energy levels up and ensure shared understanding.
  • As navigator, resist the urge to jump into tactical details. Park observations on sticky notes for later discussion so you don't interrupt the driver's flow.

Ping Pong adapts these roles to Test-Driven Development. Developer A writes a failing test (the ping). Developer B writes the minimal implementation to make it pass (the pong), then immediately writes the next failing test. Each cycle can also include a brief refactoring phase, following the red-green-refactor rhythm.

Strong-Style Pairing prioritizes knowledge transfer over speed, based on a simple rule: an idea must go through someone else's hands to reach the computer. The more experienced partner stays in the navigator role while the novice drives, trusting the directions even with incomplete understanding. The goal is to favor active learning over passive observation, though the technique borders on micro-management and should be phased out once the transfer has taken hold.

Beyond Coding: Pair Development

Pairing doesn't stop at the code editor, and the Pair Development mindset treats the whole feature lifecycle as a shared responsibility. This approach is especially valuable in the early stages, where catching misunderstandings saves significant time downstream.

  • Planning: Read the story together, verify understanding, and agree on an approach. Write down the steps and testing strategy as a shared reference.
  • Research: For unfamiliar technologies, split up to answer specific questions separately, then reconvene after a set timebox to compare findings. Browsing results together on one screen is rarely effective.
  • Documentation: Work on it together or have one draft and the other review. Pairing provides a natural accountability mechanism for tasks like documentation that are easy to postpone or skip.

Managing Time and Energy

Pairing requires deliberate attention to scheduling, since two people's calendars need to align. Start the day with a shared check-in: how many hours will you pair, what commitments exist on either side, and how will you prepare if one of you must work solo for a stretch? If your team pairs by default, consider establishing core coding hours for everyone to simplify scheduling.

The pomodoro technique is a useful complement to almost any pairing style. Working in 25 minute chunks with breaks in between helps mitigate the mental fatigue that pairing can create and provides a natural cadence for switching drivers.

  • Decide on the next task.
  • Set a timer for 25 minutes.
  • Work without interruption until the timer rings.
  • Take a 5-10 minute break—step away, get water, avoid email.
  • After 3-4 pomodoros, take a longer break of 15-30 minutes.

Pair Rotations and Context Costs

Rotating pairs means one person leaves a story while the other, often called the anchor, onboards a new partner. Rotations happen for practical reasons—sickness, holidays, remote days requiring on-site presence—and for more deliberate reasons: breaking up long stretches together, bringing fresh energy to tedious work, or spreading knowledge more widely across a team.

The frequency of rotations is a matter of trade-offs. Frequent rotations every few days maximize the number of eyes on each line of code and build collective ownership, but every switch carries costs: time to onboard, context switching, and the risk of losing tacit knowledge if no consistent anchor remains. Junior developers in particular may benefit from longer assignments that allow deeper immersion. If your team already has strong documentation, readable code, and regular knowledge sharing, forcing very frequent rotations may deliver only marginal benefit with significant overhead.

Practical Setup Considerations

Physical Space

Pair programming requires physical proximity in a way that individual work doesn't. Spend time in advance figuring out a comfortable arrangement for both people:

  • Clear the desk so both have enough space to work.
  • Make sure chairs and equipment don't crowd each other.
  • Decide on one or two keyboards and mice—there's no universal rule, so try different configurations based on your space and preferences.
  • Use an external monitor if available; otherwise consider screen sharing as if you were remote.
  • Ask about preferences like font size or contrast.

If you use an unusual keyboard or IDE configuration, confirm your partner is comfortable with it, and consider maintaining a standard setup for pairing sessions. A team-wide default configuration reduces repeated friction.

Remote Pairing

Pairing remotely is entirely feasible with stable internet and the right tools. A screen-sharing solution that allows both parties to control the machine is essential. Many commercial video conferencing tools support this directly, while options like jitsi, SSH with tmux for low-bandwidth connections, or the Live Share extension for Visual Studio Code are solid alternatives.

  • Use video: Seeing facial expressions adds nuance. If the main tool doesn't support simultaneous screen and video, consider a second call for video only.
  • Collaborative boards: Online whiteboards replicate the experience of sketching out designs together.
  • Audio quality: A quiet space and a good headset, ideally with a directional microphone, help on both sides. Noise-cancelling headphones minimize distraction.
  • Network lag: Alternate who drives so each person regularly works on their own machine without lag. Avoid scrolling through long files; use keyboard shortcuts to jump to specific code sections.

When only some team members are remote, make a deliberate effort to keep the remote partner included in incidental office discussions. For teams that never meet in person, pairing provides a rare chance to build rapport—consider scheduling a remote coffee together. Remote pairing does carry a bonus: with good headphones on, it's often easier to block out office distractions than when pairing on site.

Common Pitfalls and What to Do Instead

Even with good technique, pair programming comes with predictable failure modes worth watching for:

  • Drifting apart: Avoid reading email or using your phone during a session. If something genuinely needs attention, say so transparently. Reserve solo time for individual obligations instead.
  • Micro-management: Endless directives like “now type System dot print” leave no room for your partner to think. If you catch yourself doing this, step back to high-level guidance.
  • Impatience: As navigator, apply a five-second rule before commenting on an error or obstacle—the driver may already be on it. Waiting preserves their flow and lets them correct course themselves.
  • Keyboard hogging: If one person controls the keyboard for nearly the entire session, the other disengages. Rotate keyboard control frequently.
  • Sustained over-pairing: Full-day pairing sessions are exhausting and rarely practical, given the other demands of a workday. Plan for pairing as part of the day, not the entire day.

Finally, celebrate successes together when you complete a task, even with something as simple as a high-five. And remember that the right pairing style depends on your personalities, experience, and the task at hand. There isn't one correct way—the point is that the collaboration delivers its intended benefits. If it doesn't, discuss, adapt, and try another approach.

Why Pair Programming Works

Pair programming is a tool for improving software quality and keeping the team moving. Knowing what it offers helps you decide when to use it, how to do it well, and why it's worth the effort.

Spreading Knowledge

The clearest benefit is knowledge sharing. With two people on a task, technology and domain expertise spreads through the team on a daily basis instead of pooling in one person. Two minds working on a problem also explore more alternatives, since different experiences and perspectives lead to a richer discussion of possible solutions.

  • Pair on tasks outside your comfort zone. If you always stay where you're strongest, you miss the chance to learn and to pass that expertise along.
  • Watch for teammates who repeatedly pick up the same type of work. Encourage them to vary their focus.
  • A visible skill matrix—covering tech and business topics with each person's strengths and gaps—helps the team plan for a good spread of knowledge.

Forcing Reflection

Explaining an idea out loud forces you to examine it. Pairing pushes you to discuss approaches rather than just thinking them through internally. That scrutiny isn't limited to code and design; it also applies to the user story itself and the value it's supposed to deliver. This works best when both people trust each other enough to ask questions and admit confusion. Regular one-on-ones and feedback sessions build that trust.

Maintaining Focus

Two people working together naturally fall into a more structured rhythm. You have to say what you're doing and why. That explicit communication keeps you from the solo-developer trap of chasing a "quick" tangent and emerging from the rabbit hole hours later. Your partner keeps you anchored to the task and helps you decide what actually matters for finishing the story.

  • Plan before you write code. Break the task into steps, write them on sticky notes or as subtasks in your tracking tool, and work through them in order. Combine this with the Pomodoro technique if it helps: aim to complete one step per pomodoro.
  • Keep asking each other for explanations. Communication is the mechanism that keeps the session productive.

Review as You Go

With four eyes on the work from the start, mistakes are caught during development, not after. Refactoring is part of any coding session, and it's easier when you have someone to discuss naming or structural changes with. Pairing reduces the burden on post-hoc code review, which is a reactive process that can be less efficient.

  • Use questions to push for clarity. If either of you can't easily read and understand the code, rewrite it so you can.
  • If you still feel the need to review pair-programmed code heavily, ask why. Did you leave questions unraised during the session? What would you change about how you paired?

Combining Two Ways of Thinking

In the classic driver/navigator setup, the driver's focus is tactical—on the current line and its details. The navigator can hold a more strategic view, tracking the big picture and parking ideas for later. No single brain comfortably switches between those two modes quickly. Having both perspectives simultaneously improves quality because details and context both get attention.

  • Rotate the keyboard regularly. It refreshes both of you and gives each person practice in both thinking styles.
  • Navigators: resist the pull to micro-manage the code. Stay at the strategic level and complement the driver's tactical work with medium-term thinking.

Toward Collective Ownership

With consistent pairing, every line is seen or touched by at least two people. That broadens comfort with the codebase across the whole team and tends to produce more consistent code than solo work does.

Collective code ownership abandons any notion of individual ownership of modules. The code base is owned by the entire team and anyone may make changes anywhere.

-- Martin Fowler

Pairing on its own is not enough. You still have to rotate pairs and move people across different parts of the codebase, or you'll just trade individual silos for pair-based ones.

Lowering Work in Progress

Limiting work in progress is core to improving team flow. Pairing naturally constrains how many tasks a team can handle in parallel, which reduces the inefficiency of multi-tasking at both individual and team levels. With fewer streams of work, the team concentrates on the important tasks, blockers get addressed immediately, and work moves more steadily.

  • Set your team's WIP limit to the number of developer pairs you have. Make the board—physical or online—clearly show the limit. Check it before picking up new work. The discipline can even nudge the team toward pairing by default.

Faster Onboarding

Pairing accelerates onboarding because new team members absorb project, business, and org knowledge while working alongside someone. Team changes temporarily disrupt flow, and pairing forces more communication than solo work, which can soften that impact. But it's not automatic.

  • Give new joiners the big picture and broader context before they start pairing, and set aside extra time for the onboarding process itself. Pair on the new person's machine so they get set up to work independently.
  • Maintain an onboarding checklist of topics. Some topics need dedicated sessions; others can be covered indirectly through pairing. When a topic comes up in a session, check it off. The list makes onboarding progress visible to the whole team.

When Pairing Gets Hard

Pair programming brings real benefits, but it also demands practice, patience, and a willingness to work through friction. Teams that push past the rough patches often find the payoff is worth the effort. The trick is knowing what you want to get out of pairing so you can adapt the practice to your own context.

Mental Fatigue

Sustained focus is a hallmark of pairing, but it can also drain you. When you work alone, you can drift off, take breaks on a whim, or let your mind shut down for a moment. Pairing keeps you alert and requires constant alignment with another person's rhythm and thinking style. That intensity is what makes it productive, but it can also be exhausting.

Take breaks deliberately. If you tend to forget, set an alarm for something like 10 minutes every hour, or try a time-management method like Pomodoro. Don't skip lunch; stepping away from the monitor actually boosts productivity. Cap your pairing sessions at about 6 hours per day rather than trying to pair through a full 8-hour shift, and switch roles between driver and navigator regularly to keep energy up.

The Difficulty of Close Collaboration

Working shoulder-to-shoulder with someone for hours is intense. It demands constant communication, empathy, and interpersonal skill. You may clash over technique, knowledge levels, personality, or problem-solving approaches. Some combinations start rocky and need deliberate effort to become mutual learning rather than mutual frustration.

Begin sessions by aligning on how you want to work together. Ask each other questions like "How do we want to operate?" and "What's your preferred pairing style?" Be honest about how you work best, but stay open to other approaches. End a pairing day with a short feedback round — think of it as a mini retrospective rather than a critique session. Reflect on your alertness, comfort, how often the keyboard changed hands, and whether you hit your goals. Make this a routine early so that giving feedback feels natural when something actually goes wrong. Resources on difficult conversations and interpersonal conflict can also help. Encourage the whole team to take on pairing challenges collectively, especially by gathering everyone's hot-button triggers.

Meetings Eating the Day

Meetings interrupt flow for any team, but for pairs the disruption compounds. If each person's meetings land at different times, effective pairing time shrinks quickly.

Set boundaries such as core pairing hours with no meetings, or insist on no meetings after noon. Audit which meetings are really necessary, push for better facilitation and clear agendas, and shorten where you can. When meetings are unavoidable, check calendars together at the start of the session. Consider attending meetings as a pair, and lean on your product owner or other non-pairing team members to shield the pair from interruptions during the core hours.

Mismatched Skill Levels

When experience differs, assumptions can sour the session. The more senior person might assume they know best; the less experienced one might assume they have little to offer. Both are wrong.

Ask questions about the "how" and "why" behind choices — explaining reasoning can surface new insights for the expert. At the same time, remember that a fresh perspective may see what the veteran's blinders miss. Explaining a concept is also a way for the expert to test their own understanding. Understanding where each of you sits on the Dreyfus model of skill acquisition can help you appreciate the different stages of learning and what they mean in practice.

Power Dynamics Few Teams Talk About

Pairing happens inside hierarchies, formal and informal. A manager paired with a report, a junior with a senior, a career changer with a CS graduate — these pairings carry weight that predates the session. Power dynamics are also intersectional, so multiple ones may overlap.

The heavier load sits with the person on the upward side: acknowledging their position is the first step toward neutralizing it. Only then can you honestly assess how dynamics shape the interaction. Ask yourself what you can do to level the field. Recognize where you sit in relation to your partner and reflect on how that shows up in practice. It can be exhausting, but anti-bias or ally-skills training offers a structured route forward.

Nobody Knows the Answer

When nobody in the pair has any idea how to approach a problem — new technology, an unfamiliar pattern — the usual pairing rhythm often breaks down. Research and experimentation can be frustrating, as people read at different speeds and try things in different orders.

Consider a spike to explore the technology before the real work begins. Share findings with the team afterward. Shift mindset from pair programming to pair development — splitting up independently for research is acceptable as long as you agree upfront on the questions you need answered.

No Time for Solitude

Constant collaboration is energy-draining, especially for introverted people. Alone time for focused digging or spontaneous learning can feel like an interruption to the pair.

Keep pairing to a maximum of 6 hours a day, agree on core coding hours, and block out a few hours for solo learning when needed. If the pair lacks collective knowledge, split up to read and then share what you learned before continuing implementation.

Context Switching from Rotations

Rotations spread knowledge across the team, but too many produce frequent context switches that hurt momentum. A new pairing partner needs a baseline understanding of the story to contribute meaningfully. Find the balance between rotation frequency and the time needed to get up to speed. Don't rotate merely for the sake of it.

Vulnerability Is the Price of Admission

To pair requires vulnerability. It means sharing all that you know and all that you don't know. This is hard for us. Programmers are supposed to be smart, really-crazy-smart.

Pairing exposes what you don't know, which is uncomfortable in an industry prone to hero-worship and judgment of past choices. Yet research shows vulnerability is a necessary condition for innovation. For that to happen, the environment must feel safe. Those with institutional or earned authority should model openness first, demonstrating that imperfection is acceptable and making it easier for everyone else to follow. Regular check-ins and a healthy feedback culture do the groundwork.

Winning Over Skeptics

There's no magic formula for persuading managers or coworkers that pairing is worth it. Start by talking about it so everyone shares the same understanding. Then propose a low-stakes experiment: a single pair who reports back, or a default-to-pairing trial for two sprints with structured feedback along the way. People cannot be forced into a practice, and pairing doesn't suit everyone, so expect to start with part of the team. Seeing and experiencing it in action usually does the convincing.

On the economics question, there is one frequently cited study suggesting pairing is worth the cost, but robust evidence is scarce. Development involves analysis, testing, and quality work that defies simple measurement. Rather than trying to scientifically prove productivity, focus on demonstrating that pairing works in your specific context. The only way to do that is to try it for real.

Pairing Is a Default, Not a Dogma

Pair programming has proven to be a cornerstone practice for building high-quality, maintainable software sustainably. Yet treating it as an absolute rule is counterproductive. The most effective approach is to establish pairing as a team's default working mode, then explicitly discuss and agree on exceptions. The specifics—how much pairing, which tasks warrant it, and how it's executed—should always be flexible.

Going Solo on the Routine Stuff

Not every coding task demands a second set of hands. Work that follows a well-defined, established boilerplate approach may not significantly benefit from knowledge sharing or live review, since the team has typically already mastered the pattern. In those cases, pairing can add little value.

However, there's a caveat worth heeding. Repetitive tasks are often a red flag for underlying design problems. Pairing on such work can reveal opportunities to build a more effective abstraction. Additionally, the brain tends to slip into autopilot during "easy" work, making simple yet critical errors more likely.

Pairing offers an accelerated learning curve for junior programmers, but it can also breed self-doubt. A newer developer may wonder if they can actually perform without a more experienced teammate observing over their shoulder. They also miss the essential experience of independently navigating frustration, debugging, and unobserved experimentation that builds deep expertise. Confronting a problem before being given its solution often provides a more effective learning experience.

Teams can counteract this in a few ways. Allowing junior developers to work solo intermittently, while a mentor checks in regularly and conducts code reviews, builds independence. Alternatively, pairing junior developers together lets them problem-solve collaboratively while still digging their way out of rabbit holes faster than they would alone. Crucially, when a senior and junior pair up, the senior should spend most of their time in the navigator's role, giving the driver space to figure things out—sometimes waiting a beat to hit the next obstacle together is more instructive than pointing it out in advance.

Why Code Review Falls Short

The advantage of pair programming is its gripping immediacy: it is impossible to ignore the reviewer when he or she is sitting right next to you.

— Jeff Atwood

A common argument is that a solid code review process eliminates the need for pairing. We strongly disagree. Code reviews are not an adequate substitute.

First, several dynamics can render reviews superficial. Coders may intentionally defer minor decisions and fixes, assuming the reviewer will catch them, while the reviewer, in turn, trusts the coder's diligence and doesn't scrutinize the code closely. The sunk cost fallacy also comes into play—teams are often reluctant to request rework on code that already took time and effort to produce.

Second, reviews can seriously disrupt a team's flow. Every review demands a context switch, and to keep changes small and integration constant, reviews must happen frequently. This creates a potential bottleneck that adds time pressure and undermines review quality.

In a Continuous Integration environment, especially with trunk-based development, delayed reviews become even less effective since code merges to the main branch immediately. Pairing and CI are natural partners. Many teams successfully default to pairing while reserving pull requests and code reviews for occasions when production code must be changed solo. In such cases, teams must vigilantly monitor that pull requests remain short-lived to preserve continuous integration practices.

Friction Is the Point

We've extensively discussed the challenges that make pairing hard. So why subject a team to it? Because the skills required for successful pairing—concentration, task organization, time management, communication, feedback, empathy, vulnerability, and the rest—form the underpinnings of any well-functioning, collaborative, and effective team. Pairing provides a structured way for everyone to practice these skills together.

Team performance is also boosted by diversity, though diverse perspectives often introduce initial friction. This can amplify pairing's challenges, such as asking team members to be vulnerable, a request that falls heaviest on those from underrepresented groups. As the Harvard Business Review notes, "Diverse Teams Feel Less Comfortable - and That's Why They Perform Better." The fluency heuristic—our tendency to favor information that's easier to process—makes us lean toward homogeneity and simplicity. While that bias serves us in much of software development, it works against the value of pairing.

Pairing feels difficult at first, but difficulty isn't a sign it's bad for the team. In her talk, Pia Nilsson describes how her team at Spotify overcame the friction of practices like pairing by deliberately cultivating a feedback culture, non-violent communication, psychological safety, humility, and a shared sense of purpose.

Agile, extreme programming, and pairing are all built around embracing change. Equally important is embracing friction—not as a goal of generating conflict, but as an inherent part of the journey toward a highly effective, diverse team. Teams should arm themselves with the tools to manage friction before problems arise, embedding them permanently in their working culture. Pair programming shouldn't be avoided because it feels hard; with deliberate practice, it becomes a powerful means of building a far more resilient team.