What is it
Coding cognitively is about understanding how students think and learn and adapting our teaching of coding to maximise their opportunity to learn effectively.
Why would you use it?
There are many barriers to students effectively learning to code. By being aware of these barriers and thinking carefully about how to overcome them, we can improve outcomes.
How does it work?
A little background is required. Cognitive Load Theory (CLT) is the study of how the brain processes and stores information. Based on our current understanding, there are two types of memory. Long term memory allows us to remember things in the long term which in theory, is limitless. Working memory is where we initially process and understand new information. Most people can generally remember four to seven different things at any one time before their working memory becomes overloaded. Once overloaded, our ability to process and store new information is severely limited.
In addition to our memory, certain tasks given to us present intrinsic or extraneous loads on our memory. Intrinsic load is our core knowledge and is easy to retrieve. It is the teacher's goal to make all their student's learning intrinsic by the time they sit their exams.
Extraneous load takes up much of our working memory. When we are trying to perform a task for which we don't have all the information to hand or are being interrupted, chances are our brain is dealing with an extraneous load where our working memory is frequently being overloaded.
The goal in our teaching is to ensure that everything we give and present to the students reduces extraneous load as much as possible.
What does it look like in the classroom?
There are many strands to this across teaching, but let us focus on coding.
When we code, there is a lot we need to remember and do including:
Knowing the syntax of the code we wish to write
Knowing how to use the IDE / environment of the computer
Understanding the task we have been set
Having a strategy for solving problems
When understanding an algorithm we have just written, having in our mind the values of the variables in out code as we trace our code
It is fair so say that of the 5 points above, each could have 10-20 different bits of information that need to be processed in our working memory. It is no wonder some students struggle to learn to code.
Solutions
There are two key points:
When planning, think carefully about your learning objective and remove anything that may distract away from the key learning objective.
Break your learning objectives into small chunks allowing students to progress onto the next chunk once they have mastered the first.
In coding lessons, here are some things that might overload your students.
PowerPoints - we put words on the board and then talk. Do we want students to read the words or listen to us? Chances are they aren't doing both. I type my notes onto the board whilst dictating. It allows me to go at the speed of my students and allows me to stop and explain details knowing I have the full attention of the class.
Images - we show students images and talk. Do we want them to take in the image or listen to us? Chances are they aren't doing both. I prefer to draw my diagrams on the board. There is something wonderfully human about starting with a single line and ending up with the inner workings of the processor rather than showing a complex image on a PowerPoint that is hard to know where to start.
Code syntax - students frequently struggle to remember syntax and this may well block them from completing a problem solving task which may initially be unrelated to syntax. Give students the syntax in the form of a cheat sheet. Syntax comes with experience so nothing is lost and in the real world everyone just Googles it anyway, However, most importantly, spend time explaining how to use the cheat sheet (see use of PRIMM)
IDE - If you use Visual Studio or similar, be aware that to fresh eyes this is a bewildering place to be. There are buttons, windows and things to click everywhere. Spend time explaining what the different parts of the IDE are, how they work and how they should be used. Give students coded solutions that work and allow them to debug, step through, build and run them without needing to worry about coding.
Problem solving - Spend time offline getting students to solve algorithmic problems by writing steps out as English sentences and then refine them to pseudocode and then code. (Small steps)
Variables - trace algorithms through with students providing boxes and tables for students to fill in as they trace through the code. As students become more fluent in their own coding, encourage them to use a white board to draw out their own variables as named boxes that they can use to trace their own algorithms.
What do I need to do? - Ensure students understand what they have to do. Model the first task to small groups of students who might get stuck at the start or do a whole example as a class and then allow students to work on a similar problem in pairs or small groups before setting a final problem as homework.
Games - Who doesn't love a game? But chances are, students are focused on scoring points, bragging to their peers or trying to make sense of the rules rather than focusing on the learning within the game. Everyone loves a Kahoot, but does it provide for good learning?
Displays - There is an obsession in some settings with putting up vibrant and engaging displays, especially in primary school. However there is an increasing body of evidence that suggests they are counter to good learning environment. They provide for an unnecessary distraction at best and an overwhelming sensory overload for some of our learners at worst. Other than to please management, is there any purpose to putting up displays?
These are just a few examples but there are many others. Some schools see all wall displays being removed to prevent distractions or students working in total silence. Both have their merits but may well be controversial.
Comments