jects 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,