Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Effective Pair Programming by Mind Map: Effective Pair
5.0 stars - 3 reviews range from 0 to 5

Effective Pair Programming


Nicholas Tuck

Pair Programming for 4 years

AFWWEBS / MetServices Developer 4 Years, Team pairing full time for 2 years

Brandon McAllister

Pair Programming for 3 years

AFWWEBS / MetServices Developer 2 Years

AFWWEBS / Metservices Team pairing full time for 2 years

Sit by Andy Sedlacek, in front of Trent's office


Pair Programming Illuminated

Amazon Book

My Notes

SEMS owns 2 copies

C2 Pair Programming Wiki

Super awkward wiki

Lots of great pages, definitions, and ideas

What is Pair Programming?


Style of programming

two programmers, working side by side

1 computer, 1/2 keyboards, 1/2 mice

Continually collaborate, on, design, coding, algorithm, debugging, testing, unit test, integration test, etc, Work together, High Communication, High Focus, Double checking work, Planning the next step, Solving the Problem Together


Driver, The one typing at the computer, Implementing the current test / solution, Focused heavily on the syntax of the for loop etc, Writing down a design

Navigator, Observes the work of driver, looking for defects, syntax, typos, calling wrong methods etc, pro tip, Give the driver a few nanoseconds to find and correct a mistake, strategic, implementation won't accomplish goal, headed down the wrong path, "TomTom Recalculating", Planning the next step, Ensuring the current implementation is going to work with the next design step, Designing the next test to make pass, Finding the best implementation for the next step, Useful libraries to solve the problem, Understanding how to use the apis, Considering the best way to refactor current solution

How it Works

Lots of Communication, Lots of Questions!, Why are you doing it that way?, What's the next step?, How do you think we should do this?, Should we test it this way?, What if we try this?, Lots of Pointing, Finger (Don't touch the screen), Using the Mouse, Nonverbal, Grunting, Laughing, Enjoyment, Snickering, Crossed Arms, Eye Rolling, Come to an understanding on how pairing will work with a new pair, Negotiate on what each person likes to do and how. What each does well etc, Takes < 5 min, Practice active listening, Acknowledge, restate and summarize ideas

Constantly Switching Roles, Ping Pong Programming, Write the test, switch roles, write both the test and implementation, switch roles, Small Tasks, Helps identifying switch points



WHAT Pair Programming is

Benefits of Pair Programming

Myths of Pair Programming

Learn some Techniques

Tips and Tricks

If your navigator is getting bored, pass them the keyboard

If you both are tired, get up and walk around

If your partner is getting tired or frustrated, grab the keyboard

Handling Conflict

Navigator record contentious issues, Review every half hour, Allows progress

Separate for a period of time, ~ 10 min, Do separate investigation, Get back together and discuss

Let the navigator drive for 5 minutes, If driver agrees with the solution, driver can finish it out. Otherwise rollback, Sometimes just trying can make both sides see the good and bad and lead to an agreement


Sit comfortably side by side, Rotate sitting positions, Or stand

Both can completely view monitors

2 mice, 2 keyboard, no more awkward mouse dance / accidental hand holding


Use test driven development

helps facilitate switching roles

Practice Humility

It's okay to not know something, admit it and start helping the team as best you can

Take Breaks

check email, return phone calls, etc


15 sec without talking is long, 30 sec is an eternity

Programmer's are stereotyped as quiet, but really we love to talk about what we are interested in... like programming, This is not forcing introverts to be an extrovert, this is professionals excelling at what they do and showing colleagues their work

Be a Team Player

your partner's work == your work

Use the word "we" a lot

If you don't understand something, ask, you are responsible for all of this work too

Benefits of Pair Programming

Software Quality

Pair Negotiaion, pair programmers arrive at the best solution together, each brings their own set of skills, abilities and outlook, both share the same goal for completing the task, must 'negotiate' how to approach the problem jointly, evaluate more alternatives than either would have considered alone, Pairs produce code with fewer defects, Definition of Done between an individual and a pair are not equal. The pair's is better., Conclude that the end result is far better than anything they could have developed on their own

Pair Reviews, 4 eyes are better than 2, Peer reviews are a heavy focus because they have been proven to find defects earlier, The earlier a defect is found the cheaper it is to fix, Pairing gives minute by minute peer review, the best way to find 'all' bugs as early as possible, work done individually is often reassessed early and the better solution is implemented, It's not too late to do what's right, traditional peer reviews often will allow what's NOT best because problems were identified too late, These are actual peer reviews vs many complaints of peer reviews not adding real value, Not Just Feng Shui

Saved Time

Gelling pairs produce higher quality code in about half the time as individuals

Pair Pressure, pair programmers put a positive form of pressure on each other, Programmers admit to working harder and smarter because they do not want to let their partner down, Improved adherence to procedures and team standards, TDD, Retrospective Items

Pair Courage, Strength in numbers!, tremendous courage builder giving us confidence to do things we might be afraid to do alone, Teaching Analogy, Teacher asks all students to do a task individually and ask their answers at the end, only a few respond, Teachers asks all students to work with a pair, nearly every pair will respond at the end, Courage to admit when we don't know something, individually we may muddle through problems on our own, embarrassed to ask others questions, Where is canada?, Study shows 42% of developers are inclined to work on problems alone, the more experience a dev has the more likely he or she is to ask for help

Pair Debugging, Most common use of pairing, Rubber Duck Debugging It is a common and effective practice to explain a problem to an inanimate object like a teddy bear or a rubber duck, The act of explaining the problems will often lead you to a solution, Constant communication will increase this technique, Also this bear will talk back

Interruptions, Person out (sick, meetings, training...), Doesn't halt an entire task/story, Pair can catch up when they are back, Drive Bys, People tend to interrupt less if you are working with someone else, If you are interrupted, pair can continue to work, pair can help you back into context afterward, When your context is broken it can take 30 min to get back into context

Knowledge Sharing

Knowledge is constantly being passed between partners, tool usages tips, programming language rules, design and programming idioms, how to approach problems, Pair programmers know more about the overall baseline

Training New Team Members, Costs are reduced in training as training time can reduce by a factor of two, New people can actually contribute to projects quickly, Teaching by doing, not showing, has been proven to be more effective

Strengthens Teams

Pair Trust, Pairing allows team mates to open up to each other's knowledge and experiences, get to know their team-mates much better, builds trust and improves teamwork, allows team to share more freely

Morale, Pair programmers are happier programmers, helps job retention, Constant Team Building

Nick's take on when to use Pair Programming

This is Nick's idea. Management is not telling you to use Pair Programming.... But I am


Ken Schwaber - Scrum Et Al

When you NEED something done, You setup a team, Give them the resources to do their job, Let them decide how best to do their job, You leave them alone and check status every few weeks

Don't do this when you HAVE to get stuff done, Do it ALL the time, This is called Scrum

Pair Programming

When you really NEED something done, You work with someone else, Together you debug/troubleshoot code, Together you decide the best solution, Together you implement and test

Don't do this when you HAVE to get stuff done, Do it ALL the time, This is called Pair Programming

Myths of Pair Programming

The team productivity will be cut in half

reality, Get two people programming in pairs and they'll work more than twice as fast as one could have, Majority of buggy production code comes from individually written code, A bug can range in effort dramatically so reducing bugs earlier saves an indeterminate amount of time very quickly, Proved by a 16 week study at University of Utah

The navigator finds only syntax mistakes. Compilers can do that better than humans can

reality, Navigator is doing more than syntax checks, Navigator is holding the roadmap and is caught up with staying between the lines on a winding road, Overall design is constantly being assessed and re-considered by navigator while driver implements the latest agreed on idea, Also help brainstorm - brainstorming concludes good designs much faster than individual considerations

Pair Programming is good for training, but once you know what you're doing it is a waste of time

reality, Two experts solving complex problems will come up with a great solution, always better than what they would have come up with individually, Two experienced programmers will fill many of each other's knowledge gaps, everyone has gaps

I'll never get to work alone. I couldn't stand that!

reality, ~50% spent pairing, ~30% spent working alone, ~20% spent working with more than 2

It will work well only with the right partner

reality, Works well with most (though not all), Usually those with excess ego and/or a 'my way or the highway' attitude is the exception, Managed approaches to the different dynamics of pairs are well described in the Pair Programming Illuminated book

I'll never get credit for doing anything. I'll have to share all the recognition with my partner

reality, Pairing is about better quality code and better solutions for the projects and benefits the team overall, so desired personal success transitions to desired team success, individual success means nothing without team success

Only time I ever get any real work done is when I'm alone

reality, Interruptions while working alone can make you lose context (all it takes is 15 seconds), A partner can help you get back into flow, A pair is interrupted less than someone working individually, "real work"does != better / less buggy / reliable / working code, Mental blocks happen, pairing helps prevent and work through them, Surveys show 90% of those who pair enjoy programming more and feel more confident when pairing


Parking Lot