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. Pair programming can be performed remotely, with the driver sharing their screen.
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, and it is really a specialized form of partner work that you may already be doing in your classroom. 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. One of the key features of pair programming is an openness to new ideas and to constructive criticism, so it can be very helpful to start small on lower-risk projects, rather than waiting for larger projects with more room for personal creative expression.
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 primary benefit is to get new perspectives on their work, and they 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/evaluate 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. Again, 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.
Professional Developers and Intro Students Discuss Pair Programming
While this article presents just one point of view, it’s linked here because of the discussion in the comments at the end. From that discussion, here is poignant metaphor about the benefits of pair programming for novices, in terms of athletic training:
I am taking an intro to java programming class to fulfill a requirement for school. The professor has us program in groups of three every class. One person drives and the other two pretty much dictate the code. Although it feels like running with weighted shoes at times I have been able to quickly pickup some quick tips, shortcut keys and other little tricks that I would have never known about. Also when I am back to programming all by myself it feels like I have removed the weights from my shoes. I can run that much faster after practicing with the weights. -bryana2