How to support your students to write code

For many children writing code can be a daunting prospect. To help children learn to write code more easily we can use a range of scaffolded pedagogies. Initially these approaches take ownership of the code away from the students thereby giving them confidence to explore and experiment with the code.  Gradually as the students learn more and more we can reduce the amount of support until they are able to write their own programs independently.

 In a previous article we looked at approaches for supporting pupils to learn to read code that included activities such as explaining, predicting and tracing code, and live demonstrations with worked examples. This follow up article presents some approaches to support pupils with writing code.

Fixing broken code

Children can find and fix common syntax, runtime and logical errors in a piece of code. Errors might include missing brackets, missing speech marks, spelling mistakes and missing variables declarations, for instance. 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. However, pupils will need to be made aware of how the errors present themselves which will be idiosyncratic to the specific translator and language and are often not obvious. For instance, in the IDLE Python interpreter it can be unclear exactly where the error is located sometimes. Once pupils are familiar with a variety of common error messages, their causes and how to fix them we can expect the children to debug their own code with greater confidence and resilience. As an additional challenge, this exercise can be carried out on paper which is more difficult because there is no feedback from the translator.

 

Incomplete solutions and pseudocode

We can give children partial solutions to complete. This offers a variety of levels of differentiation according to how much code we choose to include. As students progress we can gradually leave out more and 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

Parson’s puzzles are problems in which the code is presented to children all jumbled up. The aim of the activity is to put each instruction 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 could make modifications to a piece of code so that it solves a similar problem to what it currently does. 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.  Moreover, 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. As 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. Moreover, pupils should be encouraged to organise any code that they write so that they can reuse the code in the future. Recognising where you have used similar code for a similar problem in the past to one you are currently working is an  important computational thinking skill and allows that code to be applied to a new context.

Pair programming and collaboration

Social constructivist approaches that use collaboration and pair programming, where two students work together on a single computer, can help pupils learn better. 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 plans can be employed with more and less able pupils sat next to each other, for instance. Even if each student is working independently on their own code, pupils should still be encouraged to collaborate with their neighbours. Collaborative approaches are 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 can engage girls more.

Planning lessons

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 whole experience of learning to code for children a lot less intimidating and a good deal more enjoyable.

Another version of this article was also published in:

Grey, W. How to support your students to write code, Issue 9, June 2019, p 62-63