Pair Programming Guidelines

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 would be a good interval for us, 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: Spend your time in the scheduled labs working with your partner, one of you as driver and the other as navigator, switching regularly. You may need to arrange other times to meet, beyond the scheduled lab sections. 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 outside 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 stronger partner builds teamwork skills that 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 from week to week. 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.

What happens if you don't "do it right," according to these guidelines? You won't learn as much, your scores on the exams will be lower, and so will your grades in this class and others. You may get a low partner evaluation score; too many low evaluation scores can affect your class participation score. These consequences don't strike you instantly like a bolt of lightning, but they're real nonetheless.

That's so important that it bears repeating. If you're the stronger partner, it is your job to explain what you're doing and help your partner understand. It's not okay to do all the work yourself in advance and just drop it on your partner as you submit it. If you're the less strong partner, it's your job to come to the lab prepared (by attending class, reading the assignment, and doing the preparation part) and to ask questions so that you do understand. If you just let your stronger partner take the lead and you follow along passively, or worse yet disengage completely, you will not learn the necessary skills and concepts. You might get a decent score on that assignment, benefiting from your partner's work, but next week you may be the stronger partner, and you won't be ready. Even if you have strong partners all quarter long, you won't do well on the exams if you didn't participate in the labs, and most importantly, you won't know what you need to know in the following courses. You can't just skip a few topics in ICS 31; everything comes up somewhere in a later class. Imagine the feeling (which a few people experience every quarter) of being in a more advanced class, having a solo assignment to do, and not having the skills and knowledge to do it. At that point you can't just "look up" a few facts; you'll be missing critical skills and you'll be pretty much stuck. Don't risk that; stay engaged with your lab work in ICS 31.

What happens if you can't find a partner? There are plenty of potential partners in every lab section, so it is your responsibility to find a (new) partner to work with every week. The Partner App lists who's still unpartnered. If there's an odd number of students and you happen to be the last unpaired person, see your TA; you may be given permission to work solo, but that's a one-time deal and you'll need to take special care to get a partner for the rest of the assignments. Repeatedly working solo may lead to lower participation scores. The lab assignments are doable in a week by one person; we use pair programming not to assign harder work but for the benefits in communication, collaboration, and learning that pair programming provides. It's not a tragedy if you miss that for one week, but it is part of the course. What you should not do if you don't have a partner is just attach yourself to some other pair. In rare cases your TA may authorize this, but if you have an unauthorized group, it will look as if you copied each other's work and that could lead to serious trouble. If you're working solo and need help, you have the lab tutors, the TA, the instructor, and Piazza for any questions.

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.) On assignments that specify pair programming, each pair will submit one solution, marked with both partners' names. (For electronic submissions, just one member of the pair should submit the solution, which must contain both partners' names at the top of the file; also, make sure your partnership is regisered in the Partner App in the first place.) Each pair will receive a single score on the assignment.

Also, for each paired assignment, each student individually will submit a brief partner evaluation form, administered electronically in the Partner App, which will ask these questions: 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?

Filling out the evaluation is required of each student for each assignment; forgetting the evaluation will lower your participation score. We will tally these evaluation scores and use them in computing the participation part of the grade (taking care that nobody's score is hurt by a single bad partnership).

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).

Additional information: Pair programming is one aspect of the programming methodology called Agile Development. A search for "pair programming" or "agile methodologies" on the Web will yield many references.

David G. Kay, kay@uci.edu
Sunday, September 24, 2017 5:21 PM