Posted on

Coding at Key Stage 3: Thinking about progression (via Tim Eaglestone)

I’ve been thinking a lot about both the what and how of teaching Computing next year. It’s a subject on many people’s mind and is causing concern for quite a few.  Threads are starting on the Computing at School (CAS) discussion board on developing a pedagogy for computing. The teaching of coding appears to be the biggest area of concern.

I am grateful to Sue Sentance of Anglia Ruskin University for first posting a comment on the CAS discussion board about a recent talk by the University of Glasgow’s Quintin Cutts on his thoughts on assessing undergrad programmers; and secondly for kindly forwarding me Quintin’s presentation along with a couple of background papers: the snappily titled Concrete and Other Neo-Piagetian Forms of Reasoning in the Novice Programmer and Learning Edge Momentum: A New Account of Outcomes in CS1 (which I confess I have not yet read but will).

As a secondary school teacher, I was pleased to see reference to the SOLO Taxonomy in the first paper. Apparently, I had been using a taxonomy based on neo-Piagetian principles all along! The paper goes on to describe how Piaget’s stages of reasoning can explain common issues with new programmers. There is much food for thought here and much of what the authors describe chimes with my experience of teaching Ruby to Key Stage 3 students this year along with previous experience of teaching several other ‘textual’ languages to students of various ages.

A quick run through of Piaget’s stages

There are four stages to Piaget’s model:

  1. The Sensorimotor Stage: This is the first of the four stages and covers from birth to the acquisition of language.  We wont dwell on this stage as it describes cognitive development in the typical infant.
  2. The Preoperational Stage: This stage is characterised by symbolic play and the manipulation of signs and symbols. It is the phase of least abstraction and is where the first paper starts in describing ’novice programmers’. This is the stage at which most of us begin when starting out in a new field of endeavour. The suggestion is that many students get stuck here when learning to code.
  3. The Concrete Operational Stage: The foundations of abstract forms of reasoning and generalisations are developed in this stage; it is here that logical and inductive approaches to problem solving are evident. Hence, there are some interesting implications for getting students to this phase in the paper that have a direct bearing on what and how we teach in Key Stage 3.
  4. The Formal Operational Stage: According to Wikipedia, in this stage, “Intelligence is demonstrated through the logical use of symbols related to abstract concepts. At this point, the person is capable of hypothetical and deductive reasoning. During this time, people develop the ability to think about abstract concepts.” This is where we want to be. They sound like good computer scientists to me.

It is stages two and three that mainly concern the authors (and me) as it’s here that things often get stuck with coding.  It is worth pointing out that Piaget associated these stages with childhood ages. The neo-Piagetian view is that these stages are not a result of maturity but instead reflect the capacity of the working memory and its ability to work in tandem with long-term memory via the retrieval of ‘chunks’ of information.


Progression in chunks when writing code

Talk of chunking and short-term memory got me thinking about knowledge. Specifically, how we might want to build knowledge in coding so that students have something to retrieve to help their working memories when learning (assuming this is an accurate model of how we think).

In short, chunking is the theory that larger sets of data are stored in long-term memory and retrieved by the working memory as if they were a single item. The example given in the paper is learning a telephone number. It enters working memory as a series of individual digits before getting committed to long-term memory as a ‘chunk’ of knowledge in the form of the whole phone number.  We can use other chunks, such knowledge of area codes, to help this process.

We can map some common activities done when learning to code to Piaget’s Preoperational and Concrete Operational stages:

Stage Learning to code activity
(Many students get stuck here)
  • Spotting keywords
  • Identifying numbers and data (variables)
  • Spotting syntax elements (such as block starts and ends)
  • Recognising constructs (sequences, loops, conditions)
  • Tracing (running through the code on paper step by step)
  • Explaining the code in English in the form of a trace (“first it does this, then it does that…”)
Concrete Operational
  • Explaining the code in English in terms of its function (“This code sorts an array from smallest to largest”)
  • Using diagrammatic abstractions
  • Completing conservation exercises (e.g. “This method is not finished. Complete is so that it returns …”)
  • Completing reversing exercises (e.g. “Heres some code that does X, Y and Z. Write some code that does the reverse: -Z,-Y then -X.”)
  • Transitive inference (where a student might have to hold several possible program states in mind to answer a question, or generalise a system’s response by reading a fragment of code)


There are some things to note from this table:

  • I have added my own ideas to the preoperational based on my Key Stage 3 experience. The first four bullets are activities that get students engaged with the syntax of the chosen computer language. The types of activities are taken from the structural phases of the SOLO Taxonomy.
  • Diagrammatic abstraction appears to be a higher order skill than I originally assumed. The implication of this is not to draw a flow-chart and ask kids to produce code from it early on, but to maybe run this process in reverse to encourage skills in abstraction. That is, present some simple code and see if students can produce the flow-chart from the code instead of the other way round.
  • When asking students to articulate the function of the code in English whether orally or in writing, be aware that tracing (describing the code line by line) is a more accessible task than describing a generalised function. Again, this agrees with my own experience when doing this type of activity with Year 8 (12 to 13 year-olds). When asked to give a written explanation in their books, many students explained the code line by line; the more confident coders were able to say things like, “it uses a while loop to draw some petals”. A teaching point is to be explicit about the form when asking students to articulate code and provide stem sentences or other scaffolds to encourage students to explain code in more general terms once they have competently done so line by line.
    • Conservation exercises should probably be given more frequently that I currently do. A subject for another post might be to look at porting DARTS (Directed Activities Related to Texts) type activities to Computing as a form of conservation exercises.
    • Reversing and conservation exercises are explained at greater length in the paper. They are the first time students really produce code of their own in this model.
    • Exercises involving transitive inference are more subtle and need some further consideration. They might make good extension tasks for the more able

    See more from this excellent blogpost here



About danbowen

Educational technology learning and teaching consultant, support, training, change management, innovation and all things ICT and educational, father of two, guitarist, welsh rugby follower,

Leave a Reply

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

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

Google+ photo

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

Twitter picture

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

Facebook photo

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


Connecting to %s