Does my child need a computer to use Prof Turing?

For some sessions yes, but a surprising amount of his teaching happens with pen and paper. Algorithm design, dry runs, tracing through code logically — none of that requires a keyboard. When code does need to be typed, any free Python environment works (most schools use either Repl.it or Thonny; both are fine).

Is this about Python specifically, or computing more broadly?

Both. Python is the de facto KS3 programming language in UK schools, so Turing uses it for code work. But computing isn't just programming — there's also data representation (binary, hex), computer systems (hardware, the CPU cycle), networks, and ethics. Turing covers all of these, with the same 'understand before do' philosophy.

Won't pencil-before-keyboard slow my child down?

Yes, deliberately, and only at first. A student who draws an algorithm before coding it spends an extra five minutes per problem early on and saves ten minutes per bug later. After a month the upfront thinking takes 30 seconds and the bug rate has dropped sharply. The slow start is the investment.

My child is already coding well at school. Will Turing still help?

Yes — the level just shifts. For a confident KS3 programmer Turing will work on harder algorithms, better debugging discipline, computational thinking applied to non-trivial problems, and conceptual depth (why binary, why floating point is weird, what abstraction really means). The pencil-first principle still applies; it just goes faster.

Meet Prof Turing: Pencil Before Keyboard, Always

If you watch a Year 8 student trying to write a Python program without much guidance, you'll usually see the same thing. They open the code editor. They type a line. They run it. It doesn't work. They change a character. Run it again. Tweak. Run. Tweak. Run.

This is what professional programmers call programming by guess. It works, sort of, for very simple problems and stops working completely for anything that needs more than a few lines of logic. By the time a student is in Year 10 it's a real handicap. And it's not their fault — KS3 computing in most UK schools has become so Python-heavy that the thinking step underneath has quietly disappeared.

Prof Turing was built to put the thinking step back. Named after Alan Turing, who did most of his actual work with a pencil. The teaching principle is one line long: no code is typed until the algorithm is drawn on paper.

What "computational thinking" actually means

Before the pencil work makes sense, it's worth saying what computational thinking is. The standard four pillars, which appear in every KS3 computing scheme of work and which Turing references constantly:

Decomposition. Breaking a problem into smaller parts. "Make breakfast" is too big. "Boil the kettle, get the bread, put the bread in the toaster" is workable.
Pattern recognition. Spotting where you've seen something similar before. "This looks like a counting loop, like the one I wrote last week."
Abstraction. Stripping away detail to see what matters. "For this problem, I don't care what colour the user's screen is. I just need their input."
Algorithm design. Planning the steps in order, with the right control flow.

These are described as the building blocks of computer science, but they're really just good problem-solving. A child who can decompose, spot patterns, abstract, and plan can do much more than write Python — they can write essays, design experiments, organise revision. Computing happens to be the subject where these are taught explicitly.

What a Turing session looks like

A typical session opens with a problem statement, not a code editor. For example: write a program that asks the user for ten numbers and tells them the average.

A keyboard-first session would dive into Python immediately. A Turing session goes:

Decompose. What are the steps? Read input ten times. Add them up. Divide by ten. Print the result. The student writes these in plain English.
Plan the algorithm. What needs to be remembered? (A running total. A count of how many we've read.) What's the structure? (A loop that runs ten times.) The student writes pseudocode or draws a flowchart.
Dry run. Pretend to be the computer. Take three or four fake inputs. Trace through the algorithm by hand. Does the answer come out right? Is the count actually ten or is it nine? (Off-by-one errors get caught here, before any code exists.)
Translate to Python. Now, and only now, the keyboard. The student writes the code. Because they planned it, the code usually works first time.
Test edge cases. What happens if the user inputs zero? What if they put a non-number? These would have been hidden by guess-programming; the planning surfaces them.

A 25-minute session might produce a 10-line Python program. That's fine. The 10 lines work, the student understands every line, and they could write a similar program tomorrow without help. Better than 30 lines of broken code they don't really own.

Why pencil-before-keyboard works

A few reasons.

The keyboard is too fast. Typing is so quick that you can act before you think. Drawing is slow enough to force a pause. The pause is where the thinking happens.

Errors are cheap on paper. Crossing out a line on a flowchart costs nothing. Running broken Python ten times costs frustration and confidence. Pulling the thinking out of the editor is, paradoxically, what makes the editor productive.

It exposes assumptions. When you write for i in range(10) you might think "this runs ten times, starting at 1". When you draw the algorithm and dry-run it, you discover range(10) actually goes 0 to 9. The misconception gets caught before the bug, not after.

It builds reusable thinking. The student who plans before coding develops habits they'll use in any programming language, in any computing context. The student who types-and-tweaks has built a habit specific to one Python environment.

The three artefacts Turing uses most

Three on-paper tools do most of the work.

Pseudocode. A description of the algorithm in plain language, with structure (BEGIN/END, FOR/END FOR, IF/THEN). Closer to code than English but not language-specific.
Flowcharts. Boxes and arrows showing decisions and loops. Best for branching logic. Most KS3 students intuit these fast once they've seen a few.
Dry-run tables. Columns for each variable, rows for each step. You trace through the algorithm by hand and write what each variable becomes at each step.

All three are taught explicitly. (See the next article: Algorithms drawn out.)

Tone modes

Like every faculty agent, Turing adapts to the energy level set by the Mentor. Green sessions are for harder algorithms, debugging real bugs, exploring new concepts. Amber sessions stick to one small problem with lots of dry-run support. Red sessions are homework triage — just enough to get the next thing done.

Turing-specific signal: he watches whether the student is reasoning forward (planning before doing) or guessing (changing things until they work). If guessing-mode kicks in he'll gently interrupt and pull back to the algorithm.

What Turing isn't

Worth saying clearly.

Not a Python textbook. He'll teach syntax as it's needed, but the focus is the thinking. A student who finishes a year with Turing won't have memorised every Python method — they'll have learned how to think about problems.
Not a homework completer. If your child brings a homework problem, he'll walk them through the planning, but they'll write the code themselves. The point is capability.
Not Scratch. Some KS3 schools still teach Scratch in Year 7. Turing focuses on Python and computational thinking. He can talk Scratch concepts but it's not where his time goes.
Not vibe coding. "Vibe coding" — letting an AI write code for you while you watch — is the opposite of what Turing does. It's also a habit that quietly destroys programming ability for students who form it early. He pushes hard against it.

What KS3 computing teachers will recognise

If you're a UK computing teacher reading this, you'll notice the methodology lines up well with the National Curriculum and the BCS guidance — pseudocode, flowcharts, dry runs, computational thinking, focused on understanding before doing. None of this is exotic. It's the right way, applied consistently.

The thing AI tutoring adds is patience. A teacher with a class of thirty can't sit with every student through a hand-drawn algorithm. An AI tutor can. That's the gap aitutors.me is built into.

What to expect as a parent

If your child has had a Turing session and you ask what they did, the answer should reference the thinking, not just the code. "We drew the algorithm" or "I dry-ran it before I coded it" is the signal that the session worked. "I wrote some Python" without any reference to planning is the signal that something slipped.

You may also notice your child becoming slower to type code and faster to talk through problems. That's the design working. The fast typing comes back, with the bugs subtracted.

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