If pencil-before-keyboard is the principle, here's the actual mechanics. What does the paper work look like? What does a student actually draw? When does the keyboard come in?

This article walks through one worked example end to end, plus the three core tools Turing uses repeatedly.

The three tools

Three on-paper artefacts do almost all the work.

1. Pseudocode

Pseudocode is a description of the algorithm in structured plain language. It's closer to code than English, but not tied to any specific programming language. A simple pseudocode example:

BEGIN
    SET total TO 0
    FOR each number FROM 1 TO 10
        ADD number TO total
    END FOR
    OUTPUT total
END

Keywords (BEGIN, END, FOR, END FOR, SET, ADD, OUTPUT) give it structure. The student can read this aloud and understand exactly what should happen. It's also easy to translate to Python:

total = 0
for number in range(1, 11):
    total = total + number
print(total)

The pseudocode-to-Python translation is mechanical once both are familiar. The thinking happens at the pseudocode level.

2. Flowcharts

Flowcharts are pseudocode's visual cousin. Boxes for actions. Diamonds for decisions. Arrows for control flow. They're particularly good for problems with branching logic, where you'd otherwise need nested IF statements that get hard to read.

A flowchart for "is the user's input greater than 10?" is a sequence: Start → Get input → diamond asking "input > 10?" → YES branch prints "big", NO branch prints "small" → both branches converge at End. Drawing it forces the student to be explicit about where each branch goes.

For KS3 students, sketching the flowchart often clarifies branching they'd otherwise get wrong in code. It's worth the five minutes.

3. Dry-run tables

A dry-run table is where you pretend to be the computer. Columns for variables, rows for each step. You write down what each variable contains at each step. For a "sum 1 to 5" algorithm, the total column would tick through 0, 1, 3, 6, 10, 15 as the number column goes 1, 2, 3, 4, 5. Final answer: 15. If your trace doesn't match what you expected — bug found, before any code ran.

The worked example: FizzBuzz

FizzBuzz is the canonical KS3 problem for combining loops, conditionals, and modulus. The full problem:

Print the numbers from 1 to 30. But for multiples of 3, print "Fizz" instead. For multiples of 5, print "Buzz". For multiples of both 3 and 5, print "FizzBuzz".

A keyboard-first attempt usually fails. The student tries if i % 3 == 0: print("Fizz") then if i % 5 == 0: print("Buzz") and gets Fizz Buzz on a separate line for 15, instead of FizzBuzz. They scratch their head. They try something else. They guess.

A Turing-style session goes:

1. Decompose

What does the program need to do?

  • Loop through numbers 1 to 30.
  • For each number, decide what to print.
  • The decision has four cases: multiple of both 3 and 5 (print FizzBuzz), multiple of 3 only (Fizz), multiple of 5 only (Buzz), or neither (the number itself).

The decomposition has already surfaced the trick. The "multiple of both" case has to be checked first, before the individual checks. A student who plans this is much less likely to write the bug.

2. Draw the flowchart

In a real session the student sketches this on paper — a loop from i=1 to i=30, with a chained set of decision diamonds inside: first check i % 15 == 0 (print FizzBuzz), then i % 3 == 0 (print Fizz), then i % 5 == 0 (print Buzz), else print i. The visual order makes the "multiple of 15 must come first" rule obvious — you can see why splitting the FizzBuzz case out fixes the bug.

3. Pseudocode it

BEGIN
    FOR i FROM 1 TO 30
        IF i MOD 15 == 0 THEN
            OUTPUT "FizzBuzz"
        ELSE IF i MOD 3 == 0 THEN
            OUTPUT "Fizz"
        ELSE IF i MOD 5 == 0 THEN
            OUTPUT "Buzz"
        ELSE
            OUTPUT i
        END IF
    END FOR
END

4. Dry-run a few values

Don't dry-run all 30. Pick representative ones: 1 (none match), 3 (Fizz), 5 (Buzz), 15 (FizzBuzz), 30 (FizzBuzz). For each, walk through the conditionals in order and check the output. All five trace correctly — the algorithm works.

5. Translate to Python

for i in range(1, 31):
    if i % 15 == 0:
        print("FizzBuzz")
    elif i % 3 == 0:
        print("Fizz")
    elif i % 5 == 0:
        print("Buzz")
    else:
        print(i)

This works first time. The student understands every line. They could write a variant tomorrow (different range, different multiples) without help.

Total time: maybe twelve minutes. Compare to twenty minutes of keyboard guessing, ending in working code the student doesn't fully understand.

What Turing does when the dry run fails

When a dry run shows the algorithm doesn't work, the fix happens on paper, not in code. The student amends the flowchart, re-traces, and only moves to Python when the paper version is right. This is the loop most KS3 students never form. Their default is run code → tweak randomly → run again. The Turing-trained loop is trace → spot logical error → fix algorithm → re-trace → translate. The second builds understanding. The first builds frustration.

When to drop the paper

The paper work isn't permanent scaffolding. After two or three weeks of pencil-first sessions, most KS3 students start doing the planning mentally. The flowchart still exists — in their head. The dry run still happens — quickly, internally. The keyboard becomes fast again, but with the thinking baked in.

This transition is the goal. The paper isn't there to be drawn forever. It's there to install the habits that make drawing unnecessary.

Jason runs aitutors.me. He has a Year 8 child and about fifteen years of building software adjacent to education. Updated 21 May 2026.