I’m a lecturer in the School of Mathematics at Edinburgh University. A lot of my job involves teaching introductory programming for Mathematics students. This post is adapted from a reflection I wrote in 2022 on using pair programming in online teaching — why I decided to do this, and how it went overall.
Designing an engaging online session
For the academic year 2020/2021 I was Course Organiser for two introductory Python courses: Python Programming (MSc, semester 1) and Computing and Numerics (Y2, semester 2). Practical sessions for both courses had usually been drop-in computer labs, where students work on exercises with tutors in the room to help. That year however, with all computer labs moving online due to Covid, it quickly became clear that simply transferring the drop-in format to a digital session would not be practical nor pedagogically valuable.
The need to rethink course delivery on a short timescale created momentum – in the School of Mathematics, a School-wide project [1] provided the structure and resources to ensure our courses were ready for 20/21. Although the focus was on adapting to digital delivery, this was also an opportunity to reflect more broadly on learning outcomes, and capitalise on this momentum to implement long-overdue improvements. For programming courses, in particular, my view was that such improvements should go in the direction of developing students’ programming practice, not just their knowledge, to better prepare them for the professional world.
Lab sessions are a key setting for students to develop their practice and teamwork skills. Both courses were allocated a 1-hour synchronous session each week. I set out to structure these sessions not only to facilitate learning, but also to embed elements of professional practice. Seeking colleagues’ expertise in online and blended learning (including many contributors to this community!), consulting the literature, and assessing current industry practice, led me to consider pair programming.
Pair programming is a widely used paradigm in industry, with demonstrable benefits to code quality, team building, and knowledge sharing [2]. During a session, a pair of programmers share a computer, and take the respective roles of driver, with exclusive control of the keyboard and mouse, and navigator, actively observing the driver and helping them program; they switch roles periodically.
In the classroom, pair programming provides a form of collaboration script to facilitate peer learning [3]. In a literature review of pair programming in undergraduate courses, Hanks et al. report that “the benefits of pair programming include increased success rates in introductory courses, increased retention in the major, higher quality software, higher student confidence in solutions, and improvement in learning outcomes” [4].
In my courses, both programming and virtual learning spaces would be new for most students; figuring out a way to cooperate efficiently with classmates in this unfamiliar environment may not be straightforward. This cognitive load can be minimised by providing additional structure to facilitate interaction [5], provided it is not overly constraining [3]. As an industry-standard, collaborative workflow with scripted roles, with well-documented pedagogical benefits, pair programming seemed fit for purpose.
Each week, students pair-programmed via Zoom, working on a dedicated task during the workshop session. They switched roles every 15-20 minutes, to ensure that both students took the driver role at least once during the session. In the first two weeks, I scaffolded the workshop tasks with detailed written instructions and cues for both driver and navigator, to help them learn the roles and workflow.
Student feedback
Throughout the academic year, student feedback provided valuable data points to assess the effectiveness of pair programming in my classes.
Peer learning and social interaction
For both courses, the majority of student feedback was positive, with most comments pointing at cooperation, social interaction and discussion with classmates, and peer learning as positive aspects:
“[It] was nice to get some 1-1 interaction through the pair programming in what could have been an otherwise solitary course.”
“Working with others is also a real benefit as it allows you to learn from others, or teach others which further consolidates your own learning.”
Tutoring and troubleshooting
A key concern in planning online labs was the availability of individualised support. During the sessions, tutors could easily be called into breakout rooms for help, but working in pairs also provided students with an immediate source of help and support in their partner. As pairs worked together to solve many of the more benign issues (e.g. syntax errors) independently, tutors were left with more time to help students struggling with more complex problems.
“I didn’t interact much with tutors since we often solved coding issues by ourselves. This is a good feature of the workshop.”
Technological barriers
The negative feedback comments typically pointed at the sessions being too short, sometimes worsened by technological hurdles. Distributed (i.e. remote) pair programming requires students to juggle multiple applications to work together. As expected, this issue improved significantly as the semester went on and students got used to their tools, but clearly a longer session would still be beneficial.
Pairing successes and mismatches
My initial approach was to pair students randomly each week. My hope was that the benefits of working with many different students would outweigh the occasional issues with mismatched pairs, potentially compounded by communication issues (particularly between ESL speakers with sometimes low-quality audio). This seems to have been the case, some of the time:
“I have really enjoyed our workshops. In the first few weeks we were put with random people which I enjoyed as I was able to meet a range of coders and try out some things which were a little different to maybe the code we had already met.”
However, student feedback indicated that mismatched pairs was a frequent problem. Within both cohorts (MSc and Y2 Mathematics students), levels of programming experience vary immensely between students coming into these courses. Dysfunctional pairs were typically either an experienced coder paired with a complete beginner, or two complete beginners paired together. To address this, I started letting students choose their own partners in Semester 2, and work in triples rather than pairs if they wished to do so (with two navigators and one driver), which students seemed to appreciate:
“Being able to choose our own breakout rooms was really effective.”
“The feature of getting to pick who you work with during workshops is extremely helpful, as it allows us to team up with people we know we can be productive with, so I’d love to see that being carried on.”
There is no clear consensus in the literature on what constitutes an effective pairing. A 2011 literature review by Salleh et al. [6] suggests that pairs of students with similar ability are generally effective (measured in terms of “technical productivity, program/design quality, academic performance, and satisfaction” [6]). However, I believe that there is an argument about prioritising comfort and letting students choose their partner, instead of trying to form pairs based on some measured or self-reported metric for programming ability. For instance, a study on student group dynamics [7] suggests that in a structured group activity, “comfort was strongly positively correlated with student performance”, and that letting students self-select their group mates may be a viable strategy to promote participation and effective learning.
Feedback is biased
As a final remark, I find it difficult to draw conclusions on effectiveness from student feedback alone. Response rates for feedback surveys are low (typically 10-20%), and I wonder about the “silent majority”; as reported in [8], self-selection bias in course evaluations may affect results significantly. As one student said:
“I didn’t like the format (work in pairs) so I decided to not go to many of them.”
In both courses, workshop attendance dropped significantly over the semester. Although this was on par with previous years, it poses an important question: did any students stop attending because of pair programming, and what can I do for these students?
References
[1] The ASID Project: A Student-Centred Outlook on the Development of Hybrid Teaching and Learning. Teaching Matters Blog, University of Edinburgh, 28th January 2021. URL: https://www.teaching-matters-blog.ed.ac.uk/the-asid-project-a-student-centred-outlook-on-the-development-of-hybrid-teaching-and-learning/
[2] Williams, L. (2010). Pair Programming. In P. A. Laplante, editor, Encyclopedia of Software Engineering, volume II.
[3] 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
[4] 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
[5] 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
[6] Salleh, N., Mendes, E., & Grundy, J. (2011). Empirical Studies of Pair Programming for CS/SE Teaching in Higher Education: A Systematic Literature Review. in IEEE Transactions on Software Engineering, 37(4), 509-525. DOI: 10.1109/TSE.2010.59
[7] Theobald, E. J., Eddy, S. L., Grunspan, D. Z., Wiggins, B. L., Crowe, A. J. (2017). Student perception of group dynamics predicts individual performance: Comfort and equity matter. PLOS ONE 12(7): e0181336. DOI: 10.1371/journal.pone.0181336
[8] Goos, M., Salomons, A. (2017). Measuring teaching quality in higher education: assessing selection bias in course evaluations. Res High Educ, 58, 341–364. DOI: 10.1007/s11162-016-9429-8