Summary of A Comparison of Two Pair Programming Configurations for Upper Elementary Students

(Jennifer Tsan et al)

In this experience report, researchers explore the practice of paired programming with primary school-aged learners. Specifically they compare the standard approach, using a shared device and driver and navigator roles, with a two-device approach, in which each student works synchronously on the same project using a second device. The report uses interviews and analysis of student conversations to identify some of the benefits and limitations of each approach.

Quick summary:

Primary researcher: Jennifer Tsan
Sample/group size: 117 4th and 5th grade students across three schools
Study size: medium-scale
Data type: mixed
Measures: student interviews, observations

Summary of methodology:

The report summarises findings from three similar studies conducted with students aged between nine and eleven at three different schools in the US. In each scenario, students tried the two approaches to pair programming while completing a collaborative programming project using the block based programming tool NetBlox. One of the three schools delivered the experience via the science curriculum, while the other two schools had it embedded in computational thinking/computer science lessons.

Although there was some variation in exactly how the lessons were delivered, due to timetabling, all students received a similar experience. Their interactions while working in pairs were recorded and later analysed, with particular emphasis on the types of conversations occurring while working together.

Exploratory conversation - learners challenge each other, offering explanation and alternative ideas.
Cumulative conversation - learners seek to avoid conflict and therefore converse uncritically.
Disputational conversation - learners tend to have unresolved disagreements.

Conversations are seen and “productive” where exploratory conversations are taking place and less productive where they are either cumulative or disputational in nature.

The researchers followed up their observations with interview questions designed to elicit the students’ preferences for each approach to pair programming, as well as the perceived benefits and challenges.

Summary of findings

Analysis of learner conversations showed that in both forms of pair programming, learners tend to rely on cumulative conversation, avoiding critical conversations that may lead to conflict.

Traditional pair programming, with shared device and driver and navigator roles, featured more disputational conversations which frequently occurred either just before or after a period of exploratory conversation. While learners were focused on the same task, they frequently disagreed.

In two computer pair programming there was less disputational conversation, but exploratory conversations frequently led to cumulative conversations. In this scenario, the collaboration took on more of a consultative role, with learners working in parallel on the same task rather than together.

Conversations with learners showed a general preference for the two-computer approach as well as some perceived challenges and benefits of each.

In single computer pair programming, the participants would prefer to be the driver, got frustrated with turn taking, and felt it was less hands on. However, there was also a view that you learnt more and can see what your partner is doing and spot mistakes.

For two computer pair programming, the challenges appeared to be broadly technical in nature, frustration about slow synchronisation of the software or not being able to follow their partners work in real time. For benefits, the participants recognised the perceived increase in independence and more hands-on experience.

The authors end with five main takeaways:

Students suggested that the two-computer approach gave them more independence, although this may lead to co-operation rather than collaboration. They suggest that where educators want to promote greater agency, this approach could be used.
Co-ordination was critical to both approaches, whether it’s about turn taking or agreeing what each partner will work on. Educators should ensure they scaffold effective communication practices.
Each approach may offer different learning, while participants say they learnt more with both approaches, what they learnt varied. In a shared-computer model, they talked about learning more from their partner, whereas the two-computer approach gave them more hands-on experience.
Educators should pay attention to the types of conversations occurring in pairs and be alert for disagreements, particularly as the challenge level of the task increases.
Participants felt that the two-computer approach was helpful in chunking their tasks into subtasks and enabling them to complete in parallel. Breaking a problem down into chunks is a valuable skill to develop in learners. However, it also comes with a co-ordination and communication cost

Reviewer’s opinion

This experience report intrigued me as someone who regularly used pair programming with learners and has seen the benefits of the approach. I think that more collaboration in general should be encouraged when engaging in programming tasks. The two-computer approach to pair programming is definitely intriguing and may be something that teachers want to try for themselves

One aspect of the approach that the report didn’t explore in any depth was that this approach depends on having an appropriate collaborative programming tool. The study made use of a block-based tool for collaborative programming which needs learners to adapt to, while there are collaborative text-based programming tools for older learners, these may come with a similar challenge.

Regardless of the approach taken to pair programming, one important consideration that this report underscores is the time needed to effectively train and prepare learners for this way of working. For traditional pair programming, educators should dedicate time and energy to supporting learners to communicate and take turns. For two-computer pair programming, a similar level of attention needs to be given to co-ordination and breaking down tasks.

About the author

James Robinson, Senior Learning Manager (Pedagogy), Raspberry Pi Foundation