In issue 8 of Hello World, I shared approaches to support pupils learning to read code. These included activities such as explaining, predicting, and tracing code, as well as live demonstrations with worked examples. Now, I’ll share some evidence-based approaches to support pupils who are learning to write their own code.
Fixing broken code
Children can find and fix common syntax, runtime, and logical errors in a piece of code. These errors might include missing brackets, missing speech marks, spelling mistakes, or missing variables declarations. The pupils can use the programming language’s translator to help find the errors by making the fixes and then running the code to test that it works.
Pupils will need to be made aware of how the errors present themselves – this is unique to the each translator and language and is not always obvious. For instance, in the default IDLE Python interpreter, it can be unclear where each error is located. Once pupils are familiar with a variety of common error messages, their causes, and how to fix them, they will be able to debug their own code with greater confidence and resilience. For extra challenge, debugging exercises can be carried out on paper, where there is no feedback from the translator.
Completion problems and pseudocode
We can give children partial solutions to complete. This has scope for a variety of levels of differentiation: as students progress, we can gradually leave out more code. Initially, students might be given most of the code but with parts of some statements missing. Then, we might remove statements completely. Next, we could remove several lines or complete blocks of code. Finally, we could remove all code and only provide comments to the pupils. If these comments are detailed enough, then this is like converting from pseudocode into working code.
At some point, children will need to plan their own code with pseudocode. It is difficult and does require the application of high-level computational thinking, where pupils perform abstraction and code design. A good approach is to get pupils to write the comments for each line of their program before they start coding.
Parson’s puzzles are problems in which the code is presented to children all jumbled up. The aim of the activity is to put the instructions into the correct order so that the whole code performs a specified task. Students do not need to be concerned with remembering syntax and can focus on logic and sequencing.
Modifying code and tinkering
Pupils can make modifications to a piece of code to adapt it for a slightly different purpose. Suppose we have a Scratch program that draws a square. We could ask pupils to modify the code to draw a triangle, pentagon and circle, for instance. We could extend pupils’ understanding and get them to find patterns in the relation between internal angles of a shape and the number of sides – we know finding patterns is a key aspect of computational thinking.
When pupils are modifying and completing code, a crib sheet that provides the basic syntax of constructs with some examples is a helpful aid. Pupils should be encouraged to organise any code that they write so that they can reuse the code in the future. The ability to recognise code that can be adapted to a new context is an important skill.
Pair programming and collaboration
Social constructivist approaches that use collaboration and pair programming, where two students work together on a single computer, can support students who are learning to write code. Within each pair, one student does the coding and the other observes, reviews and gives feedback. Students in each pair should regularly switch roles.
A tactical seating plan can be employed – with mixed attainment pairs, or pairs who can challenge each other. Even if each student is working independently on their own code, pupils should still be encouraged to collaborate with their neighbours. Collaborative approaches are often more effective than coding activities where pupils work in isolation without the support of their peers. Moreover, the cooperative and social nature of this approach has been shown to be particularly successful at engaging girls.
We cannot expect children to be able to write code before they have learned how to read code. Through careful planning of lessons and sequences of lessons, we can slowly remove the scaffolding as pupils gain greater independence as they progress from reading and using code, through modifying code to ultimately writing their own code to solve problems.
The great news is that the PRIMM (predict, run, investigate, modify, and make) model offers a framework around which we can plan our lessons. For each lesson episode within this structure, we can pick and mix from our assortment of techniques where pupils read code before they write code and gain increasing ownership of the code as they progress.
If we consistently apply scaffolded approaches for reading and writing code in our lessons, we can make the experience of learning to code for children a lot less intimidating, and a good deal more enjoyable.
Learn to program with The Little Book of Algorithms by William Lau, Hello World issue 9, pages 70–71
Will Grey's article in Hello World issue 8, Read before you write
Phil Bagge's article in Hello World issue 8, Cognitive load theory in the computing classroom
James Robinson's article in Hello World issue 8, Parson’s in practice
The trouble with pseudocode by John Woollard, Hello World issue 7, pages 40–41
Programming pedagogies: PRIMM by Oliver Quinlan, Hello World issue 5, page 25