Starting the research
I carried out the research over a six-week period with one class of students aged 13–14 and another class aged 14–15. Social distancing restrictions in the UK had relaxed enough to allow pupils to sit near each other, but they still could not use the same computer. This meant that I couldn’t investigate traditional pair programming, and instead, I investigated through the lens of virtual pair programming. This involves two people working on their own computer, but using a shared integrated development environment (IDE). Both people can type at the same time, so the driver and navigator roles are blurred.
At the start of the research, I measured pupils’ programming skills and programming confidence levels. I would measure these again at the end of the research, to understand the benefits of the pairing activities and the best combinations of pupil pairings. I assessed pupils’ programming skills using Eedi’s Diagnostic Questions website and England’s National Centre for Computing Education’s question sets ‘Principles of programming’, ‘Design and development’, and ‘Algorithmic thinking’. I also carried out a survey of programming confidence levels using Google Forms.
Each pupil’s predicted grade in computer science also formed part of the initial data that helped to identify the different pairings. Pupils were categorised as having one of a range of abilities in programming, from low to very high, this sometimes differed from their predicted GCSE grade, so a higher-ability pupil may have a low programming ability based on the initial assessment. I allowed pupils to work solo, or with another person of their choice, each week. This provided lots of different combinations of pairs and solo programmers for the research.
Innovative technologies
Innovations in online technology accelerated while I was completing my master’s. One such innovation was the multiplayer mode in the Replit IDE, which the older group of pupils used. This mode allows different people to work on the same program at the same time, from different locations. During the research, I would introduce a programming topic, and then pupils would complete the programming challenges on Replit, either as a pair or solo. Pairs could sit near each other so they could communicate face to face, as well as using the IDE’s built-in comment and chat facilities.
In the younger group of pupils, pairs and solo programmers used blog.withcode.uk, which introduces a topic and provides a self-marking programming challenge. Those collaborating as a pair discussed a solution and completed the challenges on their own computers.
Results from the research
It was evident that pair programming can have a positive impact on programming proficiency, although there are other factors affecting performance. One key indicator of performance is confidence in programming, which appears to have a bigger impact on performance than predicted grades, particularly for pupils with less confidence.
The results show that solo programmers performed better in the weekly challenges than pairs did, both in terms of number of activities completed and percentage score on the activities completed successfully. Bear in mind that the solo programmers included more confident pupils. Furthermore, the use of a virtual — rather than traditional — pair programming technique, with the driver and navigator roles blurred, may explain the drop in speed for pairs.
The pair combinations used did not appear to have any impact on the outcome of the weekly activities. In some weeks, a low-ability pairing performed the same as a medium-ability pairing. Also, in the final practical activity, a solo low-ability pupil outperformed a pairing of pupils with medium and very high abilities. What was clear from the research, though, is that pairing pupils with lower confidence did not improve their final assessment score or confidence level. Pupils who were able to experience a mixture of solo and pair programming did, however, see an improvement in their confidence and achieved a higher score in the final assessment.
Recommendations
There are several factors to consider when using pair programming in the classroom, including the pairing of pupils and the hidden benefits. If using pair programming, there should also be an opportunity for solo programming; pupils should avoid becoming overly reliant on others. The pairing of pupils should not necessarily be based on predicted grades or programming proficiency alone. Social and communication factors are also important. My research recommends that teachers measure their pupils’ programming confidence to avoid pairing low-confidence pupils together.
As a teaching technique, pair programming appears to offer some hidden benefits, such as improved social and communication skills. Although pairs took longer than solo programmers to complete every activity, speed is not necessarily a measure of success, and if the process of finding a solution through collaboration takes longer, that is perfectly fine.
Through this research, I recognise that the focus of programming lessons should be on confidence-building activities. Activities that are too difficult can lead to pupils giving up. When pupils did complete the challenging but achievable activities during this research, I could hear their excitement and sense of achievement. I heard lots of “I did it!” and “Yes, it’s working!”, and this is surely what a computing education is all about.
Links to resources
Assessment platform for computing: diagnosticquestions.com
Self-marking programming challenges: blog.withcode.uk
Collaborative IDE for many languages: replit.com
