To address some of these issues, I developed the PRIMM approach to teaching programming. Following the approach, teachers can structure programming lessons with five elements: Predict, Run, Investigate, Modify, and Make.
Predict: Students discuss a program and predict what it might do, drawing or writing out what they think will be the output. At this level, the focus is on the function of the code.
Run: Students run the program so that they can test their prediction and discuss in class.
Investigate: The teacher provides a range of activities to explore the structure of the code; this involves activities such as tracing, explaining, annotating, and debugging.
Modify: Students edit the program to change its functionality via a sequence of increasingly challenging exercises; the transfer of ownership moves from the code being ‘not mine’ to ‘partly mine’ as students gain confidence by extending the function of the code.
Make: Students design a new program that uses the same structures but solves a new problem (e.g. has a new function).
There are three key principles underlying PRIMM, all emerging from research in computer programming education. The first is that students should read before they write. The excitement of writing a new program and creating something that works means we don’t spend enough time reading and learning from simple, well-written programs. In literacy, we learn to read first, and at a level beyond what we can write. We learn from reading examples of the written word. The same can apply to programming. There is a substantial body of research around tracing and reading programs that has shown that reading first is beneficial for novice programmers.
Secondly, students should talk about their programs. This works at three levels: we need to find the right language or terminology to use to articulate our understanding; we are helped by verbalising what may be a complete mishmash in our head, and we also share in the creation of understanding through dialogue with others.
Finally, students should start with code that isn’t their own. Using a starter program, written by somebody else who takes responsibility for any bugs, reduces the emotional strain caused by our programs failing. We often hear that students in computing should build up resilience because their programs will always fail. I believe we don’t need to accept this, and that by providing code written by somebody else as a stepping stone we protect our students from the disappointment, anxiety, and frustration that we’ve all felt when our programs fail. This is especially important for young learners, but applies to anyone learning to code.
The Investigate phase of PRIMM gives us the opportunity to devise creative activities and ask insightful questions about a program. In this way we are moving from thinking about what the code does to how it does it. Armed with this knowledge, learners should be more confident to tackle their own programs.
In the Investigate phase, we often use a range of activities. Here are some examples, numbered so that we can refer to them later:
Ask the question, “What would happen if those two lines were the other way round?”
Ask the question, “What would happen if the input to the program was ____ ?”
Ask students to draw on the program to identify blocks of code or type of construct.
Draw the flow of control on the program showing what line is executed when a loop is exited, for example.
Ask students to identify the scope of a variable.
Identify the purpose of a single statement.
These activities can be varied and added to, and many teachers have been very innovative in how they ask questions of students that really get them thinking. However, we can fall into the trap of asking the same questions about the code all the time, and we can then find that we are not really supporting understanding as much as we could.
The Block Model
So this is where the Block Model comes into play! The Block Model was created by Carsten Schulte in 2008 and gives us some insight into the various granularities of skills that new programmers need. The Block Model is a grid with two axes — one showing the size of the programming element under consideration, and the other the distinction between the structure of the program, the execution of the program, and the function of the program. Last year, Cruz Izu and Carsten Schulte led research that mapped classroom activities using the model, leading me to link the idea to PRIMM. The Block Model ensures that the Investigation stage of PRIMM addresses a range of skills required to thoroughly understand a program.
From atoms to macro structure
At the bottom of the Block Model is the Atom: a single language element such as a variable, or the word ‘if’. The top is the least granular end of the scale, where we have the macro structure: the whole program. Between these two extremes we have blocks of code, and relationships between blocks of code. Using the Block Model enables us to reflect on whether our questioning spans all these four levels.
Structure versus function
When we ask students to predict, we ask them what a program might do. This relates to the function of the program or piece of code. In contrast, the structure of the program relates to the syntax and how the program is constructed. For example, we might be using the keyword ‘for’ in Python to indicate the beginning of a loop. There is one more column: program execution. This relates to the flow of control and values of variables when the program runs, or what code is called when.
Twelve zones of understanding
Looking at the Block Model in its entirety, we can see that it gives us twelve zones of program comprehension. So the question is, can we devise activities or ask questions about a program that develop knowledge in each of these twelve zones? It’s a challenge to do this, but if we don’t, we may not totally support students’ full understanding of the program.
If we take as an example some of the questions and activities I outlined above, we could start to put some of them into the Block Model and identify the gaps. The exact placement of each task in the table above may vary depending on the views of the teacher, but in this case, it’s clear that there are definitely gaps. For example, I can see that there is a gap at the bottom left: Atoms/Text surface. To address this, I could add the following — “Can you locate a function call in the program?” — to my list of questions to ask the students.
What I’ve outlined here would take a lot of time and effort to do in every lesson, but an enhanced awareness of the types of questions and activities we use will help us understand our students’ difficulties with programming. I haven’t tested this widely but I believe that it may help us develop a language to use to understand our own practice as programming teachers. The approach adds to our pedagogical content knowledge (PCK) and increases metacognition relating to the teaching of programming.
I’m keen to hear from any teachers who try to apply the Block Model in their PRIMM lessons! Do contact me via Hello World at contact@helloworld.cc or on Twitter at @HelloWorld_Edu and let me know how you get on!
More about PRIMM
PRIMM was established from a combination of experience and research, so not surprisingly, many experienced teachers will recognise elements from their own practice. It’s very useful if you are new to teaching programming, or are struggling to get your students to understand a particular concept.
Many teachers have been using the PRIMM approach in their lessons; if you’ve never heard of it, here are some resources to have a look at:
Teach Computing Quick Read on PRIMM
PRIMM: Something for your programming pedagogy toolkit? Sue Sentance, Hello World issue 4, p.62-63
Programming pedagogies: PRIMM. Oliver Quinlan, Hello World issue 5, p.25
Reusing familiar techniques. Jane Waite, Hello World issue 6, p.74-75
Sentance, S. et al. 2019. Teachers’ Experiences of using PRIMM to Teach Programming in School, SIGCSE ’19: Proceedings of the 50th ACM Technical Symposium on Computer Science Education
Further reading
Schulte, C. (2008). Block Model: an educational model of program comprehension as a tool for a scholarly approach to teaching. Proceedings of the Fourth International Workshop on Computing Education Research, p.149–160
Izu, C. et al. (2019). Fostering Program Comprehension in Novice Programmers — Learning Activities and Learning Trajectories. ITiCSE-WGR ’19, July 15–17, 2019, Aberdeen, Scotland, UK
