Policy Innovation Blog

Rigour: the connection between yoga and computer programming

Mark Griffiths - 15.05.2012

In one sense, you would be hard pushed to find someone who argued for less rigour in education - who doesn't want students to learn as much, and as deeply, as possible.  The crux comes when people start defining the learning processes and the content that constitute 'rigour'.

Is a lecture format the acme of 'rigour'?  Can studying The Simpsons form part of a 'rigorous' learning experience?

Given the new interest in the teaching of computing at schools, these debates have been given a new format.  Our Next Gen. report, for example, argued that "computer science should be a highly rigorous course in schools that focuses on the essentials of programming, algorithms, logic and data structures".  Similarly, the Computing At School group have been consistently (often as a lonely voice) articulating the rigour, and relevance, of learning about 'if conditions', data structures, and variables.

As an ex-programmer, I have no doubt that this content is tough and demanding.  It passes the rigour test.  However, discussions often fail to make a distinction between rigour in learning goals, and in learning processes, with an implied assumption that group learning, or learning structured around a project, is, by definition, less rigorous. 

This isn't true, especially for the deep learning that we all want students to engage in.  Erik de Corte, writing as part of the OECD publication 'The Nature of Learning: using research to inspire practice' tells us '[t]he current understanding of learning, aimed at promoting 21^st Century or "adaptive" competence, is characterised as "CSSC learning'.  The 'C' stands for Constructive, or the obvious fact that learning is something done by the learner, involving hard work as they construct their knowledge and skills.  'S' is Self-Regulated - students need to use strategies to learn, for example setting themselves challenging but achievable goals, and then monitoring their progress towards achieving these.  The other 'S' is Situated, more learning takes place in contexts that are relevant to the student (for example, someone who is bad at remembering names is likely to remember the name of someone she wants to go on a date with), while (we're nearly there!) the final 'C' stands for 'Collaborative': learning is not a solo activity.

It's quite easy to sketch out how these principles would be realised in the context of a programming activity.  Students could be working in groups on a joint activity where the success of the group depends on the contribution of each individual.  The task that they are working on has relevance to them - maybe they choose the particulars of the puzzle they want to address, and it would probably help if the task has real-world relevance.  For example, maybe they could be designing apps, which they will then go on to sell, or creatively making use of some open data, or hacking and then publishing a web page. 

Importantly, none of this should be confused with a model where students are just grouped together, given a task, and left to get on with it.  Rather, the 'teacher' takes on a more demanding and fulfilling role, for example by structuring the tasks and the interactions within the groupings of students, articulating the learning goals and success criteria, modelling and presenting content where needed, and seeking and responding to student feedback on how they are getting on.  All of this should be there in the best group work, or project led enquiry.

I have a non-programming example of this from my own experience - my yoga lesson where I am constantly impressed by the quality of the instruction.  Here there is a task that taps into my existing motivations; my yoga teacher begins an exercise by modelling the exercise; I have (somewhat) been successful in understanding what it feels like to make progress in the task; while my instructor is constantly going around the room and providing micro-feedback on how well we are all doing.  If we get it badly wrong we, and my instructor, will try again - maybe we will use equipment, or my instructor will model the exercise again, highlighting the features which we need to work on. 

What she never does is didactic learning - standing at the front and declaiming the learning content.  No one would ever expect that from a yoga lesson.  I don't see any reason to expect the same from a programming one.