How to Pair Program

This is derived from “All I Really Need to Know about Pair Programming I Learned in Kindergarten.”, by Laurie A. Williams Robert R. Kessler.  You are welcomed to read the full paper.  It starts with lots of data supporting the use of pair programming, some of it with computer jargon you do not need to worry about as beginning programmers.

An only slightly condensed version of the rules in the paper is next, followed by my summary.

Guidelines from “All I Really Need to Know about Pair Programming I Learned in Kindergarten.”:

The paper name and suggestion headings are derived from a poem by Robert Fulghum:

Share everything.

In pair programming, two programmers are assigned to jointly produce one artifact (design, algorithm, code, etc.). The two programmers are like a coherent, intelligent organism working with one mind, responsible for every aspect of this artifact. One person is typing or writing, the other is continually reviewing the work. But, both are equal participants in the process. It is not acceptable to say or think things such as, “You made an error in your design.” or “That defect was from your part.” Instead, “We screwed up the design.” or, better yet, “We just got through the test with no defects!” Both partners own everything.

Play fair.

With pair programming, one person “drives” (has control of the keyboard or is recording design ideas) while the other is continuously reviewing the work. Even when one programmer is significantly more experienced than the other, it is important to take turns “driving,” lest the observer become disjoint, feel out of the loop or unimportant.  The person not driving is not a passive observer, instead is always active and engaged. “Just watching someone program is about as interesting as watching grass die in a desert (Beck to be published).” In the pair programming survey, approximately 90% stated that the main role of the person not typing was to perform continuous analysis, design and code reviews. “When one partner is busy typing, the other is thinking at a more strategic level – where is this line of development going? Will it run into a dead end? Is there a better overall strategy? (Beck to be published).”

Don’t hit your partner.

But, make sure your partner stays focused and on-task. Doubtlessly, a benefit of working in pairs is that each is far less likely to “waste time” reading e-mail, surfing the web, or zoning out the window – because their partner is awaiting continuous contribution and input.

Put things back where they belong.

The mind is a tricky thing. If you think about something enough, the brain will consider it a truth. If you tell yourself something negative, such as “I’m a terrible programmer,” soon your brain will believe you.  However, anyone can control this negative self-talk by putting these thoughts where they belong, in the trash can, every time they start to creep into their brain. The surveyed pair programmers indicated that it was very difficult to work with someone who had a great insecurity or anxiety about their programming skills. Programmers with such insecurity should view pair programming as a means to improve their skill by constantly watching and obtaining feedback from another.

A survey respondent reflected, “The best thing about pair programming for me is the continuous discussion gave me training in formulating the thoughts I have about design and programming, thereby helping me reflect over them, which has made me a better designer/programmer.”

Indeed, two researchers surveyed 750 working programmers on coordination techniques in software development (Kraut 1995). The communication technique with both the highest use and the highest value was “discussion with peers.” “The standard response when one confronts a problem that cannot be solved alone is to go to a colleague close by (Kraut 1995).” When pair programming, the “colleague close by” is continuously available. Together the pair can solve problems they couldn’t solve alone and can help improve each other’s skills.

Also, negative thoughts such as “I’m an awesome programmer, and I’m paired up with a total loser” should also find their place in the trash can, lest the collaborative relationship be destroyed. None of us, no matter how skilled, is infallible and above the input of another. John von Neumann, the great mathematician and creator of the von Neumann computer architecture, recognized his own inadequacies and continuously asked others to review his work. “And indeed, there can be no doubt of von Neumann's genius. His very ability to realize his human limitation put him head and shoulders above the average programmer today . . . Average people can be trained to accept their humanity -- their inability to function like a machine -- and to value it and work with others so as to keep it under the kind of control needed if programming is to be successful (Weinberg 1998).”

Clean up your mess.

Pair programmers cite that it is amazing how many obvious but unnoticed defects become noticed by another person watching over your shoulder. Additionally, these defects can be removed without the natural animosity that might develop in a formal inspection meeting. Established software engineering techniques often stress the importance of defect prevention and efficient defect removal. This “watch over the shoulder” technique, perhaps, epitomizes defect prevention and defect removal efficiency.  “Given enough eyeballs, all bugs are shallow (Weinberg 1999).”

Don’t take things too seriously.

“Ego-less programming,” an idea surfaced by Gerald Weinberg in The Psychology of Computer Programming(recently re-reported in Weinberg 1998) a quarter of a century ago, is essential for effective pair programming. According to the pair programming survey, excess ego can manifest itself in two ways, both damaging the collaborative relationship. First, having a “my way or the highway” attitude can prevent the programmer from considering others ideas. Secondly, excess ego can cause a programmer to be defensive when receiving criticism or to view this criticism as mistrust.  In The Psychology of Computer Programming (Weinberg 1998), a true scenario about a programmer seeking review of the code he produced is discussed. On this particular “bad programming” day, this individual laughed at himself because his reviewer found seventeen bugs in thirteen statements.  However, after fixing these defects, this code performed flawlessly during test and in production. How different this outcome might have been had this programmer been too proud to accept the input of others or had viewed this input as an indication of his inadequacies. Having another to continuously and objectively review design and coding is a very beneficial aspect of pair programming. “The human eye has an almost infinite capacity for not seeing what it does not want to see . . . Programmers, if left to their own devices, will ignore the most glaring errors in their output -- errors that anyone else can see in an instant (Weinberg 1998)."

Conversely, a person who always agrees with their partner lest create tension also minimizes the benefits of collaborative work. For favorable idea exchange, there should be some healthy disagreement/debate.  Notably, there is a fine balance between displaying too much and too little ego. Effective pair programmers hone this balance during an initial adjustment period. Ward Cunningham, one of the XP founders and experienced pair-programmer, reports that this initial adjustment period can take hours or days, depending on the individuals, nature of work and their past experience with pair-programming.

Say you’re sorry when you hurt somebody while moving furniture.

In the pair programming survey, 96% of the programmers agreed that appropriate workspace layout was critical to their success. The programmers must be able to sit side-by-side and program, simultaneously viewing the computer screen and sharing the keyboard and mouse.  Extreme programmers have a “slide the keyboard/don't move the chairs” rule.  Effective communication, both within a collaborative pair and with other collaborative pairs, is paramount.

Wash your hands of skepticism before you start.

Many programmers venture into their first pair programming assignment skeptical of the value of

collaboration in programming, not expecting to benefit from or to enjoy the experience. Two skeptical programmers joined together in a team, could certainly carry out this self-fulfilling prophecy. In the pair programming survey, 91% agreed that “partner buy-in” was critical to pair programming success.  Pair programming relationships can be informally started by one programmer asking another to have a seat and give them some help – and carry on from there.

Tom DeMarco shares his inspiring view on this type of union. “A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts. The production of such a team is greater than that of the same people working in unjelled form. Just as important, the enjoyment that people derive from their work is greater than what you'd expect given the nature of the work itself. In some cases, jelled teams working on assignments that others would declare downright dull have a simply marvelous time. … Once a team begins to jell, the probability of success goes up dramatically. The team can become almost unstoppable, a jaggernaut for success (DeMarco 1977).”

Advice to an up-and-coming pair programmer: Wash your hands of any skepticism, develop an expectation of success, and greet your collaborative partner by saying, “Jell me!” This is an unprecedented opportunity for the two to excel as one.


Inevitably, the pair programmers will work on something independently. Of the programmers that were surveyed, over half said that when they rejoined with their partner, they reviewed this independent work and then incorporated it into the project. Alternately, Extreme Programmers flush (discard) and rewrite independent work. In their XP experience, the majority of the defects they found could be traced back to a time when a programmer worked independently. In fact, in their Chrysler Comprehensive Compensation project during the last five months before first production, the only defects that made it through unit and functional testing were written by someone programming alone. In re-writing, the author must undergo the customary continuous review of the work, which identifies additional defects.

The decision to flush or to review work done independently can be made by a pair of programmers, or the choice may be encouraged, as it is with Extreme Programming. However, it is important to note that none of the programmers surveyed incorporated work done independently without reviewing it.

Warm cookies and cold milk are good for you.

Because pair programmers do keep each other continuously focused and on-task, it can be a very intense and mentally exhausting. Periodically, taking a break is important for maintaining the stamina for another round of productive pair programming. During the break, it is best to disconnect from the task at hand and approach it with a freshness when restarting. Suggested activities: checking email, making a phone call, surfing the web, eating warm cookies and drinking cold milk.

Live a balanced life – learn some and think some and draw and paint and sing and dance and play and work every day some.

Communicating with others on a regular basis is key for leading a balanced life. “If asked, most programmers would probably say they preferred to work alone in a place where they wouldn't be disturbed by other people (Weinberg 1998).” But, informal discussions with other programmers – the one you are paired with or any other – allow for effective idea exchange and efficient transfer of information.

For example, The Psychology of Computer Programming (Weinberg 1998) discusses a large university computing center. A common space with a collection of vending machines was in the back of the room.  Some serious-minded students complained about the noise in this common space, and the vending machines were moved out. After the vending machines were removed and signs urging quiet had been posted, a different complaint abounded – not enough computer consultants! Suddenly, the lines for the computer consultant wound around the room. The cause of the change: the informal chat around the vending machines had consisted of idea exchange and information transfer between the mass of programmers. Now, all this discussion had to be done with the relatively few consultants. (Sadly, the vending machines were never moved back in.)

Take a break from working together every afternoon.

It’s certainly not necessary to work separately every afternoon. But, according to 50% of the surveyed programmers, it is acceptable to work alone 10-50% of the time. Many prefer to do experimental prototyping, tough, deep-concentration problems, and logical thinking alone. Most agree that simple, well-defined, rote coding is more efficiently done by a solitary programmer and then reviewed with a partner.

When you go out into the world, watch out for traffic, hold hands and stick together.

With pair programming, the two programmers become one. There should be no competition between the two; both must work for a singular purpose, as if the artifact was produced by a singular good mind.  Blame for problems or defects should never be placed on either partner. The pair needs to trust each other’s judgment and each other’s loyalty to the team.

Be aware of the power of two brains.

Human beings can only remember and learn a bounded amount. Therefore, they must consult with others to increase this bounded amount. When two are working together, each has their own set of knowledge and skills. A large subset of this knowledge and these skills will be common between the two, allowing them to interact effectively. However, the unique skills of each individual will allow them to engage in interactions which pool their resources to accomplish their tasks. “Collaborative people are those who identify a possibility and recognize that their own view, perspective, or talent is not enough to make it a reality. Collaborative people see others not as creatures who force them to compromise, but a colleagues who can help them amplify their talents and skills (Hargrove 1998).”

Guideline Summary:

Share everything.  All contributions, whether great results and errors, are “ours”, not “yours” or “mine”.

Play fair.  One person “drives” (has control of the keyboard or is recording design ideas) while the other is continuously reviewing the work and planning ahead. Stay fairly close to 50-50 on driving.  Let the less experienced partner start and maybe drive a little more.

Don’t hit your partner.  But make sure your partner stays focused and on-task.

Put things back where they belong.  Put negative judgments in the trash:  Be positive about you and your partner.  For both, this is an opportunity to improve.

Clean up your mess.  >Watch over the shoulder and you are really likely to find a large number of your errors!

Don’t take things too seriously.  If your partner picks out a bunch of errors as you type, be glad.  But do not always agree.  Have healthy disagreement/debate.  Finding the fine balance takes adjustment.

Say you’re sorry when you hurt somebody while moving furniture.  Sit side-by-side and program, simultaneously viewing the computer screen and sharing the keyboard and mouse.  Slide the keyboard -- don't move the chairs.

Wash your hands of skepticism before you start.  Being skeptical can be a self-fulfilling prophesy.  Buying in and “jelling” can lead to a whole that is greater than the sum of the parts.

Flush.  If you work on some parts independently either discard them (flush) and start over together or have the partner very carefully review the work with you.

Warm cookies and cold milk are good for you.  Periodically, taking a break is important for maintaining the stamina for another round of productive pair programming.

Be aware of the power of two brains.  Experiences show that, together, a pair will come up with more than twice as many possible solutions than the two would have working alone. They will then proceed to more quickly narrow in on the “best” solution and will implement it more quickly and with better quality.