Paired Programming in Computer Science Lessons

Introduction and Context

The previous placement mentor set a target for this author to “Differentiate lessons for students of all abilities.” This target is linked to Teaching Standard (TS) 5 (DfE, 2011), whereby a teacher must “adapt teaching to respond to the strengths and needs of all pupils”. There is a strong ethical grounding for this: It is important that all pupils make progress within education so that education does not remain the privilege of a select minority nor ostracise. The standard also emphasises the “needs of all pupils, including those with special educational needs; those of high ability; those with English as an additional language; those with disabilities;” Differentiation is then an inherent component of teaching practice.

Differentiation is a broad topic within education and several approaches exist. Hramiak, A., & Hudson, T. (2011, p. 126) emphasise that in “planning your lesson it is important to consider how you are going to differentiate the activities to meet the needs to all learners.” And outlines the different types of differentiation that can be undertaken by content, activities, negotiation, support, extension, response, group work and by role.

Computer science (CS), coding in particular, can be mistaken as a somewhat solitary pursuit but this style does not support the recommendations for pupil learning that research shows. I wanted to select an approach to differentiation that would embrace the benefits of socialising and discovery learning. The school’s ethos is: “We welcome everyone with open arms and pride ourselves on our inclusive practice.”

Inclusivity is a term commonly used for minority characteristics e.g. gender, race, disability but at the crux of differentiation is the recognition that all pupils are individuals (irrespective of labels given) and teachers should utilise differentiation techniques that enable all pupils to make progress in learning.

Proposal and Review of Existing Literature

Pritchard, A (2018, p.37) describes a Constructivist view of learning as “the result of mental construction. That is, learning takes place when new information is built into and added onto an individual’s current structure of knowledge, understanding and skills. We learn best when we actively construct our own understanding.” This author’s experience as an initial trainee teacher (ITT) supports this view – students understand and retain concepts much better when undertaking activities than passively being taught information. Bates, B. (2015 pp. 46-48) summarises Vygotsky, a chief proponent of the constructivist perspective: “knowledge and thought are constructed through social interaction with family, friends, teachers and peers” and “learning occurs through social interaction as being in the Zone of Proximal Development (ZPD)”. Being in the ZPD is where learners “developed an understanding of a subject beyond their previous level of comprehension”.

Again, this author’s experience has observed young learners need for social interaction whereby they can explore ideas with peers. Indeed, a technique this author has used in teaching practice has been to identify a pupil to share their knowledge with the rest of a classroom who can be more receptive to learning from a peer than the teacher.

Sentance, S., Barendsen, E., & Schulte, C. (2018, p.30) emphasise that “collaboration and creativity” are “critical competencies for a new century” and “have a special meaning in the world of computer science.” It is evident, then, that learning in the CS classroom takes place more effectively with social interaction. It seemed fitting, then, for a study of a possible strategy of differentiation within the CS classroom to explore an aspect of ‘social learning’. Differentiation is an enormous topic within education research and of the various broad types available, differentiation by organisation will be used: “Students work in groups that are structured to best support their needs. This might mean students of similar abilities working together or more and less able students collaborating on a task.” – Baker,T., Evers, G. and Brock, R. (2017, p.165)

Advice on this style of differentiation offered by Baker, T., Evers, G. and Brock, R. (2017, p.171) is to “Think about which of the student’s peers may be best able to support them to reach their potential. It may be that working with another student of similar ability is supportive for some tasks, but for other activities, a pairing of high- and low-ability students may be beneficial to both. When forming groups, it may be useful to define roles for members of the group or to define rules for the way that students should interact.” A method of grouping coders within a CS environment (albeit education or industry) is to use paired-programming.

Williams, L. (2001) describes paired-programming where “two programmers working side-by-side at one computer collaborating on the same design, algorithm, code or test – outperform individual programmers. One of the programmers (the driver) has control of the keyboard/mouse and actively implements the program. The other programmer (the observer) continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects, and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software.” Hanks et al (2011) state that “pair programming is frequently used in introductory programming courses as there is notable evidence that its use helps students learn to program.”

Muijs, D., & Reynolds, D. (2018, p.220) clarifies the need for differentiation by “understanding that we are dealing with diverse pupils, and making sure all are able to learn in our classrooms”. A common misconception about differentiation (that this author previously held) is that differentiation involves producing several lessons instead of one, tailored to different ability students. This would be an enormous amount of work for a teacher. Differentiation is about achieving the learning objective by making learning outcomes accessible to the range of individuals’ strengths and weaknesses in a class.

An initial concern with using paired-programming would be that lower attainment (LA) pupils may over-rely on higher attainment (HA) pupils and ironically become more passive in learning. A study undertaken by McDowell et al. (2006), cited in Hicks et al. (2011), concluded “by pairing in the first course, students were able to build a foundation that led to later success when they had to work alone. It also seems to refute the notion that pair programming results in weak students passing the first programming course by over-relying on their partners, only to fail later when they have to work alone.” This conclusion was also supported by a study (Nagappan et al., 2003, p.194 – cited in Hicks et al., 2011) that concluded “pair programming is not detrimental to a student’s performance in future programming courses done in solo.” The suggestion is that the skills learnt in pair-programming are retained by individuals in the pair. The purported benefits of paired-programming are discussed below are principally outlined as an improvement in confidence and productivity.

Hicks et al. (2011) state that “Many studies have shown that students who pair are more confident than those who program alone, although some students are ambivalent about the relationship between pairing and confidence. Another study cited (Simon and Hanks, 2008) “suggests that it may be important for students to program individually at some time to build their confidence.”

Hicks et al. (2011) discuss the quality of code produced by pairing: “Research studies have shown that pairs produce higher quality code than solo programmers, although this does not necessarily suggest that the students who paired learned more as a consequence.” and cite several different studies to support this. A salient point is noted from a study whereby “These greater submission and error-free compilation rates suggest that paired students are able to overcome problems that frustrate solo students, who may give up.”

Plan

The research is planned to involve three sequential lessons for a class of 17 pupils in year 9 studying key stage 4 CS. The class is mixed ability, predominantly male (3 female students). One pupil (pupil 1) is wheelchair bound, has cerebral palsy and moderate learning difficulties and another pupil (pupil 2) is on the autistic spectrum disorder. Five pupils (pupils 6, 11, 13, 14, 16) are classed as pupil premium (PP). The paired-programming method will be introduced to the class and students will complete coding challenges set throughout each lesson. The challenges will help pupils actively learn core programming concepts and three lessons are themed around lists, writing files and data validation respectively.

The key objectives to explore the purported benefits of paired-programming, previously discussed, are defined as:

  • Does paired-programming improve pupil confidence and willingness to take a more active role in their learning?
  • Does paired-programming improve the quality of work produced – indicating a degree of self-improvement?
  • Does paired-programming provide support to pupils with different educational needs and levels of attainment to enable progress across all pupils?

Wilson, E. (2013, p.151-2) discuss the importance of triangulation (using multiple perspectives, in social science research and the importance of reducing the Hawthorne effect (also known as the observer effect whereby subject beyond observed may change their behaviour if they are aware of being observed). A variety of perspectives will be used in order to ascertain the impact of this strategy.

Observations

My own observations, as the class teacher, of pupil engagement will primarily be used to understand whether pupil engagement had changed. I am familiar with the class individuals through previous taught lessons and data that has been collected on attainment and attitude to learning. These observations will be documented in a weekly journal and referenced in the analysis sections later.
Host teacher (mentor) observations will be recorded in the form of lesson observations and from meeting notes will also be referenced.

Questionnaires

Hopkins, D. (2014, p. 140) suggests questionnaires as a suitable means of data gathering: “Questionnaires hat ask specific questions about aspects of the classroom, curriculum or teaching method are a quick and simple way of obtaining broad and rich information from pupils.” The advice offered is to be “relatively unsophisticated in the structuring of questions”, “keep the questions simple” and to use open ended questions – “what did you like best?” and “what did you like least?”.

Each lesson will then conclude with students providing structured feedback via a brief (online) questionnaire that will rate pupils’ engagement/perceptions within the lessons and their confidence undertaking tasks/using skills as illustrated in Appendix A. The questionnaires focus on qualitative feedback but quantitative data can be gathered via ratings style questions.

Assessment

Prior to the study, I had mainly observed the class and only produced a few taught lessons. I had planned a formative assessment in order to understand the pupils’ progress with each programming concept. This will produce attainment data. After the study, an end of term summative assessment will be undertaken and this will produce attainment data that can be quantiatively compared to the previous assessment results.

Ethics

Wilson, E. (2013, p.92) states, that in this type of research, “The potential for harm is not very great and the sorts of activities that participants are likely to be undertaking are not very different from those that they do every day”. Indeed, this would be the case with the intervention proposed here – it is likely that many teachers who have used paired-programming have done so without ethical consideration. Wilson continues to discuss ‘informed consent’ as relevant to gathering feedback. A letter was sent to parents/carers (Appendix B) of each pupil and replies were collected.

As the study is working with young (and therefore by definition, vulnerable) people, it is vital that confidentiality is maintained. No reference to the school nor pupils’ names are made in the write-up and any other information that could be used to identify individuals has been excluded or minimised. All information relating to the lessons, observations, evaluations or pupils and their work is stored on encrypted media and will only be retained until the conclusion of the study.

The study is not anticipated to advantage only a selection of pupils as all pupils in the class are involved in the study. The study is anticipated to produce positive outcomes for all pupils involved and therefore any detriment to individuals learning or progress was not anticipated. It is possible that the strategy may disadvantage the two SEN pupils because one has a degree of autism (and may find the social aspect difficult) and the other, which is discussed later, is a relatively solitary individual and has little interaction with other class members. I will be mindful of this from the outset and engage specifically with these pupils to intervene if concerns present.

Impact on pupil progress and participation

Overall, pupils worked well in the paired-programming activities (compared to their engagement in previous lessons, programming in solo). As I walked around the classroom, I was pleased that most conversations were about the task in hand; and pupils seemed to be quite relaxed despite a busy engagement with the activities. I would suggest that being ‘relaxed’ is a better environment for cognition, and learning new concepts, than being under-pressure; and even stressed. Host teacher observations (Appendix H) included “A Well-ordered class which is very responsive to the engaging and interesting tasks you provide for them.”

In a chapter discussing differentiation strategies, Lau, W (2018, p.84) recommends “In the first lesson, you should use a seating plan; this can be displayed on the board and also can be printed out so that you can instruct students where to sit. Seating plans should be data led and designed to maximise learning.” The initial seating plan I designed had HA pupils paired with LA pupils so that HA pupils could assist LA pupils’ learning; and their own learning by addressing errors and misconceptions. This generally worked and the host teacher (Appendix H) observed “Good that students support each other in coordinated pairs to support programming skills.” This was the principle objective of the study and this peer-support was evident throughout the series of lessons.

However, I was more intimately involved than the host teacher, supporting students in the classroom as I circulated around pairs, and in some instances, it was evident that the HA pupils would dominate the coding activity and the LA pupils would passively observe. I regularly intervened to ensure pupils swapped the driver and navigator roles where this was evident in a few pairs – in most pairs though, this occurred without intervention. However, the coding challenges were not set to test knowledge of syntax (as code hints would be often displayed) but to test computational thinking and understanding of programming concepts. Some LA pupils would happily type what a HA pupil dictated but when the roles were swapped the LA pupil would typically not feel comfortable as the navigator, planning the code, and be disengaged.

Pupil 7 stated in the feedback (Appendix F) “If your partner is of a different ability it’s hard to get anything done” and Pupil 4 (who is HA) had also fed back “The Slow Pace And That I’m Normally Teaching Someone How To Code” with an improvement suggestion of “Grouping People with the same ability together”. A host teacher observation from the first lesson (Appendix H) was to “Consider re-organising pairs to eradicate the occasions where students are off task”. In subsequent lessons, I re-allocated pairings of students so that abilities between students did not differ so extremely.

This seemed to work much better as the LA pupils were less reluctant to have a go and make mistakes with the scrutiny of a HA pupil next to them. A female pupil was initially paired with quite an introverted male pupil and had approached me at the end of the lesson to be allowed to work alone. She started to cry when I encouraged her to give it a try next lesson so I agreed to her request. In the following lesson, however, she was willing to pair with another female pupil of similar ability and this worked well, and they were both engaged.

A few pupils would have liked to have chosen their own partners with some feedback “let people choose their own groups”, “being able to choose who you work with” and “letting us choose our own pairs”. Although I didn’t risk allowing this (due to concerns of disruption and behaviour), in retrospect, I think this would have worked well. A few weeks after the study, when the host teacher was absent, I gave pupils complete freedom to work alone or work in a pair of their choice. Incredibly, these lessons worked very well and behavioural issues were minimal. These lessons were not part of the study but nevertheless too noteworthy to exclude from mention.

Pupil confidence in prior coding lessons emerged from a sense of completion as they copied code from the board and either annotated it or made small amendments – they would have working code within a few minutes. However, in these lessons, the achievement would be gained from an understanding of the concepts and synthesising concepts together to create working code. This was initially difficult and I could see that pupils were taking time to adjust from the more ‘instant gratification’ they had previously been used to.

Lawson, T. (2012, pp. 64 -68) discusses Bloom’s Taxonomy and how creativity to access the higher-order thinking requires risk taking. In order to complete challenges, pupils would need to think creatively and be competent synthesising coding concepts together. Where pairs contained two LA pupils, this was problematic and they would be reluctant to start work on challenges compared to more HA pairings.

Results from the assessment after the study showed students had, on average, improved scores by 11% (2 s.f.) compared to scores from the assessment prior to the study. The standard deviation of test scores remained at 15% (2 s.f.), which suggested the same variation of ability existed. The graph below shows the percentage score for each pupil in the formative test (prior) and the summative test (afterward) as well as their delta between the two tests.

A graph to show the percentage score for each pupil in the formative test (prior) and the summative test (afterward) as well as their delta between the two tests.

The largest improvement was observed in the LA pupils with a score increase of 17% compared to only a 6% in the HA pupils. This does then suggest, however, that the LA pupils had the most gains from the paired-programming. Indeed, the highest percentage improvement of the class was for the pupil with the lowest overall attainment – Pupil 1 – with an 18% increase in assessment score. Pupil 1 is wheelchair bound, has cerebral palsy, dyslexia, visual perception disorder and short-term memory issues. Pupil 1 would often sit alone in class and would not typically socialise with other class members – probably due to a separate daily routine where the pupil spends a lot of the day in learning support.

Pupil 1 evidently benefitted from the paired-programming and their feedback from the first lesson was an enjoyment of “The Social Aspect”. Indeed, I witnessed the pupil conversing much more actively during the lesson and appreciating the reciprocity of exchanging ideas with their partner. Pupil 1’s routine meant they left lessons early and only completed feedback for lesson 1 – I suspect further discussion with pupil 1 would enabled exploration of other benefits of the strategy; possibly with implications for SEN pupils.

The table below summarises the students’ responses to the questionnaires (Appendix A) where a mean average of students rating (out of 5) to four different questions is provided for LA and HA students:

Students’ responses to the questionnaires.

The data is limited (17 pupils) and does not provide the depth of insight that the qualitative responses and observations offer. However, the data indicates that the LA pupils had a better experience of the lesson and paired-programming activities and were even more confident in coding than the HA. The HA did find the lesson more challenging, which could indicate they had a more difficult challenge in the pair to utilise the higher-order thinking skills required.

Considerations

As with any social science study, the insights drawn are from context of the author’s ontology; and were only from the experiences of three lessons with one particular year group in one school. Other factors (such as demographics and organisational culture) limit the generalisability of conclusions. A larger sample size and perhaps a control group would provide more reliable insight into the effectiveness of paired-programming. Nevertheless, the depth of insight is useful as the way individual students reacted to interventions highlight implications for future research. It is evident that traditional categories of pupils (e.g. SEN, PP, HA, LA) are not homogenous groups with uniform traits: Individuals are complex and subsequently can vary dramatically in response to teaching strategies.

Impact on Professional Learning

My initial observations of CS lessons taught on this placement found that a programming concept was taught but pupils would not necessarily need to understand it in order to copy code from the board into workbooks and annotate it. Lessons were tightly structured with brief activities; and progress was documented – evidenced. However, my experience of this project highlighted the importance of implementing strategies, so students discuss ideas amongst themselves (and a teacher) to better demonstrate understanding (or expose misconceptions).

CSE results for the department are below HA pupils forecasted grades: I would suggest that contemporary approaches to differentiating work like pair-programming could stretch both LA and HA pupils. The approach is a substantial change in paradigm, the reception to which I did not anticipate. In the first of the series of lessons, I had scaffolded, with modelling and brief challenges, how to create a list in Python and then be able to reference an element of the list. That was all. The second challenge was a larger leap to code a program to create a list, change elements of the list and even gather user input (a previously taught programming concept) to change an element (illustrated in the from a lesson resource, below).

The only hints I provided were three lines of code that very generally did the operations required in a program. Few pupils were able to make progress and frustrations arose (with subsequent behavioural issues and low-level disruption). As a trainee teacher under observation, I was mindful to enforce the school behaviour policy which was to issue warnings and detentions as consequences for non-compliant behaviour. This exacerbated frustrations in the classroom.

Although I had briefed the pupils on the new paired-programming style or working, I should have more thoroughly set classroom expectations with consideration of the previous classroom culture they were accustomed to. Pupils were used to undertaking challenges that would take 5 minutes and consist of only a few lines of code. They were not practised in deconstructing a problem nor having to persist at a problem without immediate success for 10 to 15 minutes.

I did not set a clear time expectation around the challenges, which also led to frustrations as some pupils felt overwhelmed or that they were getting the exercise wrong. I expected difficulties – syntax and logic errors but I should have emphasised the importance of having an attempt (at even just partial completion) so that the mindset would be to tackle challenges methodically.

Baker, T., Evers, G., & Brock, R. (2017) state that “Teaching involves a constant feedback cycle of increasing and decreasing the level of challenge to find the ‘sweet spot’ at which a class is adequately but not overly challenged.” I should have adjusted my lesson to compensate for difficulties and not continued regardless with additional challenges (combining yet more programming concepts previously taught) as pupils would not be able to progress to further challenges without forfeiting a sense of completion from the previous. This causes frustration. Baker, T., Evers, G. and Brock, R. (2017, p.168) “A well-differentiated lesson is likely to both increase the potential for learning and minimise opportunities for students to become bored or disengaged. It is well worth the added time taken to ensure that all members of the class you are planning for will be able to engage with the material and be appropriately stretched.”

This study has shown me that while categorising pupils can be useful for planning differentiation and subsequent measures; I must approach each pupil as having a unique learning journey. Baker, T., Evers, G. and Brock, R. (2017, p.169) confirm that “While diagnoses such as dyspraxia or dyslexia might be useful for grouping together students with some common traits of common SEND, there will also be significant differences between students within a diagnosed group”.

As previously discussed, a large contributor to the success of pupils learning (within the constructivist perspective) is the freedom for pupils to socialise – which satiates their desire. However, facilitating this style of classroom is quite difficult as I would need to balance discipline to ensure conversations and activities remain on task but when fine-tuned, the benefits are evident across the range of learners. I will certainly be willing to adopt a more facilitative and social classroom management approach in my NQT year.

Ultimately, I appreciate that differentiation is an intrinsic part of teaching. I must differentiate all the time. Differentiation is not a large planned strategy that I implement in a lesson. It is several strategies that I invoke collectively such as where pupils sit, how pupils access work, what supporting resources are provided – it is the unison of practices that collectively form a well-differentiated lesson and enable the progress of all learners within a classroom.

Conclusion

The study achieved intended outcomes but not as dramatically as anticipated. The differentiation strategy can aid pupil motivation (making challenges more accessible) but the strategy alone does not necessarily motivate pupils intrinsically. A good differentiation strategy alone does not compensate for other weaker areas, but all teaching techniques derived from teaching standards (e.g. behaviour management) must work together; to deliver a complete learning environment, which is only as strong as the weakest strategy employed.

It is evident that a strategy may benefit only a sub-group of pupils e.g. only aiding in the progress of LA pupils or a specific gender. Some strategies may even ostracise pupils (e.g. kinaesthetic activity may be difficult for pupils with reduced motor control). It is unlikely then that any strategy will be an educational ‘elixir’ for pupil progress, but success lies within deploying a range of different strategies as appropriate to the classroom.

Despite the academic rigour underpinning Education, it appears to share a trait with other industries: Education can be subject to fads. The mere suggestion of a potentially beneficial strategy can invoke its zealous adoption in classrooms. I naively expected that this strategy would be the ‘answer’ to pupil progress and a class of confident independent social coders would emerge. Perhaps ‘confirmation bias’ meant I had presupposed ‘paired programming’ would work perfectly. My Web searches were “Why does paired programming work well”, “what are the benefits of paired-programming” and had simply neglected to look at any issues associated with the strategy or consider evidence against.

Paired-programming works well in industry and where programmers team on large coding projects or for mature programmers. It worked to some degree in a secondary classroom but to be truly effective, other differentiation strategies were still required as well as aspects such as motivation, modelling, scaffolding, confidence building and behaviour management. There were drawbacks to paired programming – it is difficult to measure individual contribution in the pair and it is hard to police to balance freedom and creativity with producing outcomes.

Although hard to quantify and then, arguably, evidence; the project had a positive impact on the pupils. The ‘a culture of mistakes’ where pupils can confidently learn is valuable. Pupils exposed to the mistakes of other pupils (either partners or other pairs) allows them to ‘forgive’ their and learn from their own mistakes. I think the process had a positive affect on my host teacher (the only CS teacher in the faculty) as he was able to witness a different approach to learning instead of the more ‘traditional’ approach – presenting a concept, presenting code and then setting various exercises to encourage mastery. In this approach, coding was fun, pupils gained confidence with the support of a partner, their willingness to attempt unprecedented activities was evident – this itself aided motivation.

I concur with the statement “By far the greatest challenge to teachers is to ensure progression in the learning of all pupils in their class” – Capel, S., Leask, M., & Younie, S. (2016, p. 221). This strategy had provided progress to many pupils but on a personal-level, I was left feeling unsatisfied because progress was not made by all pupils.

I would re-attempt paired-programming in future classes and with different year-groups as well to have a firmer grasp of when it is can be more appropriately adopted. I would enjoy being more objective in my assessment of its usage as well. More importantly, in my NQT year, I now have a willingness to trial strategies (particularly for differentiation) and should be more objective in my preliminary selection and subsequent evaluation of such strategies.

References

Baker, T., Evers, G., & Brock, R. (2017). Targeted teaching : strategies for secondary teaching . London: Sage.

Capel, S., Leask, M., & Younie, S. (2016). Learning to teach in the secondary school : a companion to school experience. (Seventh edition). Abingdon: Routledge.

Department for Education (2011) Teacher’s Standards Retrieved from https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/665520/Teachers__Standards.pdf

Hanks, B., Fitzgerald, S., Mccauley, R., Murphy, L., & Zander, C. (2011). Pair programming in education: a literature review. Computer Science Education. Norwood: Taylor & Francis Ltd. https://doi.org/10.1080/08993408.2011.579808

Hramiak, A., & Hudson, T. (2011). Understanding learning and teaching in secondary schools. Harlow: Longman.

Hopkins, D. (2014). A teacher’s guide to classroom research (Fifth edition.). Milton Keynes: Open University Press.

Lawson, T. (2012). Reflective teaching and learning in the secondary school (2nd ed.). London: SAGE.

Lau, W. (2018). Teaching computing in secondary schools : a practical handbook . Abingdon: Routledge.

Lee, Y. (2011). Empowering Teachers to Create Educational Software: A Constructivist Approach Utilizing Etoys, Pair Programming and Cognitive Apprenticeship. Computers & Education, 56(2), 527–538. https://doi.org/10.1016/j.compedu.2010.09.018

Muijs, D., & Reynolds, D. (2018). Effective teaching : evidence and practice (Fourth edition.). Los Angeles: SAGE.

Pritchard, A. (2018). Ways of learning : learning theories and learning styles in the classroom (Fourth edition.). London, [England] ;: Routledge.

Sentance, S., Barendsen, E., & Schulte, C. (2018). Computer science education: perspectives on teaching and learning in school . London: Bloomsbury Academic.

Williams, L. (2001). Integrating pair programming into a software development process. Proceedings of the 14th conference on software engineering education and training, IEEE Computer Society (pp. 27–36). https://ieeexplore-ieee-org.hallam.idm.oclc.org/document/913816 Wilson, E . School-Based Research : a Guide for Education Students . Third edition. Los Angeles: SAGE, 2017. Print.