Two heads are better than one, according to an old saying. This even applies to writing programs: A pair of programmers (working as described here) nearly always beats the stereotypical solitary loner. The pair produces more high-quality code in less time, by far more than two-to-one.

In pair programming, two programmers share one computer. One is the "driver," who controls the keyboard and mouse. The other is the "navigator," who observes, asks questions, suggests solutions, and thinks about slightly longer-term strategies. The two programmers switch roles frequently — every 15 minutes could be a good interval, though that's flexible. Even the activities of the driver and navigator are flexible (except for who does the typing); the goal is to work together collaboratively, each partner assisting the other as needed, to produce the best joint result possible. It is not pair programming if one person does all the work or if the partners just split up the work and each does half independently.

That's the basic idea: You do need to arrange times to meet. We expect everyone to be as flexible and professional as possible in arranging those times as necessary; if your schedule is highly constrained, explore possible meeting times with your prospective partners before you commit to the partnership.

You may enjoy reading this paper about pair programming: All I Really Need to Know About Pair Programming I Learned in Kindergarten, by Laurie A. Williams and Robert R. Kessler (Communications of the ACM, May 2000). [Alternate link]

What about individual differences? People new to pair programming often ask what happens if the members of the pair have different abilities. Actually, that will be true of any pair of people in the world, probably even including identical twins. The differences may be great or small, one member may have more strengths than the other, but this is exactly like most real-world working situations. Part of accomplishing a task is to get the most out of each member and make each member stronger and more productive on subsequent tasks.

A clearly stronger partner may feel frustrated or slowed down by the other partner, but the stronger partner still benefits from the teamwork in many ways: The other partner's requests for clarification often point out flaws in the approach or solution, the teamwork skills gained have great value in the job market, and the exercise of providing a clear explanation solidifies and deepens the explainer's own understanding.

The less strong partner may feel that questions hold the other partner back or that there is no benefit to participating actively, but pair programming studies show that paired work is consistently better than work the stronger partner does individually. It is part of each partner's job to understand the whole task; that means asking questions when necessary and answering them when possible.

You will choose a different partner for every assignment, so your partners' skill levels are certain to vary during the quarter. Still, when you have a choice, you should try to pick a partner whose skill level is close to your own. This won't always be possible, and it's sometimes hard to compare skill levels at all, but we find that pairs are most productive when the partners are at about the same level — there's a more balanced give-and-take.

How does this affect my grade? Participation in pair programming won't be the cause of any low grades. (Failure to participate fully and cooperatively, on the other hand, could be a problem.) Each pair will submit one solution. Just the "head member" of the pair should submit the solution via Checkmate, which must contain both partners' names at the top of the files. Make sure that your pairing is registered with the class Grader by the registration due date for that assignment. Each pair will receive a single score on the assignment.

Typically, all CompSci 165 students are capable and professional. We expect that the answers to all of the following questions would be "yes":

• Did your partner come to the scheduled meetings on time and ready to work?
• Did your partner read the assignment and preparatory materials before coming to the scheduled meetings, showing up either with specific questions or ready to contribute?
• Did your partner cooperatively follow the pair programming model (rotating roles of driver and navigator, questioning and making observations as the navigator)?
• Did your partner contribute fully, fairly, and actively, to the best of his or her ability, to the completion of the lab assignment?
• Was your partner's participation professional and cooperative overall?

It may be instructive to read a selection of students' partner evaluation comments from a previous course; they give a picture of what good partnerships are like (and a few disasters, too).