How to support your students to write code

By Will Grey. Posted

Learning to write code can be a challenge for students, but there are evidence-based approaches to support them

Will Grey shares some evidence-based approaches for teaching students to write code

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

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. 

A Python crib sheet that students can refer to when writing code

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

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.

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

Further reading

  • 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


Free - UK only

If you’re a UK-based teacher, volunteer, librarian or something in between, we'll send each issue free to your door.



Just want to read the free PDF? Get each new issue delivered straight to your inbox. No fuss and no spam.


From £6

If you are UK-based but not involved in education, you can get hard copies by buying back issues.