Reducing the load: ways to support novice programmers

What’s your experience of learning to program? Have you given up and thought it just wasn’t for you? This has been the case for many people — and it’s the focus of a lot of research. Now that teaching programming is in the curriculum in many countries around the world, it’s even more important that we understand what we can do to make learning to program accessible and achievable for all students.

What is cognitive load for learners?

In education, one of the problems thought to cause students difficulty with learning anything — not just programming — is cognitive load. Cognitive load, a concept introduced in the 1980s by John Sweller, has received a lot of attention in the last few years. It is based on the idea that our working memory (the part of our memory that processes what we are currently doing) can only deal with a limited amount of information at any one time. For example, you can imagine that when you are just starting to learn to program, there is an awful lot going on in your working memory, and this can make the task of assimilating it all very challenging; selection, loops, arrays, and objects are all tricky concepts that you need to get to grips with. Cognitive load is a stress on a learner’s working memory, reducing their ability to process and learn new information.

Dr Briana Morrison (University of Nebraska-Omaha)

Finding ways of teaching programming that reduce cognitive load is really key for all of us engaged in computing education, so we were delighted to welcome Dr Briana Morrison (University of Nebraska-Omaha) as the speaker at our latest research seminar. Briana’s talk was titled ‘Using subgoal Labels to Reduce Cognitive Load in Introductory Programming’.

The thrust of Briana’s and her colleagues’ research is that, as educators, we can design instructional experiences around computer programming so that they minimise cognitive load. Using worked examples with subgoal labels is one approach that has been shown to help a lot with this. 

Subgoal labels help students memorise and generalise

Think back to the way you may have learned mathematics: in maths, worked examples are often used to demonstrate how to solve a problem step by step. The same can be done when teaching programming. For example, if we want to write a loop in Python, the teacher can show us a step-by-step approach using an example, and we can then apply this approach to our own task. Sounds reasonable, right?

What subgoal labels add is that, rather than just calling the steps of the worked example ‘Step 1’, ‘Step 2’, etc., the teacher uses memorable labels. For example, a subgoal label might be ‘define and initialise variables’. Such labels not only help us to remember, but more importantly, they help us to generalise the teacher’s example and grasp how to use it for many other applications.

Subgoal labels help students perform better

In her talk, Briana gave us examples of subgoal labels in use and explained how to write subgoal labels, as well as how to work with subject experts to find the best subgoal labels for a particular programming construct or area of teaching. She also shared with us some very impressive results from her team’s research examining the impact of this teaching approach. 

Screenshot of Dr Briana Morrison's research seminar talk

Briana and her colleagues have carried out robust studies comparing students who were taught using subgoals with students who weren’t. The study she discussed in the seminar involved 307 students; students in the group that learned with worked examples containing subgoal labels gave more complete answers to questions, and showed that they could understand the programming constructs at a higher level, than students who learned with worked examples that didn’t contain the subgoal labels. The study also found that the impact of subgoal labels was even more marked for students in at-risk groups (i.e. students at risk of performing badly or of dropping out).

It seems that this teaching approach works really well. The study’s participants were students in introductory computer science classes at university, so it would be interesting to see whether these results can be replicated at school level, where arguably cognitive load is even more of an issue.

Briana’s seminar was very well received, with attendees asking lots of questions about the details of the research and how it could be replicated. Her talk even included some audience participation, which got us all tapping our heads and rubbing our bellies!

Screenshot of Dr Briana Morrison's research seminar talk

Very helpfully, Briana shared a list of resources related to subgoal labels, which you can access via her talk slides on our seminars page.

You can also read more about the background and practical application of cognitive load theory and worked examples including subgoal labels in the Pedagogy Quick Read series we’re producing as part of our work in the National Centre of Computing Education.

Next up in our series

If you missed the seminar, you can find Briana’s presentation slides on our seminars page.

In our next seminar on Tuesday 14 July at 17:00–18:00 BST / 12:00–13:00 EDT / 9:00–10:00 PDT / 18:00–19:00 CEST, we’ll welcome Maria Zapata, Universidad Rey Juan Carlos, Madrid, who will be talking about computational thinking and how we can assess the computational thinking skills of very young children. To join the seminar, simply sign up with your name and email address and we’ll email you the link and instructions. If you attended Briana’s seminar, the link remains the same.



This is an interesting bit of information, totally in line with what I have been learning about concepts. Love this, am going to share and use it!


I’ve used the subgoal a approach for years, it DOES help. Since the evolution of modular programming, stub testing doesn’t get much traction. Build the core, add testable units to the core bit by bit. After a while, you’re familar with the system design that has evolved and very efficient. (for those of us who craft from their head)


Thank you Mark for sharing your successful experience.
Since (mostly) a human input is required to ‘start’ a dialog with a computer I got the student to write a line of code asking for the input and displaying that request on the screen…this leads to an immediate sign of success !
Then testing boundaries such as is the number between (say) 1 and 10. Anything outside of the boundary to display an error message as well as the number that was input. In other words each line of code has to be checked immediately after it’s operation.
Better still to display each line both before and after operation.
I also got the teams to form themselves into a Leader, an outliner of code expectations (ie the function) and the actual coder with the Leader double checking on the performance of the function. This we did in the early 1980’s way before any of the fancy terminology now flying around. BTY the best coder checkers are the very people that are losing their jobs; every day clerical personnel. They would dearly love to be part of the future because they are very meticulous with their thinking and since software such as Windows keep crashing with each and every update why don’t they employ clerical staff for testing purposes and leave the rest to the high fliers ?? I welcome any constructive feedback.


Thank you for sharing this. In the 1980’s I taught Youth Trainees aged 16’ish and taught them the basics of C programming from scratch in less than 2 hrs by guiding them how to think using concepts and the results were remarkable such that I was removed from the class instructor role for causing trouble.. I then taught a group of secretaries the reduced instruction set by use of an example and getting them to use group think to amend the example to produce a different outcome; they were highly delighted. I then suggested that we encourage primary school pupils to learn the basics of programming concepts but was told ‘to mind my own business; it will never happen’. What was really meant was ‘we don’t want it to happen because ‘they’ will realise that it is too easy and we will lose our high salaries’. What a waste of all those years for sheer greed and stupidity !
What have I done? Taught myself Linux and hade 5 different versions on a 500 Gb HDD and used a Raspberry Pi to learn the Command Line and manage Synaptic for Application investigations; in other word a replacement PC. So all was not lost because after a serious car accident in 1995 which resulted in moderate brain damage I found a recovery method by utilising my previous private study.


Hello I am really not surprised that nobody has thought it merited a response. However all is true and many electronic techs have thanked me for help in getting the hang of the required mind set both in the UK (at the very bottom) and overseas (at Graduate level in the 1980’s.
Time to liberate folks and not keep it hidden.

Only society can win the global problems if you freely educate.

Leave a Comment

Comments are closed