Shashi Krishna Computer Science, Education, Research

Pair Programming in the classroom

Background

The concept of pair programming (PP) has for years held much promise for collaborative and effective student work in a computing classroom. The idea behind this, for the uninitiated, is that students get into pairs and work on a single challenge. They take on the roles of driver and navigator depending on the challenge at hand and the solution is, ideally, solved faster and is expected to be of better quality. For the last few weeks I have been reading both the research and the application of PP in a K12 setting. While there is surprisingly very little that can be considered good guides (maybe more K12 CS educators should document their findings with work like this?) I think I now have a better grasp on the topic. As a CS teacher even though I have tried different versions of PP in my classes, they have resulted in varying degrees of success. You will find a list of my classroom findings in the final section of this post.

To start with, here is a short overview of PP from Code.org. While the setting is optimistic as it is aimed at promoting and celebrating collaboration in CS inside classrooms, the video is more an advert than evidence. However, it highlights some fundamental dos and donts for kids and teachers to keep in mind while attempting PP.

The research

Since there are multiple aspects to this sort of work, I have tried to categorize them by what I felt were the critical ones.

Aspect 1: Addressing equity issues in the pair

One of the primary reasons PP is considered in a classroom is to encourage equity so that every student has access to the same learning resources and opportunities. While this is certainly the aim and driving force of a PP activity, some research papers have discovered the rise of inequity in such settings. A co-authored research paper (Lewis & Shah, 2015) investigated samples from a Grade 6 Computer Science class and identified some factors contributing to inequity. In the Middle School CS class they collected data from the following observations were made:

  • A sample student J was paired with four different partners and the contributions of J in each pair was vastly different.
  • The driver-navigator switching of roles worked better when J was working with lighter, funner (game design) projects. But when J was working with more focused design projects that were not game based the equity wasn’t as evident. His role was seen as more submissive and less collaborative.
  • Factors that were considered for such a difference were:
    • His relationship outside of the classroom with each of his pair partners.
    • The nature of the project itself (as identified) which made him feel less comfortable with the workload.
    • Being paired with someone who was more intent on “lets just get it done quickly” rather than collaboratively trying to ensure driver/navigator balance.
    • Lack of clear instructions/differences in priorities of why the challenge was being carried out also were potential influencers.

Noteworthy passages

Aspect 2: Friendship as an influencer

Another paper I came across that focused on equity challenges investigated friendship being a primary factor in the effectiveness of PP in a Middle School scenario. This paper (Werner et al, 2013) discusses experiments made using a programming course called iGame that ran across four semesters and involved 189 Middle School students. Given the duration of the study (2 years) some partner pairings had students leaving and needing repairing. So a total of 160 students remained till the end : 60 girls and 100 boys (61 – Grade 6, 49 – Grade 7 and 50 – Grade 8). Ethnic and living backgrounds (with parental consent) were also collected to see if that played a role in how associations were built.

One of the primary questions this paper attempted to address was: Under what conditions does pair programming benefit the learning outcomes of middle school students programming games using Alice?

The following highlights emerged from their study.

  • Students were also asked if they considered their partner a friend (Friendship Quality Scale) with a rating of 1 (Not True) to 5 (Really True). One question “My partner is my friend” had be rated >=3 by both partners to be in the “friend pairing”. There were 30 of these eventually.
  • The study measured confidence levels with a computer as part of their pretest. While the knowledge of how Alice works went up, as expected, the general confidence level with computers did not. Gender did not have any influence on these values.
  • Friend pairings saw more stability in lesser confident partners. Meaning, as the programming tasks progressed, lesser confident partner was influential on the partner with more computing confidence.
  • In non-friend pairings both partners were stable before and after Alice testing with no major statistical influence showing up for either partner.
  • Biggest rise of Alice knowledge happened when confident partners worked with friends with initial Alice knowledge.
  • Knowledge and confidence both need to be addressed by teachers when trying to pair for computing projects.
  • “Pair Effectiveness Score” – Inclusiveness, responsiveness, negative behavior – can highlight important patterns for teachers to effectively improve pairings.

Noteworthy Passages

Aspect 3: Gender influence on PP

Another interesting aspect to see how pairs work best in PP is gender. Computer Science has struggled to get girls to enroll in large numbers. This, however, is changing with initiatives and that is encouraging. Researchers from University of Iowa conducted a study of undergraduates from Fall 2016 – Spring 2018 (Jarratt et al, 2019) and found that including a female in each pair (male-female, female-female) was overall more beneficial for the projects. Attendance, participation, interest and collaboration all increased in pairs where a female was present. This is excellent news and a strong rationale to look at not just encouraging more girls into Computer Science but also to find ways to overrepresent them when possible.

Another study (Jarrat et al, 2019) confirms the same where 550 graduate and undergraduate students were studied for compatibility and working efficiency as pairs. The consensus was similar that women showed more confidence and seemed to gain more out of the PP experience. Overall students who were paired (89.4%) showed higher confidence levels than those who worked independently (71.2%). Some observations on these findings:

  • While it is not always possible to ensure a 50-50 ratio in K12 setting (although that situation is rapidly changing thanks to collective CS efforts around the world), keeping an eye on gender balance seems to be important.
  • PP overall seems to benefit as an experience when skill levels are not the primary factor for pairing. This factor showed up in the scaffolding experience too (below).
  • There is still lot of research that needs to be done in the K12 setting for higher education researchers to really create a better bridge for approaches like PP. Once again, the need for more data to be pushed out of K12 into research rings out loud.

Noteworthy Passages

Aspect 4: Scaffolding the PP experience

Beyond the data generated by the papers above, I was also curious about how the scaffolding of PP as an experience actually works. I firmly believe that PP is more than just about the coding aspect because it brings together collaborative and supportive attitudes of a more agile nature. We are constantly and increasingly surrounded by dynamic structures that require us to quickly adapt and work in a extremely diverse groups of people. So if PP is used as a pragmatic experience for such a skill to be developed, how would that look like in schools?

A collective reading of research papers here, here, and here, brought to light the following observations:

  • Pairing (somewhat) by skill levels: While this isn’t a critical piece ensuring a smooth working partnership is essential for PP to be effective. Compatible partnerships, as in our roles as adults, are not an overnight thing. But with the right strategies – daily checks, logs, monitoring of progress, clarifying disputes etc. – it can be improved. Note: There is a body of work that recommends that students pick their own partners since it triggers motivation and more open conversations.
  • Choose PP projects wisely: There is no need to implement this all the time. PP is just one of many strategies that create a support structure for young developers. So perhaps selecting one project (that runs for 2-3 weeks) should be a good platform for it.
  • Standardize structure: Even though coding styles are bound to differ ensuring the entire class follows a singular approach to document/stylize their code increases likelihood of lesser issues/disagreements arise between partners.
  • Get past the teething issues: In time, the idea of paired programming does pay off. Quality of work created by pairs is both time and feature efficient. Creating opportunities in classrooms for this to develop is key.
  • Frequency of role switching: One study indicated interesting findings (with middle school students) with free-flowing switching modes. The patterns of how they switched roles was documented via a log (below) and allowed students to work at a more confident pace than a strict timed limits of 5,10 or 20 minutes.
“Investigating the Period of Switching Roles in Pair Programming in a Primary School
“, July 2017

Noteworthy Passages

ITiCSE ’19, July 15–17, 2019, Aberdeen, Scotland UK © 2019 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-6301-3/19/07. . . $15.00 https://doi.org/10.1145/3304221.3319782

My experience

Computer Science classes in the IB tend to be smaller in numbers (as an elective) so the range of class sizes where I have attempted PP are from 12-20. Some of the highlights based on the reading above.

  • Smaller classes tend to have better recognition and acknowledgement of every member than larger ones. So pairing them did not require too many preset conditions – such as skill levels or social association.
  • Most kids coming into Year 1 are relatively new to coding (basic skill levels) so compatibility wasn’t much of an issue.
  • Driver/Navigator role switching was marked at usually 15-20 minutes so that in a 90 minute session the switch happens at least 4 times.
  • Once the solution starts to emerge the Driver/Navigator roles tend to get blurry since kids have increasing confidence levels and so ensuring they adhere to their role (as in a navigator is suddenly inspired to try something new but has 15 more minutes left) was a challenge.
  • Some of the frustrations from Paper 1 (above) on speed becoming a bigger issue was also there. They had to be reminded it was not a contest and that learning/creating collaborative solutions was a real goal.
  • General confidence levels seem to rise with each session since the reliance on a partner for support grew.

Primary Takeaways/Next Steps

  • My primary takeaway from this exercise was how little there is in terms of research from the K12 setting. Most of the studies are based on work that undergraduate/postgraduate folks have done by visiting schools/colleges. How much of that data would be more accurate if K12 teachers/admin were the ones curating them?
  • The growing need to connect Higher Ed computing research to what is being delivered at the end of High School is obvious. So lot of room here for teachers to provide valuable data, observations and analysis to research points.
  • Like any collaborative method, PP is about repeated practice. So creating a structure and observing what works (and what does not) would help all students get the best of such an experience.
  • PP has shown different results in different settings. Is it worth trying more frequently? This can only be established if more scenarios are documented and tested. More feedback from students about their experiences need to be gathered. If the industry sees benefit in it, then K12 education can definitely add more factors to influence it.

Further recommended reading

Here are some more useful articles I found that addressed PP in a school/undergrad setting.