computer science education · pedagogy · research · teachers · teaching · Uncategorized

A continuum of scaffolding: from copying code to tinkering

Jane Waite, of King’s College London & Queen Mary University of London, is researching ways of teaching programming, with the ultimate goal of supporting primary teachers teaching programming. In this post Jane describes a continuum of programming that she uses in training with primary teachers (CAS London run a number of Diving Deep courses in primary pedagogy). Jane says:

Whilst undertaking literature reviews over the last couple of years I have started to formulate a model. This is a model of how programming activities in primary classes might be scaffolded. By scaffolding I mean how teachers (or an automated learning system) might guide and control learners’ tasks and activities. It is a very simple model, just a linear continuum of different instructional approaches. Some research has mentioned blended approaches already and this model builds upon this work, providing some examples to flesh out the idea.

Approaches for teaching programmingI have been sharing the continuum of scaffolding in teacher training events since mid-2017. I usually introduce the model by giving delegates, in pairs, a set of programming activity descriptions on small cards. I ask them to order the cards from most scaffolded to least scaffolded. Example tasks are ‘copy some pre-created code’, ‘explore 3 scratch commands’, ‘fix some buggy code’, ‘do an unplugged activity explaining repetition’. This really gets the educators talking about what the different tasks are and how much support is provided to pupils. I then reveal the continuum of scaffolding and we discuss.

All the continuum provides is vocabulary. I don’t think the continuum is perfect in its linear representation of scaffolding. There is usually hot debate on whether guided exploration should be a targeted task and within Projects there is a further set of ‘stages’. In some training events teachers use the continuum to review their lesson planning. In other sessions, I use the continuum to situate training activities.

The main aim is to exemplify a whole range of instructional techniques, pedagogies, for teaching programming, to reveal there is not just copy code tutorials or unguided tinkering. My objective is to provide teachers with a shared understanding of different approaches available to them.  This then means they can compare lesson and unit plans and start to become more discerning consumers of CPD and lesson resources and perhaps more confident and effective producers of such material.

I have not yet completed studies to investigate the completeness or effectiveness of the continuum model, but I have started the process. In my running of primary teacher training I have been including the continuum and I will be investigating teacher perceptions through surveys and interviews. As part of my PhD, I will be writing up the underlying sources of each of the instructional approaches included in the model and outlining evidence from literature of these approaches.

Below is a little more detail about each of the techniques and approaches within continuum. Please remember this is not an exhaustive list of techniques and that the model is not perfect. The model is a starting point to promote discussion within teacher training events and give teachers terminology to review their teaching.


  1. Copy code. This technique is where pupils are given a set of instructions to follow to create a program. The program was thought of, designed and coded by someone else, pupils are now re-creating it. Learners are required to follow a set of instructions, line by line. This might be through an online teaching product or might be a printed set of instructions. Sometimes this approach is called a tutorial approach.
  2. Targeted tasks. There are many targeted tasks that teach specific concepts or address particular misconceptions. Often such tasks are aimed at getting children to read and understand code. If learners are online there is the temptation to run code before you have read it, so these activities may use printed code snippets. An example activity might be to give learners a program and asks them to summarize what the code will do, or to trace the code line by line. Simply put, tracing is where you say exactly what each command will make happen when it runs. In both of these scenarios, learners are predicting what the code will do. Other targeted tasks might be to spot the difference between code snippets, remix code to achieve a particular outcome and fixing buggy code. Targeted tasks also include unplugged activities, such as playing a game with a score to learn about variables, or calling out lines in a poem to find out about the broadcast command for Scratch.
  3. Shared programming. This method is very similar to shared writing, where the teacher knows what they want to teach and is showing pupils not only what the finished product looks like but is also explaining the making process and their thought process.  It could be that teachers or pupils deliver the demonstration. It could be that the teacher takes ideas from pupils as they are demonstrating to create a ‘class’ version of the program. This form of apprenticeship might also be used in small groups or on a 1:1 basis.
  4. Guided exploration. Here learners are provided with just 2 or 3 commands that they must explore. The teacher has an idea in mind of what they want children to learn. But rather than telling them what the commands do, they ask children to find out. Teachers might include some questions to nudge children along to get to the objective of the task.
  5. Projects (use/imitate/remix/new/share). Here pupils are required to create a project of some kind. There are lots of different ways to run projects as well as different ways to scaffold learning in projects. In literacy, some teachers follow a progression that scaffolds learning to write texts. At first pupils read lots of examples of the genre of text they are going to create. Then they create an imitation of an example text. Next, they create a variation of the text. Finally, they get to inventing a brand-new version.  In programming projects, we could do the same, start with children using example projects. Next, they could create a project that imitates a high-quality exemplar. Then have projects where we are remixing ideas, algorithms and code examples. With an end goal of learners independently creating a brand-new program. This development of independence might span years of different projects across different programming genres.
  6. Tinkering. This technique requires pupils to play. They are given access to a programming environment and perhaps some hardware too and asked to explore and play.

This list of approaches is by no means exhaustive and the techniques are not distinct. When running a project, you might include a little copy code to get children to accomplish one tricky thing that you plan to later teach through guided exploration or targeted tasks. Or you might develop children’s curiosity and emerging understanding of a new programming language with some tinkering before demonstrating certain features and moving on to a ‘remix’ project.

Here I have not commented on the impact nor effectiveness of the approaches outlined. There is limited research to tell us which techniques are best for primary pupils for particular concepts, tasks or phases of learning.  My intention is to create a simple starting point, engage with teachers in exploring this, refine and make recommendations for other to build upon.




2 thoughts on “A continuum of scaffolding: from copying code to tinkering

  1. I am so pleased to see that you are working on this and would like to add my two penny worth. Having tried all of the approaches you have listed over the last four years (as an ex-ICT teacher come to CS) I have, currently, come to the point of rejecting them all as cognitively ineffective. I am now testing my own ‘Structured Theorem’ method – well I think it is really focussed unplugged and is probably being done by others but I haven’t come across it explicitly stated as such. I think playing with code is like going to a Chinese Restaurant, playing with Chinese words and then seeing what the waiter serves up. It isn’t to the point. Or Monkey, typewriter, Shakespeare. Ah, is the problem that the Monkey doesn’t speak English and that if it were to write in Monkeyish then it could do it? No, that’s not the problem. The problem is not one of not knowing the language. The problem is that the monkey doesn’t know that it is upsetting to have your uncle kill your father and that this can make a good start for a plot that ends up with a Midsummer murder body count. My point being that your lack of understanding of what code words do is not the main barrier to creating a machine that can perform a task for you. You have to be able to perform the task yourself and then to draw up the algorithm that captures the flow of control through the task. Once you have the algorithm you just need to transcribe it into code – and a machine can do that for you if you will (see Jackson workbench). My hypothesis is that as every process/task is made of the three Bohm Jacopini constructs (to give them due credit), sequence, selection and repetition, and that these 3 ‘elements’ are what the chemistry of process flow control is all about, it follows that in order to master the skill of finding the algorithm for a process it is first necessary to master the use of each of the three constructs. (I find it awesome that every process can be reduced to just 3 structural elements – spotting this was, I think equivalent to the discovery of the Periodic Table). Just this week I have been trying this out on Year 9. So, I have given them repetitive skill building exercises (as one does in Maths) on finding the sequence is a set of 12 simple tasks e.g. cheese sandwich or close level crossing barrier, then drawing the flowchart and then coding this in Scratch and Flowol. Very simple so that the value of sequence can be internalised. I followed this, the next lesson, with a set of exercises on conditions where the operator was equality e.g. Tennis, if it is raining, then stay in, else play. Another dozen of these, then a few flowcharts and then code in Scratch. I was beginning to think that I was boring them and that it was a waste of time but actually think that something valuable was happening. Stripping away all the usual clutter of multiple constructs, which you get once you get into even a slightly bigger problem, does, I think so far, give them more chance of homing in on the value and place of each one rather than wondering what on earth is going on. They took the example of tennis and rain and ran with it. I showed them that ‘Sensing’ has the question, that ‘answer’ stores the response and that they needed an ‘Operator’ block ‘=to’ to do the comparison. That was quite enough to be getting on with at one time. cf Dijkstraa ‘small brained human’. So, it’s raining? Answer = ‘Yes’ and cat went under the umbrella. Not raining, into the sun etc. The other feature of CT that emerged from these lessons was the importance of seeing the ‘flow of control’. IF THEN ELSe sits in Scratch in the orange ‘Control’ block set. At first, when this was discussed, they couldn’t readily identify was ‘flow of control’ meant. This wasn’t an entity that they were familiar with. It needed to be explicitly taught. Why ‘flowchart’? Why ‘Flowol’? The conductor of orchestra etc. And then, shoes and socks. Okay, sequence, socks first, then shoes. However, it took my removing my shoes and putting the right one on my left foot before they could see that a branch point needing the testing of a condition was needed. So, again, paraphrasing Dijkstraa, you can perceive one horse galloping towards you on a beach but not a thousand. One construct at a time, with sufficient work at identifying that construct in the problem domain, followed by sufficient practice drawing the flowchart to represent the flow of control and then and only then coding. I am trying out using coding in a flippant manner – using a range of options, Scratch, micro:bit, Flowol, eV3, Python really to make the point that code language is not the issue or what needs to be learnt. It is learning the chemistry of structure that needs to be learnt. That means decomposing/analysis to identify the atomic steps that are in machine do-able chunks but more importantly it means being able to see the 3 constructs in the problem – and you aren’t going to be able to do that until you have real, deep working knowledge of what each one is. And I really don’t think that playing with code is where you are going to best learn that. Yes, code to prove that you found the right structure but not in order to find the structure – that is done by doing the task yourself, unplugged. By way of analogy, if I want to tell someone in Paris the way from the Arc de Triomphe to the Eiffel Tower then knowing the words or grammar in French isn’t the main problem – its knowing the way that is the issue. However, I could be wrong (science background, refutability and all that) and so I will keep an open mind and see how the rest of it goes i.e. conditions with inequalities, count controlled loops and then condition controlled loops.


    1. Hi Mark, it’s very exciting to see your responses in four years later. Would you mind sharing more about your experiences and your testing results about the “structured Theorem” method.


Leave a Reply to Mark Thomas Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s