Teach programming well: diagnose novice misconceptions, use PRIMM, pair programming and Parsons problems, plan standards-aligned units, assess code fairly and navigate teacher certification.

Teaching Computer Science

## Why it matters

When a student's program is wrong, it is tempting to fix the line and move on. But most novice errors are not typos: they come from a consistent, wrong mental model of how the computer works. Fix the line and the model stays; the same error comes back next week in a different form. Good CS teachers learn to read a wrong answer as evidence of **what the student believes**, then target that belief.

## The core idea: notional machines

Researchers use the term **notional machine** for the simplified model of the computer that a teacher wants students to hold: "a variable is a named box holding one value", "the program runs one line at a time, top to bottom, unless a loop or call sends it elsewhere". Misconceptions are gaps or errors in that model. Making the notional machine explicit (with diagrams, tracing tables and visualisers) is one of the most effective things you can do.

## Common misconceptions and how they show up

| Misconception | What the student believes | Typical evidence |
|---|---|---|
| **Assignment as equation** | `a = b` links `a` and `b` forever | expects `a` to change when `b` changes later |
| **Variables hold history** | a variable remembers all its past values | traces show several values in one box |
| **Order does not matter** | the computer reads the whole program and "understands" it | uses a variable before assigning it |
| **The computer knows what I mean** | names carry meaning (`largest` will find the largest) | names a variable and expects behaviour |
| **Print equals return** | showing a value is the same as giving it back | function prints but caller gets `None` |
| **`if` loops** | an `if` repeats like `while` | expects an `if` body to run many times |
| **Loop runs once more / less** | unclear about where `range` stops | off-by-one errors on boundaries |
| **`=` vs `==`** | the symbols are interchangeable | assignment inside a condition (in languages that allow it) |

## Worked example: diagnosing from code

A student writes this to swap two values:

```python
a = 5
b = 9
a = b
b = a
print(a, b)   # student expects: 9 5
```

The output is `9 9`. Possible beliefs behind it:

1. **Assignment as equation or simultaneous:** the student thinks both lines happen "at once", like swapping in maths.
2. **Variables hold history:** they think `a` still "remembers" 5 after `a = b`.

A good diagnostic question separates them: *"After line 3, what is in `a`? Is 5 stored anywhere?"* A student who says "5 is still in `a` as well" has the history misconception. Then you address the model, not just the code: trace line by line in a table, one row per line, one column per variable.

| line | a | b |
|---|---|---|
| 1 | 5 | - |
| 2 | 5 | 9 |
| 3 | 9 | 9 |
| 4 | 9 | 9 |

Only after the model is fixed do you introduce a temporary variable (`temp = a`).

## Worked example: print vs return

```python
def double(n):
    print(n * 2)

result = double(4) + 1
```

The program shows `8` and then crashes with `TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'`. The student is confused: "But it printed 8!" The misconception is that printing gives a value back. Ask: *"Where does 8 go when it is printed? Where does the value go when it is returned?"* A picture of the screen versus the caller helps.

## Teaching moves that help

- **Predict before run.** Ask students to predict output before running code. Wrong predictions surface misconceptions quickly.
- **Trace tables and visualisers.** Python Tutor (pythontutor.com) shows variables and frames step by step.
- **Diagnostic multiple-choice questions** where each wrong answer matches a known misconception, so the choice tells you the belief.
- **Refutation.** Show a case where the wrong model predicts something different from what happens, then explain why.

## Common mistakes (for teachers)

- **Fixing the code for the student.** You remove the evidence and keep the misconception.
- **Assuming it is carelessness.** Consistent errors usually mean a consistent model.
- **Explaining with too much abstraction.** "Memory addresses" can confuse beginners; start with boxes and arrows.
- **Ignoring language effects.** `=` reads as "equals" in maths. Say "gets" or "is assigned" aloud.

## Quick recap

- Most novice errors come from wrong mental models, not typos.
- Make the notional machine explicit with tracing tables and visualisers.
- Learn the common misconceptions: assignment as equation, print vs return, `if` as loop, off-by-one.
- Diagnose with targeted questions and predictions before you correct.


Recognise the most common novice programming misconceptions and diagnose them from a student's code.

Common novice misconceptions

"How to teach programming (and other things)?" by Felienne Hermans

Java NM - Example 1: Two int variables are independent and do not become linked

Write one learning objective in student language, such as 'I can predict how many times a for loop runs'.

Write a short Predict program (5-10 lines) that uses the concept, and the question students answer before running it.

Plan Run: how students will run it (a free online editor or the school's tool) and compare output with their prediction.

Write three Investigate questions that make students trace, annotate or change one value and explain the effect.

Write a Modify task that changes the program's behaviour slightly (for example, count down instead of up).

Write a Make task that uses the concept in a new program, with an extension for fast finishers.

Decide which stages are done in pairs. Write the driver/navigator role cards and when students swap (every 5-10 minutes).

Add timings for each stage so the plan fits 50 minutes, and one exit question to check the objective.

## Why it matters

Many beginner programming lessons jump straight to "write a program that...". For novices this is like asking someone to write an essay in a language they have only heard spoken. They stare at a blank editor, copy something from the internet, or give up. Two well-researched approaches give students a gentler, more structured path: **PRIMM** for lesson structure and **pair programming** for collaboration.

## PRIMM: read before you write

PRIMM was developed by Sue Sentance and colleagues in England. It moves students from reading code to writing it in five stages:

| Stage | Students... | Teacher's role |
|---|---|---|
| **Predict** | read a short program and predict its output, without running it | choose code that uses the new concept in a familiar context |
| **Run** | run it and compare with their prediction | discuss surprises; misconceptions surface here |
| **Investigate** | trace, annotate, answer questions, change one thing and observe | ask targeted questions about each line |
| **Modify** | change the program to do something slightly different | scaffold from small to larger changes |
| **Make** | write a new program that uses the concept | provide a clear task and an extension |

The key idea is that **reading and understanding code comes before writing it**. Students get a working example to reason about, so their first experience is success, not a blank screen. The approach also gives you natural checkpoints: if many predictions are wrong, you stay longer on Investigate.

## Worked example: a PRIMM lesson on `for` loops

**Predict:**

```python
total = 0
for n in range(1, 4):
    total = total + n
print(total)
```

"What will this print? Write your answer before running it." Common predictions: 6 (correct), 10 (thinking `range` includes 4), or 3 (thinking the loop runs once).

**Run:** students run it and compare. Discuss why `range(1, 4)` gives 1, 2, 3.

**Investigate:**
1. Add a `print(n, total)` inside the loop. What do you see?
2. What would `range(1, 6)` print? Predict, then check.
3. What happens if `total = 0` is moved inside the loop? Why?

**Modify:** make it add only even numbers from 2 to 10.

**Make:** write a program that multiplies the numbers 1 to 5 (5 factorial), then an extension: ask the user for `n`.

## Pair programming: two people, one problem

In **pair programming**, two students work on one computer:

- The **driver** types and focuses on the current line.
- The **navigator** reads, checks, thinks ahead and suggests.
- They **swap roles** regularly, often every 5-10 minutes, with a timer.

Studies in university and school settings have linked pair programming with better completion rates, more confidence and better retention, including for students under-represented in computing. It also reduces the number of "I'm stuck" hands, because pairs solve many problems themselves.

## Making pairing work

Pairing fails when one student does everything. Structure helps:

- **Role cards** on the desk describing what each role does and says.
- **A visible timer** and a clear signal to swap.
- **Talk norms:** the navigator suggests, does not grab the keyboard; the driver explains what they are typing.
- **Thoughtful pairing:** pair students of similar confidence where possible, and change pairs between units.
- **Individual accountability:** short individual exit questions so you can still see what each student understands.

PRIMM and pairing combine well: pairs predict and investigate together, then each student does a short individual Make task.

## Common mistakes

- **Skipping Predict.** Running code first removes the moment where misconceptions show.
- **Investigate questions that only ask "what does it print?"** Ask "why?" and "what if?" too.
- **Unstructured pairs.** Without roles and swaps, the more confident student drives the whole time.
- **No individual check.** Pairs can hide a student who has not understood.

## Quick recap

- PRIMM = Predict, Run, Investigate, Modify, Make: read and reason about code before writing it.
- Predictions surface misconceptions; Investigate questions deepen understanding.
- Pair programming uses driver and navigator roles with regular swaps.
- Structure pairing with role cards, timers and individual exit checks.

## Try it

Open the Do tab and plan a 50-minute PRIMM lesson that uses pair programming.


Plan a PRIMM lesson and run structured pair programming with clear roles.

PRIMM and pair programming

reWatch: PRIMM for Teaching Programming w/ Andy Colley

Teaching CS Fundamentals: Pair Programming

## Why it matters

Writing a program from scratch asks a novice to do many things at once: recall syntax, choose a plan, remember variable names, and track what the code does. **Cognitive load theory** explains why that overloads beginners: working memory can hold only a few new items at a time. Two techniques with strong research support reduce that load while keeping students thinking: **worked examples** and **Parsons problems**.

## Worked examples

A **worked example** is a complete, step-by-step solution that students study before solving similar problems themselves. Research across maths and programming (often called the *worked-example effect*) shows that beginners learn more from studying good examples than from solving the same number of problems unaided.

Make worked examples more effective by:

- **Pairing each example with a practice problem** that has the same structure but a different context.
- **Subgoal labels:** short headings that name the purpose of each chunk of code. Lauren Margulieux and colleagues found that labelled examples improve transfer to new problems.
- **Fading:** first a full example, then one with a step missing, then two, until students write the whole thing.
- **Self-explanation prompts:** "Why does this line come before the loop?"

```python
# Subgoal: set up a counter
count = 0
# Subgoal: look at each item
for score in scores:
    # Subgoal: test the condition
    if score >= 50:
        # Subgoal: update the counter
        count = count + 1
# Subgoal: report the result
print(count)
```

The subgoals ("set up a counter, look at each item, test, update, report") are a reusable plan students can apply to "count the words longer than five letters" next.

## Parsons problems

A **Parsons problem** (introduced by Dale Parsons and Patricia Haden in 2006) gives students the correct lines of a program in scrambled order. Students drag them into the right order and, in some versions, the right indentation.

Why they work:

- Students focus on **logic and order**, not syntax recall or typing.
- Every attempt uses correct syntax, so they see good code.
- They are quick to solve and quick to check automatically.
- Barbara Ericson's research found Parsons problems can produce similar learning to writing the same code, in less time.

Variations:

- **Distractors:** extra lines that are plausible but wrong (an off-by-one `range`, `=` instead of `==`). Choose distractors that match common misconceptions, so a wrong choice is diagnostic.
- **Indentation required:** students must also indent correctly, which tests understanding of blocks.
- **Faded Parsons:** some lines have blanks to fill in, as a bridge to writing code.
- **Adaptive Parsons:** the tool combines blocks or removes distractors after repeated failures (Runestone Academy supports this).

## Worked example: designing a Parsons problem

Goal: practise the accumulator pattern.

1. Write a correct solution of 5-8 lines (longer ones get frustrating).
2. Split it into blocks, one line each (or two lines that always go together).
3. Add one or two distractors based on misconceptions you have seen: for example `count = 0` inside the loop.
4. Decide whether indentation is part of the puzzle.
5. Write the checking rule: exact order, or any order that produces correct output (some lines can be swapped legally).
6. Test it on a colleague and time it: 2-5 minutes is a good target.

Free tools include Runestone Academy and js-parsons; you can also do them on paper strips.

## Common mistakes

- **Examples without practice.** Studying examples helps only when followed by similar problems.
- **Too many distractors.** One or two is enough; more turns the puzzle into guesswork.
- **Only one correct order when others work.** If two lines can be swapped, accept both or redesign.
- **Using Parsons forever.** They are a bridge. Fade toward writing code independently.

## Quick recap

- Beginners have limited working memory; worked examples and Parsons problems reduce load.
- Use subgoal labels, fading and self-explanation with worked examples.
- Parsons problems scramble correct code; distractors should match real misconceptions.
- Keep puzzles short, check alternate valid orders, and fade toward independent writing.

## Try it

Open the Do tab: solve a Parsons problem, add a distractor and write the shuffle and grading functions.


Use worked examples, subgoal labels and Parsons problems to reduce cognitive load for novice programmers.

Parsons problems and worked examples

Teaching coding: What is a Parsons problem?

Worked Examples | A Simple Way To Accelerate Student Learning

Diagnose common novice misconceptions, plan lessons with PRIMM and pair programming, and use Parsons problems and worked examples.