Many teachers are able to recognise that students can find programming difficult and can identify the stages that novice school-aged programmers go through (cf Laura Sach’s blog article). However it is not as easy to specify a particular teaching strategy that will support learners in gaining confidence and a deep understanding of programming concepts (moving them from Laura’s “typewriter monkey” to a “code kitten”).
It is clear that more research is needed in this area, both by trying out interventions and measuring the impact and by finding out from experienced teachers what works in classrooms. A study I carried out in 2014 (Sentance & Czizmadia, 2016) revealed that teachers used strategies to support the learning of programming that included tracing, manipulation of code through debugging exercises, modifying bits of code, and generally providing lots of scaffolding to support students and reduce the exasperation and frustration of syntax errors (with text-based programming anyway).
There is research to support the usefulness of tracing code. In 2011 Lister describes that novices need to be able to trace code with more than 50% accuracy before they can begin to confidently write programs of their own (Lister, 2011). This follows on from years of research on this topic including a multi-institutional study published in 2004 showing that tracing code improves progaramming skills. Tracing is a practice that basically embodies a range of skills – a new programmer needs to be able to read, understand and explain how code works before being able to confidently write new code.
A particular approach I have warmed to over the years, and used in my own teaching, is the strategy used by Irene Lee and colleagues in a paper in 2011, called Use-Modify-Create. The idea behind this is that a learner runs (uses) an existing program to see what it does, then modifies it, and then when the understanding is pretty secure, is then able to create a new project of their own. The paper in which this is described is about Scratch projects and the Use-Modify-Create may be a great methodology to use in primary classrooms. It doesn’t contradict the Papert-style approach of learning by exploring, of tinkering and bricolage, because the modify stage involves playing around with the code to improve the functionality, but within the constraints of a well-designed original program. Our colleague Jane Waite has pointed out that the literacy curriculum is introduced by a similar process of imitate and innovate. Jane is also carrying out some really interesting work in this area around the levels of abstraction that are involved at each stage of the process.
When working in a text-based programming language with secondary-aged students, however, we may find that use-modify-create is not sufficient to generate a deep understanding of what is going on in the code because it may miss out the importance of Lister’s tracing for understanding. I have therefore tried to adapt the use-modify-create and after several variations and much discussion with colleagues, am currently proposing the following:
- Predict – given a working program, what do you think it will do? (at a high level of abstraction)
- Run – run it and test your prediction
- Investigate (Explain) – get into the nitty gritty. What does each line of code mean? (low level of abstraction). I’m not sure that explain is quite the right term.
- Modify – edit the program to make it do different things (high and low levels of abstraction)
- Make/Create/Design – design a new program that uses the same nitty gritty but that solves a new problem. I had always called this Create, and it is certainly creative but reading Tedre & Denning’s recent paper caused me to change this to Design, as a key computational thinking skill.
We are using the acronym PRIMM.
I feel this approach draws on both the scaffolding of Use-Modify-Create which has so much intuitive appeal but also embodies the evidence-based research of Lister and his group who have clearly shown that being able to read and explain programming code is c