#CSEd #PGCE #Education #final # Why should all pupils learn to program? ## How should programming be taught to ensure all succeed? --- *Will Berard, PGCE (Secondary Computing), University of Roehampton* **Preface (2024):** Looking back on this first PGCE assignment, three years later, is interesting. A couple of points: - After the PGCE year, the realities of teaching closed in, and I never returned to any of the literature. For shame. - This meant I've not checked the evidence on self-paced online coding learning platforms (shout out to [Turinglab](https://www.turinglab.co.uk/) ) of which there are now many. I've found those to have the best cost/benefit at KS3, less so higher up (though I have found [Grok Academy](https://groklearning.com/) useful at KS4). - I'm suspect of my claim that "in a previous paper (2015), \[Guzdial\] argues \[mass computing literacy\] is more likely to be reached by *formal* means than *informal* ones: school and universities rather than clubs and tutorials." I've seen students achieve amazing things with "YouTube and ChatGPT" (the shrugged answer of a Year 10 boy when I asked him how he wrote a fully functional chess game in Python when they were barely using lists) so I went to look for this in the text, but couldn't find it. I must have gotten my referencing mixed up, I expect it's in Guzdial (2016). - The vast majority of the research on teaching programming is done on undergrads. Even at the time, I was cautious not to generalise to younger learners, but, having since met some, I would be tempted to disregard all sources pertaining to contexts beyond secondary - perhaps even beyond secondary education in a W.E.I.R.D. country. - Whether all student should still *learn to program* is a re-opened question now that knowing how to program is not a pre-requisite to the production of (more and more advanced) code, thanks to Large Language Models. Ditto that of the best way to teach those who should still learn to code, given the explosion of LLM-backed tools in education. [Further Research is Needed](https://en.wikipedia.org/wiki/Further_research_is_needed), ideally before the adoption at scale of AI EdTech products with slim evidential backing. # Introduction (Why?) The notion that all schoolchildren should learn programming has become salient in the past ten years (Royal Society, 2012, 2017; DfE, 2014; OCR, 2020), but is, in fact, a twentieth century idea. Albion (2016) refers to a 'second coming of coding', noting that, from the late 70s onwards, many schoolchildren were programming in primary school. The philosophy behind that first coming is best presented by Papert's *Mindstorms* (1980): programming is a tool (not an end in itself!) to make the abstract concrete. It lets children build '*microworlds'*: powerful representations of otherwise abstract ideas. The child teaches the computer, and in doing so teaches herself. This vision of programming as a *means to* -- as opposed to an *object of -* knowledge construction has made constructivism 'extremely influential in the fields of science and mathematics education, but not in computer science' (Ben-Ari, 1998). Although a strong answer to the 'why', this idea does not justify the 'all': if programming is a tool to improve internal constructed representations of (non-programming) knowledge, it will help *some*, but it is no sufficient reason to inflict it upon *all.* In the second coming, Schulte (2013) does not draw educational conclusions from characteristics of programming as a practice, something for which evidence is sometimes lacking (Tedre and Denning, 2016); instead, he starts with a 'generally shared understanding of the goals of education'[^1], and assesses the value of programming against them. He concludes that programming fulfils six distinct educational goals: '(tool) building / participation', 'expression / self-development', and 'thinking / coping with affordance'. This outside-in approach makes it difficult to find fault with Schulte's conclusions when it comes to addressing the '*all*' in our question. By starting with (as-near-as) 'universal' education goals, his method guarantees that the objectives he concludes programming fulfils applies to *all* *pupils.* Among Guzdial's (2016) reasons to seek a 'Computing for Everyone' is 'pupils learning about their world', the very philosophy that inspires the UK's Computing at School (CaS) working group: the world is now computational, and pupils need to study computing because it 'explores *foundational principles and ideas*' (CaS, 2010), to the same extent as mathematics, physics, biology or history. Another of Guzdial's reasons, more relevant to programming, is mass computational literacy; in a previous paper (2015), he argues it is more likely to be reached by *formal* means than *informal* ones: school and universities rather than clubs and tutorials. This speaks directly to the 'pupils' in our question. ![[napkin-selection.png]] Guzdial, like Schulte, also makes the case for 'broadening participation', which uses the 'all' of the question to answer its 'why'. Nielsen and colleagues (2017) have shown that increased diversity in science fields leads to better outcomes across many dimensions; increasing the participation of historically under-represented groups starts at school. For me, it is not the sole reason for all pupils to learn to program, but it is certainly enough of one to answer the question even in the absence of the others outlined above. # Literature Review (How?) > 'Make your learners feel that they can be a programmer, and they just might become one.' \-- (Brown and Wilson, 2018) Having read *actual* literature reviews of computing education, I hesitate to even label what comes next as such. I urge the reader to think of it simply as a small sample of tools and techniques I have been able (or intending) to apply in the classroom. ## Subgoals Labelled subgoals are a scaffolding technique that isn't specific to programming: Catrambone (1998) has shown they can reduce the cognitive load borne by the student, leading to improved problem-solving. Cognitive load management is a key aspect of successful teaching in any subject (Education Endowment Foundation, 2021), and programming, as a task, can be cognitively taxing to the extreme, making cognitive load theory doubly relevant to the teaching of programming (Robins, Margulieux and Morrison, 2019). Margulieux builds on Catrambone's work, investigating the value of subgoal labelling in the specific context of programming tasks, and finds a marked effect on problem-solving skills (Margulieux, Catrambone and Guzdial, 2016). Margulieux and Catrambone collaborated further (2020), in a study where the learners were asked to define the subgoal labels themselves, forcing them to organise information mentally through self-explanation (Wylie and Chi, 2014, cited in Margulieux and Catrambone, 2020). Not only do learners in the self-labelled subgoals group perform better at problem-solving than those facing the unscaffolded task, but they also outperform learners being given the same task, scaffolded with expert-constructed labels -- even when the learners labels were of 'poor quality' (Margulieux and Catrambone, 2020). Those findings confirm a constructivist view of programming knowledge, whereby the learner having a functional internal model (regardless of its absolute accuracy) of the knowledge at hand is a key factor in problem-solving. ## Pair Programming Pair programming (PP) is a software industry technique whose name was coined during the emergence of Extreme Programming (XP) and agile development, but whose practice predates them by decades. Developers work in pairs, with the driver handling keyboard input, syntax, style, and low-level, tactical decisions, and the navigator concerning themselves with design, architecture, and strategic decisions. In a professional setting, Hannay and colleagues (2009) find small effects on code quality in a meta-analysis with n=1160, and conclude PP is 'not uniformly beneficial \[or\] effective'. Conversely, the specific benefits of PP in education have been known for a long time (McDowell et Al., 2003). Tsai and colleagues have found PP decreases cognitive load compared to solo programming (2015). More significant perhaps is their finding that 'distributed pair programming' (having the pair use different computers and collaborate remotely) shows no such advantage over solo programming. This confirms the view that the very use of the computer adds to germane cognitive load, which is reduced in 'traditional' PP, but not in distributed pair programming. Interested as I am in broadening participation in programming, and aware that girls learn more socially than boys, I surmised they would particularly benefit from pair programming. Indeed, Liebenberg, Mentz and Breed (2012) find PP increases secondary school girls' self-reported enjoyment of programming. Werner and Denning (2009) find it motivates middle school girls to persist and increase their confidence, above and beyond the increase in confidence observed amongst boys. A more recent study from China, done with primary schoolchildren, shows a more nuanced picture, whereby girls benefit in programming skills only if paired with boys, and do not receive an increase in confidence, when boys do (Wei et Al., 2020). This may be a factor of the age of the pupils, the different cultural context, or simply of the limits of the quality of evidence in education research: after all, Hao and colleagues (2019) find that the replication rate in computer science education studies is less than 2.5% (n=22,269). ## Block-based languages First amongst block-based languages is Scratch, from a team at the MIT Media Lab featuring several of Papert's former students, and the first 'sneak preview' paper features the techno-utopianism that characterises *Mindstorms*. It makes the 'working hypothesis' that children will 'develop technological fluency, mathematical and problem-solving skills, and a justifiable self-confidence that serves them well in the wider spheres of their lives' (Maloney et Al., 2004) -- no less. Questionable as the claim of its transfer to 'wider spheres' may be (Tedre and Denning, 2016), the effect on self-confidence does exist. Tsai (2019) finds that using visual programming languages (VPLs) (AppInventor2, Scratch) gives students a better grasp of basic programming concepts, especially for students with low or moderate self-efficacy. Additionally, learners' self-efficacy itself is improved by the use of VPLs (Yukselturk & Altiok, 2017, cited in Tsai, 2019) The mechanism by which those outcomes are reached may be emotional more than cognitive: a Taiwanese study of 175 pupils of 10th grade found that block-based programming increased 'playfulness and enjoyment' and decreased learning anxiety, particularly amongst low and medium achievers (Hsu and Hwang, 2021).The remarkable feature of block languages is the ease of achieving creative goals, making the ensuing gain in self-efficacy within reach of pupils with low self-efficacy. It pays to think about *which* children will tend to identify with low self-efficacy in programming tasks. Bayer (1990) finds that females consistently rate themselves lower in self-efficacy on 'masculine tasks'. Thirty years later, Syzmanowicz and Furnham's (2011) meta-analysis of gender differences in self-estimates of intelligence still report the largest effect size (.44) for 'mathematical' intelligence. It is no surprise that in Scratch, even in its early days, was amongst the programs used in studies finding girls engage more with programming tasks through visual coding, (Zimmerman and Sprung, 2008; Craig and Horton, 2009). The role of Scratch in broadening participation was identified early on by the Scratch team in a study at an inner-city computer club 90% of whose attendees had never been in a computing class at school (Maloney et Al., 2008). They also noted the use of Scratch allowed the children to be mentored by 'liberal arts majors' with no programming experience, the participation broadening effect starting with the adults. ## Live Coding Writing code in front of the class (rather than commenting on static code examples) is a powerful modelling technique, as the teacher thinks aloud through the problem, encounters and overcomes issues, and showcases the process of programming, not just the resulting program. Rubin (2013) finds that live coding only leads to a statistically significant improvement in outcomes on programming projects -- but not in assignments or exams. In fact, his test group (n=78) had worse exam results than the control (n=68), leading the overall results of test group to be worse. This may say more about the weighing of the final grade and the fact exams are a poor predictor of programming performance than it does about live coding. Less ambiguous is Rubin's finding that students in both groups report finding live coding more educational, and prefering it over other teaching methods, with this preference larger in the test group. Raj and colleagues (2018) delve into this preference, identifying by questionnaires (n=103) that live coding helps students understand programming, and in particular debugging, by exposing them to good programming practices. Gaspar and Langevin (2007) propose combining instructor-led live coding (both performed in person and in a flipped format using recorded videos) and student-led live coding, whereby one of the student writes code on the big screen, with others being given the opportunity to assist; and 'test-driven pair programming', where the programming is done solo, each half of the pair then swapping code and writing a test harness, competing to break each other's code. The authors' aim is to make the learning active and student-centred, to restore agency, intention and thoughtfulness in the work of the students, to move them away from understanding-free code re-use and trial-and-error 'random programming'. The papers cited all study university courses, where the lectures are separated from the tutorials and practicals. In the school classroom, even a teacher using static code example during the didactic part(s) of the lesson will likely model the writing of code in the activity part, and the students would write code along or immediately after. Raj and colleagues (2018) find the benefits of live coding magnified when the students can practice writing code along the instructor, making live coding ideally suited to a cognitive apprenticeship model. Black (2006) reminds us that the crux of this model is the phases that come after the teacher modelling: coaching and scaffolding; during those stages the execution-and-feedback loop between instructor and student is ideally suited to computer programming. Black's research sources are also conducted on adults: Snyder (2000, cited in Black, 2006) finds 'better complex problem-solving skills' than in the control (text-based instruction) group, and Novemsky's (2003, cited in Black, 2006) study is also in higher education. The ideas Black considers, with the view of applying them as a novel intervention to American undergraduates of the mid-00s, seem to be the de-facto norm for British secondary school pupils of the 20s; the improvements in programming languages and IDEs have certainly made live coding more accessible to both contexts. # Reflection(s) (Whence?) I learnt to program as a child, around the age of six, in a fashion fitting the stereotypical narrative of what Ames (2019) calls the '*technically precocious boy'*. I was taught BASIC in the late 1980s by my father, an agronomical engineer and subclinical computer enthusiast, who brought ome a Toshiba 'laptop'[^2] from his work. My father had learnt programming *for* engineering - as opposed to programming *as* engineering; his job did not have a great call for computing, but should the need arise, he would be the early adopter, the person to go and see. He had the time, inclination, and access to technology to enable my learning to program; not everyone does. Later, at school, in year 4, we spent a couple of hours in the computer room, where my BASIC skills impressed the teacher. Those were the sole few hours spent with computers in five years of primary school, at the behest of this year four teacher who was a technology enthusiast. He was also the only male teacher I had in primary, even in the whole school. Cafolla (1987) finds that both mathematical and verbal reasoning abilities to be predictors of programming ability. I knew the concepts of sequence, iteration and selection before I knew what a verb was or how to do long division -- my programming ability, such as it was, turned out to be a predictor of my reasoning abilities. # Analysis (Wherefore?) The literature review above concerns itself with techniques and tools either specific to programming, or whose specific application to it is the object of study; but, as significant as their effects may be, they must be considered against the effects of other, general pedagogical principles. To teach programming so that all succeed, one must first teach, and hopefully teach well. Teach so well in fact that *all* have a chance at *success*. This involves principles common to all teaching: even if the programming-specific concerns are where the rubber meets the road, there still needs to be a car above both, hopefully attached to the former. Robert Coe and colleagues (2014) find that the teacher's own subject knowledge comes first in the components that make 'great teaching'. This is particularly fortuitous in my case when it comes to programming. Second is the quality of instruction, which is where the ideas we have considered above find their place, along with pedagogical techniques that are not specific to programming. Then come classroom management and climate, which are easy for experienced educators to take for granted but sit much closer to the front of the minds of trainee teachers such as me. So far, in my placement school, I have only taught programming to key stages 4 and 5. This is a disappointment, in that I would very much like to *increase participation* in programming, but the pupils to whom I am teaching it have all already chosen computing at either GCSE or A-level. That's a total cohort of 32, with one girl. Representation-wise, all hinges therefore on the three lessons of Python the year 9 classes are about to undergo. Sullivan and Bers (2018) note that girls tend to perform better on programming tasks if they have a female teacher; transitioning may not be a sacrifice I would be willing to make. I have often referred to the National Centre for Computing Education's twelve principles of computing pedagogy (Robinson, 2020), proudly displaying their poster in my classroom without a single student ever glancing at it. I have linked the two strategies outlined below to the NCCE's principle, which appear gratuitously capitalised and in italics. ## OOP: A semantic tsunami 'Semantic waves' is a term coined by Karl Maron (2013) that describes a change in 'semantic density' over the course of the lesson (or even a teaching unit): start with an abstract, theoretical approach, exposing the key concepts with technical language, then go down the 'semantic slope' towards concrete activities illustrating the ideas, explained in everyday language, before going back up the slope, re-introducing the thus contextualised concepts, which will now be within the grasp of the students. Semantic waves underly the NCCE's *Unpack, Unplug, Repack* principles, but it also relates to *Lead With Concepts* and *Structure Lessons*. I applied those principles in teaching Object-Oriented Programming to my year 12 class (n=5). OOP is by no means an easy paradigm to grasp: I have been keen on repeating to my pupils that it took me two university semesters to fully grok its implications. The first difficulty with OOP is its concept-heaviness, which makes semantic waves ideal, or simply *necessary*, to its teaching. The OOP concepts are nearly homoeomorphic to real-life concepts, with just enough difference to induce confusion. This makes the downslope of unpacking easy to follow, but it does require careful navigation to avoid misconceptions. The second difficulty, which in hindsight I faced at university, is that the benefits of OOP, indeed its *point* are not immediately perceptible to learners. OOP and its associated concepts are all *in fine* means of managing program (and programming) complexity, and many learners will not have experienced the difficulties and frustrations of handling large, complex projects involving several developers. ![[OOP Concept Map.png]] Figure 1 - a concept map for OOP - https://skat.ihmc.us/ Our unit for the teaching of OOP covered a half-term. By way of introduction, we spent a lesson learning about scope, local and global variables. I selected a public-domain concept map of OOP (Fig. 1), showing all the concept we were going to cover. I introduced it early -- at the end of the introduction lesson on scope, as a preview, and referred to frequently. I deliberately chose a rather intimidating one, to heighten the sense of mastery the pupils got from understanding it more and more. By the end of the unit, the pupils were drawing their own concept maps, not identical to the one they'd seen, but equally valid. It was like witnessing constructivism in action. I introduced one concept every week or so: instantiation, encapsulation, inheritance then polymorphism. Each lesson in the MTP would follow a similar structure: 5 minutes of quizzing the pupils on the concepts learned so far and their definitions (the pupils were encouraged to create their own revision list of keywords and definition, and edit it during those sessions) -- an opportunity to *Challenge Misconceptions*; 10 or so minutes of lecturing, introducing the new concepts in the abstract, relating it to prior concepts, with (out-of-context) static examples focussed on the relevant Python syntax; then, going down the slope, with practical activities derived from real-world examples (e.g. a Vehicle class, then a Car and Lorry class inheriting it) -- often done in pairs or even, once the class was acquainted with UML standards, on paper -- all structured with labelled subgoals. Finally, the re-packing, up-the-slope phase, in which I have found it valuable to ask the pupils to comment their own code explaining which OOP concepts were at play in the code they had just written. I would also use the plenary for more definition quizzing, looking for evidence of progress amongst those who didn't do so well in the starter drill. ## The Pernicious Perils of Pair Programming in Practice Pair programming is foremost a professional practice, not an educational one; in the industry, its application aims at maximising the quality of output, with no concern of the quality of the mental knowledge schemata of the programmers: this is the first, most obvious difference. There are, however, more insidious ones: pair programming requires a certain amount of discipline and self-regulation, and, as similar as the typical software developer and the typical teenager are in many ways, this is one where the difference is crucial to the actual execution of pair programming. This was my first explanation for the great difficulty of getting my year 10 pupils (n=13) to pair program, something that went, as it were, *pair-shaped*. Hindsight has made me realise this is an unkind interpretation: pair programming also requires a baseline competency in programming, and more specifically a degree of comfort with the syntax of the language; said pupils having a grand total of six weeks of Python experience, it was not an appropriate pedagogical technique. Still, there is no such thing as a failed experiment, we learn just as much from those. Much as the programmers understanding of the code is not the aim of pair programming, it is a necessary side effect of a quality output, which is why, in the industry, it is reserved for medium to large tasks, where the pair will have time to acquaint themselves with the existing code, or in the rare case of a completely greenfield project, the problem to be solved (Stephens and Rosenberg, 2008). I found pair-programming to be much more appropriate to OOP mini-projects (spanning 3-ish weeks) for year 12. A particularly joyful moment was seeing a navigator open their own machine to take text notes. A danger, in the same context, was that without forced switching, pairs could set with always the same navigator and the same driver; this isn't a problem in a professional context, but in an educational one, results in a missed opportunity to practice the other side. A static pair has advantages: year 11 pupils (n=14) were paired using assessment data, high-ability navigator to low-ability driver, on a short (1 lesson) revision task on bubble and insert sorts in Python. Predictably, the navigator instructed the driver, sometimes to the point of dictating code, but it forced them to articulate the algorithms and their underlying logic. This moment of *Work*\[ing\] *Together* was the *Repack*ing stage. The semantic wave in this lesson started with my modelling the implementation of the algorithms, (*Concepts First* with a side of live coding to *Model Everything*) after which we *Unpack*ed and *Ma\[d\]e Concrete* by having the pupils stand up, form a line, and sort themselves by first name -- using a chair on casters to represent the progress of the iterator. Next term, I plan on using Gaspar and Langevin's (2007, 2012) poorly named 'test-driven pair programming', where each student tries to make the other's code break (the pdf of their paper is titled 'antagonistic debugging' -- a much better term[^3] that doesn't appear in the text itself!). Their frustrations with the lack of intentionality in the programming practice of their students resonated with my classroom experience, and the constructivist, learner-centred, active learning philosophy of their approach feels even better suited to secondary education than higher education, where they applied it. # Conclusion (Whither?) The excellent literature review on introductory programming by Luxton-Reilly and colleagues (2018) opens with the insight that 'teaching students to program is a complex process', then quotes prior work (Robins et Al., 2003, cited in Luxton-Reilly et Al., 2018) itself observing in its opening sentence that 'learning to program is hard'. These are the giants on whose shoulder I stand to make my own humble contribution: *learning to teach to program is complex and hard.* The difficulty my pupils experience in learning to code is matched by my own in learning to teach them to do so, and the wide varieties of possible approaches, techniques, tools and their combinations (of which this essay only presents a very small selection) induces significant complexity. Each learning programmer relies on their own individual knowledge schema and will respond differently to specific learning approaches -- and each teacher will be more or less apt in delivering them. Exploring some of the possible options was an insightful exercise that inspired my practice, however, as to the question of how to teach so all succeed, perhaps the answer is to be found closer to the general principles of quality teaching, from Bloom and colleagues (1956) to Rosenshine (2012) than to any programming-specific pedagogy. Guzdial (2016) argues that 'a computer is more like a printing press than a calculator'; It is a powerful metaphor, that elegantly runs through his presentations of the reasons for a 'computing for all': both result(ed) in the creation of new roles and whole new industries, serve(d) as McLuhanian *amplifiers* of communication and production, and both call(ed) for their own mass literacy. We can extend the analogy further: in between the printing press and mass literacy, the Protestant reformation, enabled by the former, sought to make the word of God accessible, in the vernacular, to anyone willing to read it. Python, now running in a browser, seems to be doing the same thing with programming languages, being the English to Java's Latin, C's Greek and LISP's Hebrew. It is a grandiose analogy, but programming has a long history of cloaking itself in mysticism: we speak of 'wizards', we quote *The Zen of Python* (Peters,1999) or *The Codeless Code* (Qi, 2010). We sometimes even utter the monstrous portmanteau automagically'. There is something of the numinous in the feeling that comes from 'bending a machine to your will' (an actual quote from a year 10 pupil). If all pupils learn to program, they too can reclaim their relationship with the god(s) of technology, without the intercession of the (typically white, male,American and inevitably hoodie-wearing) technological clergy. This is what the 'second coming' could herald. # References Albion, P.R., (2016) If this is the second coming of coding will there be rapture or rejection?. In *Australian Council for Computers in Education 2016 Conference Refereed Proceedings* (pp. 1-8). Queensland Society for Information Technology in Education (QSITE) on behalf of the Australian Council for Computers in Education. Ames, M.G., (2019) The charisma machine: The life, death, and legacy of One Laptop per Child. Mit Press. Ben-Ari, M. (1998*). Constructivism in computer science education*. ACM SIGCSE bulletin. 30 No 1, pp. 257-261. ACM. Black, T. R. (2006). Helping novice programming students succeed. *Journal of Computing Sciences in Colleges*, *22*(2), 109-114. Bloom, B., Engelhart, M., Furst, E., Hill, W., & Krathwohl, D. (1956). *Taxonomy of educational objectives: the classification of educational goals*. Handbook I: cognitive domain. Brown NCC, Wilson G (2018) Ten quick tips for teaching programming. PLoS Comput Biol 14(4): e1006023. <https://doi.org/10.1371/journal.pcbi.1006023> Cafolla, R. (1987). Piagetian Formal Operations and other Cognitive Correlates of Achievement in Computer Programming. *Journal of Educational Technology Systems*, *16*(1), 45--55. Catrambone, R. (1998) The subgoal learning model: Creating better examples so that students can solve novel problems. *Journal of Experimental Psychology*: General,127, 355--376. Craig, M., & Horton, D. (2009, March). Gr8 designs for Gr8 girls: a middle-school program and its evaluation. In *Proceedings of the 40th ACM technical symposium on Computer Science education* (pp. 221-225). Coe, R., Aloisi, C., Higgins, S., & Major, L. E. (2014). What makes great teaching? review of the underpinning research. DfE, (2014) *The national curriculum in England: Framework document.* Available at: [https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment\_ data/file/381344/Master_final_national_curriculum_28_Nov.pdf](https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_%20data/file/381344/Master_final_national_curriculum_28_Nov.pdf) Accessed: Oct 2021 Education Endowment Foundation (2021) *Cognitive Science Approaches in the Classroom: A Review of the Evidence* London: EEF Gaspar, A., & Langevin, S. (2007, October). Restoring\" coding with intention\" in introductory programming courses. In *Proceedings of the 8th ACM SIGITE conference on Information technology education* (pp. 91-98). Gaspar, A., & Langevin, S. (2012). An experience report on improving constructive alignment in an introduction to programming. In Journal of Computing Sciences in Colleges, 28(2), 132-140. Guzdial, M., (2015) Plain talk on computing education. *Communications of the ACM*, *58*(8), pp.10-11. Guzdial, M. (2016) *Learner-centered design of computing education : research on computing for everyone*. San Rafael, California: Morgan & Claypool (Synthesis lectures on human-centered informatics, #33). Hannay, J. E., Dybå, T., Arisholm, E., & Sjøberg, D. I. (2009). The effectiveness of pair programming: A meta-analysis. *Information and software technology*, *51*(7), 1110-1122. Hao, Q. et Al. (2019) A systematic investigation of replications in computing education research. *ACM Transactions on Computing Education 19.* doi:10.1145/3345328 Hsu, TC., Hwang, GJ. (2021) Interaction of visual interface and academic levels with young students' anxiety, playfulness, and enjoyment in programming for robot control. *Univ Access Inf Soc* . Liebenberg, J., Mentz, E. and Breed B., (2012) Pair programming and secondary school girls' enjoyment of programming and the subject Information Technology (IT), *Computer Science Education*, 22:3, 219-236. Luxton-Reilly, A., Albluwi, I., Becker, B.A., Giannakos, M., Kumar, A.N., Ott, L., Paterson, J., Scott, M.J., Sheard, J. and Szabo, C., (2018) Introductory programming: a systematic literature review. In *Proceedings Companion of the 23rd Annual ACM Conference on Innovation and Technology in Computer Science Education* (pp. 55-106). Maloney, J., Burd, L., Kafai, Y., Rusk, N., Silverman, B., & Resnick, M. (2004, January). Scratch: a sneak preview \[education\]. In Proceedings. Second International Conference on Creating, Connecting and Collaborating through Computing, 2004. (pp. 104-109). IEEE. Maloney, J. H., Peppler, K., Kafai, Y., Resnick, M., & Rusk, N. (2008, March). Programming by choice: urban youth learning programming with scratch. In *Proceedings of the 39th SIGCSE technical symposium on Computer science education* (pp. 367-371). Margulieux, L.E., Catrambone, R. and Guzdial, M., (2016) Employing subgoals in computer programming education. *Computer Science Education*, *26*(1), pp.44-67. Margulieux, L.E. and Catrambone, R., (2021) Scaffolding problem solving with learners' own self explanations of subgoals. *Journal of Computing in Higher Education*, pp.1-25. Maton, K. (2013). Making semantic waves: A key to cumulative knowledge-building. *Linguistics and education*, *24*(1), 8-22. McDowell, C., Hanks, B. and Werner, L., (2003) June. Experimenting with pair programming in the classroom. In Proceedings of the 8th annual conference on Innovation and technology in computer science education (pp. 60-64). Nielsen, M.W., Alegria, S., Börjeson, L., Etzkowitz, H., Falk-Krzesinski, H.J., Joshi, A., Leahey, E., Smith-Doerr, L., Woolley, A.W. and Schiebinger, L., 2017. Opinion: Gender diversity leads to better science. *Proceedings of the National Academy of Sciences*, *114*(8), pp.1740-1742. OCR, (2020) GCSE (9-1) *Computer Science J277 specification*. Papert, S. (1980) *Mindstorms: Children, computers and powerful ideas*. New York: Basic Books. Peyton-Jones, S., Humphreys, S. (2010) *Computing at school: A national working group*. Available at: <https://www.computingatschool.org.uk/data/uploads/Computing_at_School.pdf> (Accessed: Oct 2021) Raj, A. G. S., Patel, J. M., Halverson, R., & Halverson, E. R. (2018).Role of live-coding in learning introductory programming. In *Proceedings of the 18th Koli Calling International Conference on Computing Education Research* (pp. 1-8). Robins, A.V., Margulieux, L.E. and Morrison, B.B. (2019) Cognitive sciences for computing education. *Handbook of Computing Education Research*, pp.231-275. Robinson, J. (2020) [How we teach computing. NCCE](https://blog.teachcomputing.org/how-we-teach-computing).  Rosenshine, B. (2012). Principles of instruction: Research-based strategies that all teachers should know. *American educator*, *36*(1), 12. Royal Society, The (2012) *Shut down or restart? The way forward for computing in UK schools.* London: The Royal Society.  Royal Society, The (2017) *After the reboot: computing education in schools*. London: The Royal Society. Rubin, M. J. (2013, March). The effectiveness of live-coding to teach introductory programming. In *Proceeding of the 44th ACM technical symposium on Computer science education* (pp. 651-656). Schulte, C., 2013, November. Reflections on the role of programming in primary and secondary computing education. In *Proceedings of the 8th Workshop in Primary and Secondary Computing Education* (pp. 17-24). Stephens, M., & Rosenberg, D. (2008). Will pair programming really improve your project.  *Extreme programming refactored: the case against XP*, 6 (175-180). Apress. Sullivan, A. & Bers, M. (2018) The Impact of Teacher Gender on Girls' Performance on Programming Tasks in Early Elementary School. *Journal of Information Technology Education: Innovations in Practice, 17*(1), 153-162. Informing Science Institute Syzmanowicz, A., & Furnham, A. (2011). Gender differences in self-estimates of general, mathematical, spatial and verbal intelligence: Four meta analyses. *Learning and individual Differences, 21*(5), 493-504. Tedre, M. and Denning, P.J., (2016) The long quest for computational thinking. In *Proceedings of the 16th Koli Calling international conference on computing education research* (pp. 120-129). Tsai, C.Y., (2019) Improving students\' understanding of basic programming concepts through visual programming language: The role of self-efficacy. *Computers in Human Behavior*, *95*, pp.224-232. Tsai, C.Y., Yang, Y.F. and Chang, C.K., 2015, October. Cognitive load comparison of traditional and distributed pair programming on visual programming language. In *2015 International Conference of Educational Innovation through Technology (EITT)* (pp. 143-146). IEEE. Wei, X., Lin, L., Meng, N., Tan, W. and Kong, S.C., 2021. The effectiveness of partial pair programming on elementary school students' computational thinking skills and self-efficacy. *Computers & Education*, *160*, p.104023. Werner, L., Denning, J. (2009) Pair Programming in Middle School, *Journal of Research on Technology in Education*, 42:1, 29-49 [^1]: Taken from the United Nation's Convention on the Rights of the Child. [^2]: We know them in France as *portables*, a descriptor better suited to a machine that, at the time, no one would have considered perching on top of their lap. [^3]: I think I will settle on 'adversarial testing'.