Drawing of group of students on an online call. Speech bubbles show that students are saying things.

Structuring group work using the Pair Programming protocol

Drawing of group of students on an online call. Speech bubbles show that students are saying things.
An exchange of Ideas between online students: “So the way I understand it, is …”, “I see another way to solve this!”, “That’s cool! I never thought about it this way”. Image credit: Pawel Orzechowski

Over two blog posts, Charlotte Desvages, Brittany Blankinship, Umberto Noè and Pawel Orzechowski share their experiences of a structured group work format, called Pair Programming, which they believe fosters student engagement, well-being, and transferable skills. In this first post, they explain what ‘pair programming is’. They then show how assigning students structured roles in group work, and then switching these roles, can promote active learning. The second post focuses on how pair programming can create a sense of community and peer learning. This post is part of the Group Work series.


We are a team of University of Edinburgh educators who have been using pair programming as a group work protocol in our teaching for several years. We have done so across many subject areas (psychology, mathematics, statistics, data science, medicine, epidemiology, business, EFI); levels of study (UG and PGT); and delivery modalities (in person, online, hybrid). We have consistently seen the positive impact of this practice on our students and teaching teams. 

What is “pair programming”? (and why should you care?) 

In the software industry, people often work in pairs, which evolved over the years into a standard collaborative practice called “pair programming” [1]. Partners take turns playing two different roles: driver and navigator. The driver has exclusive control of the shared computer, and the navigator guides the driver by acting as their sounding board. Being in each role allows them to gain and contribute unique perspectives on the task at hand. Switching roles frequently allows both partners to get the most out of the experience. 

The purpose of the exercise is not only to produce better output (e.g., code) but also to:

  • share knowledge and practice (cross-pollinate ideas);
  • help each other to grow;
  • create friendships and community;
  • and foster a culture of being able to doubt and ask for help (you’re never struggling alone). 

In the professional world, pair programming benefits the product, the individuals, and the team. When implemented in the classroom, students can reap those same benefits, with evidence of positive impact on learning experience and outcomes [2]. 

Why is pair programming useful for group work?  

In our view, the two key benefits come from the structured roles, which promote active learning, and from the process, which can help foster peer learning and community. These are useful for not only  writing code [3], but for any production task where a group of people create an artifact (e.g., writing, weaving, drawing, problem-solving). 

Structured roles for active learning 

While group work can be beneficial to learning, navigating group dynamics requires effort, which can significantly worsen the cognitive load of learning something new. When roles are vague (or non-existent), communicating and negotiating responsibilities between group members can become an extra task in and of itself. For instance, when no-one in a team feels individually responsible, everyone might wait for the others to take initiative, and nothing gets done; or, one student might assume a leadership role, leaving others who are less confident to follow passively or to disengage entirely. 

As a structured way to work together (a “collaboration script” [4]), pair programming gives groups a roadmap with prescribed roles for each student – such as a ‘driver’ –  and specific activities associated with each role. With the burden of inefficient group work lifted, students have more room to focus on learning. Furthermore, when clear roles are assigned, everyone must take ownership of their part and actively contribute. Although the roles are asymmetrical at any point in time, taking turns ensures that all students benefit equitably from playing both roles over the course of a session or a semester. 

“The practice of being a driver and a navigator is very useful. These two different roles provide me with distinct perspectives on the code. When I’m the driver, I focus on how to complete the code, and when I’m the navigator, I gain insights into how my fellow students understand the code, which helps me learn new things.” – PGT, Mathematics 

 As a result, we see students engage more. They take responsibility for their group, attend more sessions, and come better prepared to not let their teammates down. 

“Students were not engaging in the tutorial sessions at the beginning, which made them less useful. But it improved after having pair programming” – PGT, Medical School 

Tutor is approaching a pair of students. Speech bubble shows tutor talking. Students are in the process of passing a keyboard to each other.
A tutor is helping a group of students: “Hello! Which of you is driving now?”, “Is it time to switch drivers?”, “Do you need help getting unblocked or are you just cracking on?”. Image credit: Pawel Orzechowski

Having designated and defined roles means one student cannot take over the task or speak over others, as can sometimes happen in unstructured group work. This is particularly important as many of our students have experienced marginalisation, and hence feel less safe putting themselves forward. 

“This is sort of just a problem with sexism, but I have really disliked group working in the past because I’ve been put with people (boys) who completely disrespect my work. This is why I’m opposed to the forced group working. It’s better to work alone than be treated like that.” – UG, Mathematics 

Although the structured roles are not a magic bullet to prevent these issues, they can provide tools for both students and tutors to maintain a safer learning environment. One useful strategy is for tutors to casually check in with the groups, leading with the question: “who is the driver?”. This does two things: first, it is a temperature check of whether the collaboration is working well; and second, it reinforces the expectation that students should always stick to the script, even after the tutor leaves. 

If a student is undermined by their partner, they can fall back on the script to reassert themselves as a valued contributor, or to communicate the issue with a tutor. This can reduce the emotional cost required to flag or confront bad behaviour directly, by giving both students and tutors a tool to defuse the situation. 

Tips for assigning pairs 

 There are many ways to assign students into pairs, but here is some of our advice: 

  •  Many students are more likely to attend class if they can work with the same friend each time, but this might mean that they miss out on meeting new people. Swapping partners each week will create a network of student-to-student connections which contributes to cohort building. 
  • Stretching the definition of “pair” programming to groups of 3 or more (with a single driver) can also work well. Allowing for more navigators can create flexibility in terms of logistics (odd number of students), technological problems (connection issues in online teaching), student preferences, or accessibility. 

In the next blog post on pair programming, we will look at how this pair programmig technique can foster peer learning and community. 

References 

[1] Williams, L. (2010). Pair Programming. In P. A. Laplante, editor, Encyclopedia of Software Engineering, volume II. 

[2] Hanks, B., Fitzgerald, S., McCauley, R., Murphy, L. & Zander, C. (2011). Pair programming in education: a literature review. Computer Science Education, 21(2), 135-173. DOI: 10.1080/08993408.2011.579808 

[3] Saltz, J., & Heckman, R. (2020). Using structured pair activities in a distributed online breakout room. Online Learning, 24(1), 227-244. DOI: 10.24059/olj.v24i1.1632  

[4] Weinberger, A. (2011). Principles of transactive computer-supported collaboration scripts. Nordic Journal of Digital Literacy, 6(03), 189-202. DOI: 10.18261/ISSN1891-943X-2011-03-06 


Brittany Blankinship

Brittany Blankinship is a Lecturer in Data Science at the Edinburgh Medical School. She teaches data science, R programming, and Python to students from various backgrounds and experiences, both online and in person. She has experience teaching undergraduate, postgraduate, and continuing professional development students. Brittany is passionate about delivering high-quality online learning, tackling the stigma around teaching and learning statistics and coding, and creating a supportive learning environment for diverse learners to thrive.


Charlotte Desvages

Charlotte Desvages (FHEA) is a Lecturer in Mathematical Computing, a teaching-focused role in the School of Mathematics. She teaches Python to mathematics students with a wide range of previous programming experience, from complete beginners to experts. She also holds the role of Director of Equality, Diversity, and Inclusion in the School of Mathematics. Charlotte is interested in inclusive teaching practices, particularly those which facilitate peer learning, and demystifying programming to make it accessible (and fun!) to all.


Umberto Noè (FHEA) is a Lecturer in the Department of Psychology and has been teaching data analysis, statistics, and R programming to both undergraduate and postgraduate students. He is passionate about teaching to students from diverse backgrounds as well as removing barriers to learning and fostering a collaborative and engaging learning environment. He is currently interested in extending pair programming principles to groups of more than two students and has been implementing this practice in his own first-year course.


Pawel Orzechowski

Pawel Orzechowski (FHEA) is currently a Lecturer in Programming for Data Science at the Edinburgh Medical School. Pawel is passionate about teaching programming to people across disciplines. He brings a decade of experience as an industry programmer, as well as extensive teaching expertise at coding bootcamps and the university. The result includes several novel educational patterns such as flipped classroom, badges, relentless feedback, mini-diaries and live data. Pawel co-organises the PairProgramming.ed.ac.uk community and codebar Edinburgh.

Leave a Reply

Your email address will not be published. Required fields are marked *