Pair Programming FAQ for Teachers

What is pair programming?

Pair programming is a structured approach to development where two developers share a workstation. One is the driver, who actually implements the code, and the other is the navigator, who reads all of the instructions out loud, searches for answers when the team has questions, and checks that the result meets the requirements.

Why should we practice pair programming?

Pair Programming is a common procedure in both academia and the workplace, so practicing now is good real-world prep. Programming is a creative process, and learning about how others think and solve problems creatively can give you your own new ideas for your own thinking and creativity, while also correcting bad habits or assumptions. Developers can help each other stay focused on the task and be more likely to meet deadlines. Pair programming also helps identify and solve problems faster by having review and reflection built into the programming process — you can even skip some of your code reviews because a basic peer-review is already done! In the workplace, there are additional benefits, such as reducing the “key man” risk.

When should we practice pair programming?

Anytime! This approach is not limited to code activities. Activities in this curriculum may be marked with “This is an excellent Pair Programming exercise.” but you are not limited to these activities. Start early and make pair programming a common method in your classroom, so that students have many chances to practice it, before you have students work on any larger group projects.

How do you choose partners?

Some believe that you should change partners frequently to get the most exposure to other ideas (which aligns with many goals of educational pair programming). Others believe that partners should be kept long-term to learn more in-depth from each other’s strengths and deliver better results faster (which is especially useful in workplace pair programming). A good balance could be to start by randomly assigning partners that change with every lesson, and later switch partners every unit. Allowing students to choose might be ok, but the whole point is to get new perspectives on their work, and they may need to experience many different partners before any repeats.

How should we handle clear imbalance of skill?

There is some debate about the matching of skill levels — a new developer can learn quickly when paired with an experienced developer, but the risk is having the stronger developer railroading the weaker developer. However, when both are engaged in the task, the stronger partner benefits from verbalizing their work, and the weaker partner benefits from more one-on-one attention than they can get from a classroom teacher. It is the responsibility of the stronger partner to explain what they are doing and thinking to the weaker partner, and it is the weaker partner’s responsibility to ask questions as needed. When in doubt, have the weaker partner drive and the stronger partner navigate.

How often should partners switch roles?

This will depend on the project. If it takes more than one class session, switch at least each session. For shorter activities meant to be finished in one sitting, partners might only switch once or not at all. That’s ok! You can still assign the driver/navigator roles even on small tasks, and this might even be the best time to model those roles by choosing a student to pair with yourself, deliberately showing how to handle potential pitfalls like railroading and role degradation.

How do I grade each participant in pair programming activities?

Equally. Pair programming is an equal partnership, with both developers fully engaged, even when there is a skill imbalance (as noted above). You, as the instructor, need to be very clear with your expectations and role-switching times, and you need to frequently remind students to fulfill the duties of their roles as driver and navigator. You may wish to model these behaviors on shorter activities by choosing a student to pair with yourself, deliberately showing how to handle potential pitfalls like railroading and role degradation.

What if students are refusing to cooperate?

If you have multiple students who consistently fail to fulfill their roles in pair programming, you may need to provide more explicit instruction in the process itself, model pair programming behaviors with role play, and/or incentivize good efforts. One of the key features of pair programming is an openness to new ideas and to constructive criticism. These are crucial virtues in any workplace, but especially as web developers, we are constantly under criticism, both subtle and overt, from website users. These virtues are especially difficult but essential to cultivate in required classes, so you might get some valuable insight from their teachers of math/language.