Cognitive load

Why it matters

New learners often get lost not because the topic is too hard, but because the lesson asks them to juggle too much at once: a new tool, new vocabulary, a busy slide and a fast talker. Cognitive load theory explains why, and it gives you concrete ways to simplify a lesson without dumbing it down.

Working memory is small

Information you are actively thinking about sits in working memoryThe small store that holds what you are actively thinking about, only a few new items at a time., which can hold only a handful of new items at a time. George Miller (1956) famously suggested "seven, plus or minus two"; later work by Nelson Cowan (2001) suggests about four chunks for new material. Long-term memory, by contrast, is huge. Experts are not people with bigger working memories; they have organized knowledge in long-term memory (schemas) that lets them treat many details as one chunk.

When you type git commit -m "Fix login", you see one action. A beginner sees a program name, a sub-command, a flag, quotation marks and a message, each of which needs attention.

Three kinds of load

John Sweller developed cognitive load theory in the late 1980s. It separates:

• Intrinsic loadDifficulty that comes from the material itself, such as how many elements interact.: the difficulty that comes from the material itself, such as how many elements interact. Merging branches has more interacting parts than making a commit.
• Extraneous loadEffort spent on things that do not help learning, such as decoding a cluttered slide.: effort spent on things that do not help learning, such as decoding a cluttered slide, hunting for the right window, or reading text while also listening to different words.
• Germane load (in older versions of the theory): effort spent building schemas. Recent versions fold this into intrinsic load, but the idea remains: you want learners' effort going into the material, not into the packaging.

The design rule is simple: cut extraneous load, and manage intrinsic load by sequencing.

The worked example effect

For novices, studying a fully worked example usually beats solving the same problem unaided. Sweller and Graham Cooper (1985) showed this with algebra, and it has been replicated many times. A beginner solving a problem from scratch spends working memory searching for a method; a worked example shows the method, so the effort goes into understanding it.

A worked example for Git might look like this:

# Goal: start new work without touching main
git switch main          # 1. start from the up-to-date main branch
git pull                 # 2. get the latest changes
git switch -c fix-login  # 3. create and switch to a new branch
# ...edit files...
git add login.js         # 4. stage the change
git commit -m "Fix login redirect"  # 5. record it

Each step has a comment saying why, not just what. Richard Catrambone's work on subgoal labels found that naming the purpose of each group of steps helps learners transfer the method to new problems.

Fading

Do not stop at examples. Alexander Renkl and colleagues found that faded worked examplesA series of examples that leave out more steps each time for the learner to fill in., where later examples leave out more steps for the learner to fill in, ease the move to independent problem solving. Example 1 is complete; example 2 leaves out step 3; example 3 leaves out steps 3 to 5; then learners solve a full problem.

The expertise reversal effect

What helps novices can hurt experts. Slava Kalyuga and colleagues (2003) found that detailed guidance which benefits beginners becomes redundant for more experienced learners and can even make their learning worse. Experienced developers in your Git workshop will be bored and slowed by step-by-step examples of git commit; give them problems sooner. This is one reason a quick pre-assessment is worth the time.

Simplifying a lesson: a before and after

Before: one slide with eight bullet points about branching, a screenshot of a terminal in small font, a live demo in a different window while the trainer explains merge strategies, and then "now try it on your own project".

After:

1. One idea per slide: "A branch is a movable label on a commit", with a single simple diagram.
2. Demo in a large font, in the same window learners will use, narrating only what is on screen.
3. A worked example handout with subgoal labels.
4. Two faded examples in a practice repository with no other files to distract.
5. Only then: try it on your own project.

Same content, far less load.

Other load reducers

• Split attention: put labels on the diagram instead of in a legend learners must match up.
• Redundancy: do not read out the exact text on a slide while learners read it; say it or show it.
• Pre-training: teach key terms (commit, branch, HEAD) before the process that uses them.
• Segmenting: break a long demo into short chunks with a pause and a question between each.

Common mistakes

• Making slides "engaging" with decorative images, animations and background music that add extraneous load.
• Giving novices open-ended discovery tasks before they have any schema to work with.
• Keeping detailed scaffolding for learners who no longer need it.

Quick recap

• Working memory is tiny for new information; long-term memory is not.
• Cut extraneous load; sequence intrinsic load.
• Novices learn well from worked examples, then faded examples, then problems.
• Guidance should shrink as expertise grows (expertise reversal).

Try it

Answer the quiz on the Do tab, then pick one slide or handout you have made and list two things you could remove or move to reduce extraneous load.