Cognitive Load Theory
Understanding the limits to our mental processing capacity to design more effective systems of learning, practice and working.
This article delves into our understanding of cognitive load to bring new perspectives and approaches to the learning and systematic practices involved in a path of mastery.
During my last decade or so of working in Software Engineering I’ve learned that one of the primary factors in determining the human experience of a team of engineers, and thus the work they are able to deliver, is the cognitive load placed upon them during their day-to-day work.
Due to the increasing complexities and pace of change in software engineering environments, tools, techniques, and methodologies combined with the demand from the wider business and customers for more features, functionality, and performance, the job of software engineering is one of continual learning and adaption. In a badly managed software engineering department, engineers find themselves continually context-switching to answer an impossible variety of demands and burning themselves out to deliver features in unrealistic deadlines from out-of-control spaghetti codebases of exponentiating complexity.
I’ll return to thoughts on managing cognitive load for software engineers in the conclusion of this article. In the meantime let’s look at the concept of working memory which laid the foundations for cognitive load theory
The magical number seven, plus or minus two
Investigations into the capacity of the human working memory, notably by George Miller1 with his eponymous Miller’s Law, highlighted the limits to our information processing capacity. Our short-term memories are limited to holding 7 ± 2 discrete pieces of information simultaneously.
We can overcome this limitation by chunking, grouping elements together into a meaningful association so that our short-term memory retains chunks of related information, rather than all of the discrete elements.
For me, a relatable example of chunking is learning the chords which make up a song in music. A complete beginner needs to recall all the notes that make up a chord - until they know the individual notes of a chord they will be overwhelmed by the cognitive load of memorising a verse. A more experienced musician will have the notes and chords burned into their muscle memory. When it comes to memorising a whole passage of music, they will have the advantage of being able to see common patterns of relationships between the chords. A common example is the II, V, I progression in Jazz and popular music where the 2nd chord in the harmonic scale is frequently followed by the fifth before resolving to the first. Only the pattern needs to be remembered so that a whole song can be quite easily understood and learnt merely through connecting a number of familiar chord progressions, thanks to the previous work undertaken by the musician to develop a schema or mental model of chunking information into patterns.
Cognitive load refers to the amount of mental activity that is imposed on working memory at any given time. By managing cognitive load effectively, we can determine the level of mental effort required to process complex information without overwhelming working memory.
The amount of cognitive load is dependent on the number of elements interacting with each other in working memory, including the many information inputs that need to be processed simultaneously. Since there is a limit to the amount of data a person can hold onto, the person is less likely to retain it if too much information is delivered at once. Also known as ‘drinking from the fire hose’. So, it is important to manage cognitive load effectively to get the best results from practice and learning situations.
Three types of cognitive load
In the 1980s Educational Psychologist, John Sweller, developed his theory of cognitive load which distinguishes three types of cognitive load: Intrinsic Load, Extraneous Load, and Germane Load.
Before delving into each, think about the game of chess and its inherently cognitive nature. The intrinsic load would relate to the sheer variety of ways a game could play out given the range of options available in each move and the anticipation of the opponent’s responses. It’s undeniable that the game itself has a high intrinsic load.
The extraneous load relates to things outside of the mechanics of the game itself, the relationship with the opponent and their stature as a player, any distracting quirks they may have, and any background fears and distractions in your own mind or the environment. If it is speed chess then the procession of the clock during your move would be an extraneous load. This would be exacerbated in a tournament setting with other players and distractions in the room. And it would be at unimaginable levels during a bout of chessboxing where players win by check-mate or a knockout - surely a punch in the face during a game of chess is the ultimate extraneous load.
Germane load is different in nature from intrinsic and extraneous loads, in chess it is the cognitive load involved in learning the variety of attacking and defensive moves available during openings, or the common end-game patterns that emerge when you’re often left with Rooks and a few other surviving pieces trying to pin down the opponent’s King. Germane load relates to building schemas or mental models, in our long-term memories which help us to automatically see patterns in the gameplay without having to think so much. So germane load is seen in a positive light over the long term because it will reduce the intrinsic load of the overall game and be less affected by the extraneous loads.
To explain each type of cognitive load:
Intrinsic load
Intrinsic cognitive load refers to the mental effort required to process the inherent difficulty of a task or material. Juggling the number of various interacting elements in your mind to solve a problem or complete a task. The intrinsic load will also depend on the novelty of the task and whether we can apply pre-existing schemas, mental models, and patterns to simplify the task and reduce the burden on our working memory through the chunking process. In a learning task, it will relate to the inherent complexity of the knowledge or skills we are trying to acquire.
Tasks or materials with a low intrinsic cognitive load require less mental effort and are often easier to learn or complete. For example, memorising a list of vocabulary words or performing repetitive physical exercises, like practising penalty kicks in football (soccer), have a low intrinsic cognitive load.
While intrinsic cognitive load is an essential component of learning and skill development, it is important to manage the cognitive load effectively to avoid overload. High levels of intrinsic cognitive load can lead to mental exhaustion, frustration, and decreased motivation to continue learning.
The intrinsic load can be eased by breaking up a task into more manageable steps, or breaking down the skill into its components, the idea behind ‘drills’ where we focus on one particular aspect of a skill.
Like many things, there is an optimal balance to be struck. In the work on the Flow State by Mihaly Csikszentmihalyi and its application to performance, especially in the extreme sports arena and notably by Steven Kotler, it is often asserted that the optimal challenge level which stretches us 4% beyond our current limits is the sweet spot for the Flow State to emerge.
Extraneous load
Extraneous cognitive load refers to the extra mental effort needed to cope with things which aren’t directly related to the task at hand.
A good example that software engineers will relate to is the burden of context switching when their concentration is interrupted by an unrelated appeal for their input on something. Or like Auguste Rodin's sculpture of 'The Thinker' whose original representation was of an image of Dante, pondering at 'The Gates of Hell', trying to write code in a noisy open plan office while meeting unrealistic time pressures, attending draining meetings, and dealing with cumbersome bureaucratic processes. The intrinsic load of coding is inherently high, software engineering environments should be designed to minimise the unnecessary extraneous load, as per the aim of the Team Topologies philosophy that I’ll refer to in the conclusion of this article.
With regards to learning, a noisy classroom or a poorly designed textbook can increase extraneous cognitive load by making it more difficult for learners to focus on the task at hand. Likewise, confusing instructions or a lack of feedback can also increase extraneous cognitive load by requiring learners to spend mental resources on understanding the instructions rather than on the task itself. Often the stress my children feel around their homework is due to unclear expectations of the assignment.
Extraneous load is particularly felt by learners who face cognitive challenges such as Autism, Dyslexia and ADHD. While autistic people do not have impaired working memory capacities, they are likely to have difficulty filtering out extraneous environmental stimuli in their experience of an ‘intense world’ so they are left with fewer mental resources to deal with intrinsic and germane cognitive loads.
Thinking of a couple of pertinent examples of my own life, I recall playing in a band where a drunken audience member had grabbed one of our tambourines shaking it to their own internal rhythm. I distinctly remember the extra thinking I needed to do in order to ensure I was keeping in time with the drummer of our band. I also recall the frustrations I had with the birth of our twin children. Going from zero to two children overnight brought such a drastic change to my day-to-day routines and the extraneous load of doing anything that involved a cognitive capacity went through the roof. I had no choice but to acquiesce to the reality of the moment and accept that reading anything complex, or writing code, would only be feasible in very small bursts.
With extraneous load in mind, we should heed the insights of W. Edwards Deming and try to optimise our ecosystems for performance - “The fact is that the system that people work in and the interaction with people may account for 90 or 95 percent of performance”.
Germane load
germane
adjective, formal
Ideas or information that is germane to a particular subject or situation is connected with and important to it:
Her remarks could not have been more germane to the discussion.
Source: Cambridge Dictionary
Germane cognitive load refers to the mental effort required to process information in a way that leads to long-term learning or understanding. It refers to the mental resources devoted to building and automating schemata in our long-term memories. This type of cognitive load can be thought of as the "good" cognitive load, as it involves the mental effort needed to learn new information and create meaningful connections between new and existing knowledge.
When learning a new language, for example, germane cognitive load would involve the mental effort required to understand new vocabulary and grammatical rules, common structures and patterns, as well as the effort needed to practice using the language in context. When learners are able to connect new information to their existing knowledge to create new schemas or mental models, they can reduce the intrinsic cognitive load of a task and deal better with extraneous load.
One way to increase germane cognitive load is to engage in activities that promote deeper processing, such as problem-solving and critical thinking. By actively engaging with the material, seeking structure, rules, patterns and working through complex problems to discern the underlying first principles, learners can increase their true understanding and retain the information for longer periods of time.
Even when we’ve incorporated sufficient germane load, our mental resources may still be compromised by excessive extraneous load. Once again regarding the experience of a person with autism, they are likely to have required a good deal of germane load to build ‘social performance’ schemas in their long-term memory to help them navigate the nuances of social settings for example, to rehearse the ‘right’ kinds of ways of acting in order to appear ‘normal’, or masking as this is referred to. They may well have the knowledge of how to act, but if they are experiencing the stresses of an overwhelming extraneous load they will not have the cognitive capacity to retrieve this knowledge from long-term memory. Their social batteries will be empty.
Returning to the comparison of the beginner and the experienced musician learning a new song, the experienced musician has indulged in many sessions of high germane cognitive load in order to understand and internalise the theory, common structures, and relationships of chords into a cohesive mental model of music to learn and perform songs with a much lower intrinsic load than the beginner.
Interestingly, the work I’m doing here - writing about cognitive load theory - is the self-imposition of germane load, deliberately challenging myself to think and writeabout this subject so that it takes shape as a schema in my long-term memory.
Mastering cognitive load and its implications on our systems of practice
What implications do the dynamics of cognitive load have on mastery and the necessary learning and practising required on the journey? Here are my personal reflections, these are by no means authoritative from a cognitive science perspective, just my own ponderings:
Mere awareness
Firstly, the mere awareness of the limits of our working memory and the different ways it can be overloaded should help us in understanding the various cognitive complexities of daily life, and the learning and practices we adopt on our personal paths of mastery.
Having the language to express our experiences and needs from the perspective of cognitive load would help us to communicate with others in a more nuanced way. Instead of expressing our overload as stress, frustration, and anger, cognitive load theory gives us a more subtle, and more convincing, way of communicating our experience. This would be especially useful in the work environment where conversations that touch on intrinsic, extraneous, and germane load could prevent burnout and poor performance.
The realistic design of our systems of practice.
The impact of extraneous load on our working memory gives weight to the importance of environmental considerations during learning and practice. We need to ensure our practices are feasible according to our environmental constraints, and the ordinary distractions of everyday life. Designing an ecology of practice around our environmental constraints is key to the sustainability of the practice. Personally, I tend to tackle tasks with a high intrinsic load, such as writing or other work, in the mornings when I’m fresh. In the evenings I tend to devote time to practices with a low intrinsic load such as guitar or piano scales, or general musical noodling and experimentation. Gone are my night owl days of being able to do cognitively demanding work late into the evening.
Deliberately planning for germane load which may slow progress in the short-term, but will pay off over the long-term. Germane load is the essence of personal development and progression towards a sense of mastery. Setting time aside for practices which are deliberately developmental, which are creating new mental models of a particular domain, and systematically working on the underlying principles, structures, and theories as part of our practice systems are the key to progressing from the plateau and onto the next growth spurt.
A lens to evaluate our experience of practice
Part of the ASPIRE Mastery Framework I’m proposing is the Reality box, the ‘R’ in the model where the intention is to earnestly observe and review our inner selves ‘I’, our external or extraneous circumstances ‘E’, the efficacy of our systems ‘S’, and our chosen paths ‘P’. The lens of cognitive load will be very useful in reviewing our progress with our systems of practice from these perspectives, giving language to talk about our experience in terms of cognitive load and inform potential adjustments to our approach to practice.
Returning to software engineering for some closing thoughts
I opened this article with references to Software Engineering and I’ve also referred to the experiences of people with Autism and the extra cognitive lifting they do due to extraneous sensory overload. Autism and other neurodiverse traits are not uncommon among Software Engineers so hopefully, it has been a useful lens through which to view cognitive load even to those unacquainted with the nuances of software engineering.
The importance of appreciating and managing the cognitive load of engineers has become more widely recognised in recent years, thanks to authors such as Matthew Skelton and Manuel Pais and their Team Topologies work, and John Ousterhout, author of A Philosophy of Software Design - each in their own way highlighting the role of cognitive load in software engineering.
The work of Software Engineering is usually done in teams, but we rarely stop to think about the cognitive capacity of a team in relation to the work we are expecting them to deliver, and we rarely ask engineers for feedback about their cognitive load. Team Topologies not only recognises the role of cognitive load theory in our experience of work, but also provides team design blueprints to manage the cognitive load by clearly defining team boundaries, team interfaces, team ownership, and team structures which are aligned with the actual code and software components they are responsible for in order to optimise the flow of work, and in turn, the flow states experienced by engineers.
Many engineers are acutely aware of the cognitive burden of their work and use energy management techniques such as the Pomodoro Technique, time-bounding work sessions to blocks of 25 minutes ensuring they take a break between Pomodoros. Another good practice is to consistently seek ways to break down complex problems into simple iterative tasks. Engineers are encouraged to automate out-of-existence extraneous load from repetitive manual tasks and to avoid context switching where possible. They will also strive to write clean code and adopt industry standards to ensure the success of future engineers who need to understand the logic. Engineers receive frequent feedback on their work during the code review process - feedback is important for validating the things we should commit to long-term memory which in turn will reduce future intrinsic load for the engineer.
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” - John Woods
The path of mastery in software engineering or any other vocation requires sufficient capacity during the working week for germane load - time to absorb domain and technical knowledge for schema formation in long-term memory. Hopefully, the ideas and language presented in this article will help to provide a deeper understanding of the needs of engineers and other cognitively heavy vocations and the need to tune the wider ecosystem to optimise the use of our cognitive capacities.
George Miller’s paper published in 1956, The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information is one of the most cited in Psychology.
John, thanks for the article.
Are you aware of some papers related to Cognitive Load in other areas than learning?
I know the Team Topologies stuff well, but I don't think there are more references to scientific work besides learning.
Thanks for this article, John. You've packed a lot in but it all hangs together really well. I can relate especially to the musical analogy and the idea of chunking 'bits' of information, such as chord tones or scale degrees, into shapes that we can easily grasp (in both senses of the word), that then become automated and intuitive. Likewise, with chess (can't imagine the context switching and stress involved in chess boxing!). This all has interesting parallels in the world of work.
Mastery is a fascinating subject, isn't it? I'm guessing you've read the late K Anders Ericsson's papers on mastery and his book 'Peak'. It's about time I revisited that. I'm going to look into Team Topologies. Thanks for the tip.