National Centre for Computing Education

Engaging learners through pair programming

National Centre for Computing Education -

As a practice, pair programming originated in the software development world as part of an Agile development approach called extreme programming (XP). However many educators have found it a valuable and engaging tool to use in the computing classroom.

Pair programming is quite simple: pairs of programming students work collaboratively on a shared project and take turns acting in two roles: the Driver controls the computing device and writes the code, while the Navigator provides direction, spots errors, and thinks ahead to the next part of the project. Throughout a programming session, the pair regularly swaps roles, so that each individual performs each role several times while working on the same programming task.

Research has conclusively shown the efficacy of pair programming, so it is a recommended practice for computing teachers in schools. Although much of the research has focused on older students (KS4- to university-age) and introductory courses, many primary school teachers use pair programming with their learners, and beyond introductory tasks.

The benefits in the classroom

Although the principle is simple, pair programming, when implemented well, has positive effects on the performance and attitude of learners, as well as added benefits for the teacher:

  • One of the benefits demonstrated by most studies is learners' increased engagement in and enjoyment of the programming task.
  • There is also evidence that, compared with solo programming, pair programming boosts learners' self-confidence and interest in the subject material. This may explain the increased student retention through introductory programming courses and into follow-up courses.
  • Studies have found that pair programming can lead to learning gains, most readily evidenced through improved code quality and programs with fewer common mistake.
  • Pair programming has been shown to reduce cognitive load by effectively sharing any additional load between the pair. This "distributed cognition" means that each role takes on different types of cognitive tasks.
  • Opportunities to collaborate are valuable in and of themselves: students get to practice a transferable skill that is important for their future careers and especially sought after in the software development sector.
  • There are also added benefits for the teacher: firstly, each learner has a partner that they can direct low-level and practical questions to, freeing up the teacher to focus on the paired work going on. Secondly, a workload-reducing benefit is that with students in pairs, there are half as many projects to mark!

Considerations for integrating pair programming

To ensure good results when including pair programming in a unit of work, some aspects need to be considered with care:

  • Time and focus are needed to establish good pair work among learners: pairs need guidance, support, and praise in order to work together effectively and form good habits. Pair work should be modelled, practised (including away from the computer), and rewarded.
  • The pairs themselves require some thought: will students choose their programming partner or will the teacher direct who works together? While the answer does depend on the setting and context, studies suggest that allocating pairs is sensible and that students of similar experience often work well together.
  • A concern that is sometimes raised regarding pair programming is that some learners may be able to "coast" with the support of another. While this is possible, it can be mitigated against through careful selection of pairs, strict regular swapping of roles, and not basing any assessment solely on the result of a pair programming project.
  • Although pair programming is popular and enjoyable for most students, there may be some (often more skilled) learners who would rather work individually. While teachers can encourage these learners to engage with in collaborative approach, they may need to accept the students' wishes and provide them with the option to work alone.

In summary, while some aspects of pair programming require careful consideration, this practice has many evident benefits, making it an ideal low-stakes, high pay-off approach that educators should be applying in their settings.

Next steps:

Here are some resources and further reading you should consider using when bringing pair programming to your learners:

In practice...

Alexis Cobo

Pair programming is an essential function of my classroom practice. Students in all grade levels I teach are tasked with working collaboratively to solve simple and complex problems, and therefore learning to communicate effectively is a necessity for them. Through forming partnerships in which one partner feels more confident in the programming and the other one, for example, might be more artistic, I provide learners with opportunities for a synergy of creative expression.

Additionally, I use pair programming as a method to teach debugging and perseverance. Often students rely on the knowledge of the teacher, and particularly in elementary school, computer science classes want instant gratification. However, when they work together to problem-solve, build, and rely on each other’s schema, I find they are more likely to persist and debug their programs.

Rick Webber

I was interested in the potential benefits of pair programming in a primary computing setting, having read about its success in universities and industry. Therefore, I carried out an investigation across two Year 6 classes of mixed ability and gender. One class worked individually on their own Scratch projects, the other class were paired as Pilot (in charge of keyboard and mouse) and Navigator (in charge of error checking/overall direction); pairs swapped roles each lesson. To assess, I recorded the types and lengths of interactions I had with pupils.

The results were startling. In the Individual class, there were more children who got no teacher time at all in a lesson. Pupil-Teacher interactions were much more likely to begin with a pupil question in the Paired class (64% of interactions, compared to 20%). However, the number of questions as a proportion of interactions was higher in the Individual class. This suggests paired pupils were thinking and solving their own problems rather than immediately asking for support, and often needed support later in the lesson than the Individual class, who immediately began asking questions.

The length of interactions was also interesting. In the Paired class, the longest interaction chains through a lesson had four parts (a comment or question from a pupil, or an intervention or response from the teacher), while the Individual class had chains reaching seven parts; pupils required more ongoing support from the teacher when working on their own.

Finally, the quality of questions improved markedly through pair programming. I ranked quality from 1 to 4 (1 = vague, 4 = specific and advanced). In the Paired class, all questions were of the highest quality, while the Individual class had equal numbers of questions that scored 1, 2, and 4, with a greater number in category 3 (problems with simple code).

Pair programming seems to promote pupils’ independence and learning, and it increases their productivity. Teacher’s time is used productively, and the atmosphere in the classroom is calm and purposeful. I would highly recommend it as standard practise in the classroom, provided the simple rules for pair programming are followed to ensure each participant is fully engaged with the project.

Nicole Maddock

I regularly use pair programming with my Year 3 and 4 classes, often as the first hands-on activity following an unplugged lesson where a new programming concept has been introduced; I’ve found that this promotes self-scaffolding during those first steps into new territory.

Since many of the children request help more often (and often unnecessarily) when they work individually, I find myself with more time to observe and assess during a paired programming lesson.

I encourage the children to talk, talk, talk — this way, even if one of the pair is more adept at coding, they will be verbalising their thought processes to their partner, who will hopefully learn from them. Moreover, listening to the children as they talk to one another can give you helpful insight into their understanding and, importantly, show you any misconceptions that may have crept in.

The children themselves seem to really enjoy working together and bouncing ideas off one another, and even at this relatively young age they’re very respectful of the Driver and Navigator roles, keeping their hands off the keyboard during their Navigator stint! So far, I haven’t applied too much logic to whom each child is paired with, as I’ve found that mixing or matching programming experience works fine — I just tend to keep a close eye on my Navigators to ensure no-one’s sitting back and letting the Driver do all the work. Children swap roles frequently to keep on their toes: either after each puzzle, if they’re working on something like a code.org lesson, or after a set period (e.g. 5 minutes) if it’s a project. For me, pair programming is a no-brainer — not something for every lesson, but a great collaborative tool to be used as part of a range of learning experiences.

About the author
James Robinson is the Senior Learning Manager at Raspberry Pi Foundation.