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 crucial to having a secure knowledge.
This example activity (written for teacher CPD) exemplifies the way this works in sessions. Each lesson would start with an existing simple program that includes the teaching points for that lesson. The students need to try to work out how it works by looking at the code on paper or on the whiteboard and then write down what they think will happen. The code is then run so that they can test their prediction. There are then exercises that allow the students to explain how the code works. These could be questions about what a particular line of code would do, or a commenting activity, or a full tracing activity such as the TRACS system that Peter Donaldson and Quintin Cutts have set up in Scotland. The explain phase may vary according to the students. The important thing is that there is an understanding of what the piece of code does (high-level of abstraction) and a focus on understanding how and why it does it (low-level of abstraction). At this point, a range of exercises can be given to modify the code in small ways to add different functionality. This may also be student-led as well as exercise led to encourage some exploration.
The approach will involve some cycles – particularly around run-explain-modify which may happen over and over again.
There is an ever-present need to reduce syntax load for beginner programmers so that they can focus on the logic behind the program. Block-based (Scratch etc) and frame-based (Greenfoot’s stride) have this built in within the tool but with the need to use a text-based language at KS3 comes the need to cope with the language at a syntax level. Therefore this approach has been designed to include code to run and modify while confidence is being built up.
I would really like some feedback on this from teachers, and also to recruit some teachers who would be interested in trialling this out, with some supportive materials, in their classroom and participating in research interviews. These ideas come from a combination of my own practice, research in this area, and from talking to many other teachers about the way they teach programming. Many teachers may use this approach, or a variation of it, already but perhaps formalising and sharing it may help. Let me know if you are interested – you can find my email address on my King’s page.
Sue Sentance
Sue Sentance 