Reflections on guided build methodology
In 2014 I wrote an article called How I teach programming to 7-11 year olds using Scratch. In 2015 I published a book called How to teach primary programming using Scratch. In both, the main methodology I recommended was a guided build. Teachers introduce new coding concepts by guiding pupils through exemplary projects. At points in the projects there are independent challenges and extension tasks.
As most of the time is spent using Scratch and building code this methodology is very good for developing pupils understanding of the programming environment. How to build, delete and duplicate code. How to work with sprites, costumes and backdrops. I still use this method for the first few projects when introducing pupils to Scratch. However it is less useful for thinking hard about code concepts or methodically building up programming ideas. To be blunt the teacher does too much thinking for the pupil once concepts become more complex. Once pupils have achieved a working knowledge of the Scratch environment then other methodologies become more useful.
Code comprehension
Code comprehension methods involve examining good quality code examples before pupils modify them and finally create their own projects. These methods are often referred to as Use-modify-create methods or you may hear about PRIMM (Predict Run Investigate Modify Make) which added prediction. The following paragraphs outline what I have learnt so far positive and negative when using these methods. You can find the planning that I used linked here.
Focused or unfocused?
When I first encountered code comprehension strategies they were presented in a very unfocused way. Pupils would just use the code before making modifications they wanted. This was very motivating for my highly motivated programmers but the majority didn’t really engage with the code. I decided to try these strategies in a more focused controlled way through questions and answers.
Macro and Micro questions
Macro questions focus on the bigger picture such as what the code does and micro questions delve into parts of the code. Pupils need both types of question. The predict aspect of PRIMM is very good for getting pupils to think about the Macro bigger picture code purpose. It helps to build complexity gradually, by starting with simpler literal questions where the answer are directly in the code.
Literal and inferential
Variety of examples
One real criticism I have of my earlier guided build curriculum was that there were not enough variability of examples to enable new computing concepts to become sticky. Careful writing of code comprehension materials can enable pupils to encounter many variations of the same concept. In making choices pupils encounter the following variations of condition-starts-action.
When they came to use these concepts independently many more pupils used a variety of methods in their own projects.
Year 5 Class at Ringwood Junior School (Approx 12 hours of programming lessons per year)
13 used one method only, 12 used two methods, 3 used three methods, 1 is working on earlier curriculum, 2 were away
Self Marking
Having mark sheets on hand for each section has increased pupil independence allowing me to focus on pupils who need more help, encouragement or support. Collecting these marks adds to my understanding of pupil progress alongside their independent creations.
Paired working
I have experimented with code comprehension methods where pupils work on their own or in pairs or as a supportive pair. I favour similar ability pairs for the use and modify parts and solo working for the create section. When pupils know that they will need to create independently they are more likely to concentrate and be a full partner in the use and modify sections instead of sitting back and letting their partner do the heavy thinking work. Some pairs just really don’t get on and rather than forcing them I will allow them to work on their own. One of my greatest privileges is walking around and listening to pupils discussing code problems.
Adapting code comprehension for SEN pupils
If pupils are behind in their reading ability it affects code reading as much as it does reading text. Often these pairs don’t get as much work done in the same time. This leads to the danger that they don’t get to take part in the create part of the cycle. One way to negate this is to create a shortened repeated cycle such as that illustrated below.
Often these pupils baulk when faced with too many questions. So I am experimenting with sections that can be cut up and handed out one section at a time to reduce what is seen at any one time. In the same way long code sections can induce worry or pressure so I am experimenting with shorter code examples that still carry enough information and variety of examples to be useful. Early indications are favourable that these adaptations help. I am also investigating question types that have less writing such as draw lines or circle or tick a part to show comprehension. I am also experimenting with easier language than use modify create as you can see below. Reading ability is important in all programming but it is even more important in this methodology. This might be considered a disadvantage for this method by some.
Code modification
Gradually increasing the code modification challenges enables pupils to feel supported. One method is to think about whether the modification affects how the program operates. Non operational changes don’t really change the programs purpose. Minor operational changes make the program run slightly differently etc. To date I have avoided major non operational changes as being too time consuming for my primary pupils.
There is a fine line between major operational modifications and easier new creation projects and sometimes I have blurred this line to enable smooth transition from modify to create.
Create
My first experiments with create sections often involved four or five alternative project ideas with an option to create what the user wanted as long as they used the concept introduced. These were fine for my high and middle ability pupils but were often not graduated enough for my lower ability pupils. Adapting this to have an easier set of creative choices which pupils could complete within the modify code section and then a more complex set of options that could be created inside or outside the code examples have improved pupil outcomes. Following this approach a recent year 4 class all achieved the easier creative option independently.
It is in the increased creative outcomes after using and modifying code that I am most positive about code comprehension approaches. It has increased my pupils independent agency over programming concepts. Their ability to write good code for their own purposes.
Design in code comprehension
In some simple projects, pupils can go straight from using and modifying into creating with no planning but the more complex the independent project the more planning improves outcome. In many of my gaming modules I have added planning exemplars so that pupils can see what the planning for the modify project looked like. This has improved their planning outcomes and the code they ultimately create. I wonder though if there is enough planning focus in code comprehension strategies which is why I still use My Best Game Ever Planning as it is planning focused rather than code comprehension focused.
Easier to teach?
I certainly seem to have more time to assess pupils creations and work with those who need support. I am contemplating adding a teacher hints version of the use and modify sections to help non specialist teachers support struggling pairs with useful hints, explanations, concrete role-plays etc.
Conclusion
Whilst I think there is a place for guided builds especially when pupils are new to programming, code comprehension strategies enable higher conceptual knowledge stickiness and have enabled higher pupils agency in my pupils. I recommend that you include it in your programming methods.
Research References
You can read about my research references and influences at the bottom of this page