The Problem Isn't
the Code.
After 30+ years in software engineering, I've watched the same failure repeat: students who can write code but cannot see what it does.
This page explains the root psychological cause I identified — and the four-method framework I built to fix it permanently.
The science behind how I teach
Visualisation isn't a learning style. It's how engineering actually works.
Before my students can build complex systems, I need them to see those systems — not metaphorically, but neurologically. The research I base my teaching on is unambiguous: the engineers who succeed are not the ones who memorise the most syntax. They are the ones who can hold a living model of a system in their mind and manipulate it. That ability has a name, a mechanism, and — crucially — it can be taught. That is what I set out to do.
r = 0.57
Correlation between spatial reasoning and programming success in advanced students
Jones & Burnett, 2008
200+
Studies confirming spatial skills are trainable at any age, gender, or background
Uttal et al. meta-analysis
4 – 7
Items working memory can hold at once before cognitive overload sets in
Miller, 1956
01
Working memory has a hard limit. I teach students to work around it.
John Sweller's foundational research established that working memory can only hold between four and seven items at once. A 200-line codebase is not four items — it is hundreds. In my experience, this is exactly where most students collapse. I teach them to compress code into mental "chunks" called schemas — the same technique expert engineers use instinctively. Once a student can draw a database connection as a single block rather than 20 lines of configuration, their working memory is freed to think about the architecture. That is the breakthrough I am working toward with every student.
02
I teach every concept twice — once in language, once as a physical model.
Allan Paivio's Dual Coding Theory showed that humans process verbal and visual information through separate cognitive channels — and that engaging both simultaneously dramatically strengthens retention. I noticed early in my teaching career that traditional programming education only uses one channel: read the documentation, memorise the syntax, type the code. That is why students forget. In my classroom, I encode every concept twice. A function becomes a factory machine. An API becomes a loading dock. Data becomes a product moving down a conveyor belt. Both channels fire. Both retain.
03
I train spatial ability — because research proves it directly improves programming.
Research across multiple ACM computing education conferences has established a consistent finding: students with stronger spatial reasoning perform significantly better in programming, and the correlation grows stronger as courses advance. The discovery that changed how I teach — confirmed by a meta-analysis of over 200 studies — is that spatial skills are not fixed. They are malleable. Anyone can develop them, regardless of age, gender, prior experience, or background. This is not a talent you either have or don't. It is a skill I can develop in you. Every exercise in my programme is designed to do exactly that.
Imagine sitting in front of a new codebase — one you have never seen — and instead of feeling overwhelmed, you immediately begin to see the shape of it. The data flows. The system boundaries. The places where things could break.
That is not a gift given to a few. It is a trained capacity. And it is exactly what I will give you in this programme.
The Diagnosis
What I see when my students struggle.
After three decades of teaching and building software, I have identified three specific cognitive failures that cause the visualisation problem. None of them are talent gaps. All of them are fixable.
01
Declarative vs. Procedural Knowledge
My students can tell me what an if-statement is. But when I ask them to trace how data moves through a live system, they freeze. Facts are sitting in their memory as isolated entries — not connected into a living, moving process. I call this the "syntax trap."
02
Absent Spatial Reasoning
Engineering is fundamentally 3D problem-solving on a 2D screen. When I teach a Class or an API endpoint, I watch students trying to hold every abstract detail in working memory at once — and failing. Without a physical metaphor to anchor the concept, the brain has nowhere to put it.
03
No Schema for System State
When I look at a codebase, I see a small number of large blocks. My students see hundreds of individual lines. They are examining atoms while I am looking at the engine. I have spent years developing methods to close that gap — to give students the chunking ability that experts build over decades.
“If this code were a factory machine, what would happen if you threw a wrench into this specific part?”
The question I ask every student before they touch the keyboard
My Method
Four techniques I use to build genuine visualisation.
Each method below targets one of the three cognitive failures I described above. Together, they move my students from typing syntax to modelling systems — and the shift is permanent.
I require a blueprint before the IDE opens
Every student must submit a hand-drawn system diagram — a flowchart or sequence map — before they open any code editor. My rule is simple: if you can't draw the plumbing, you aren't allowed to turn on the water. This forces their brain into spatial reasoning mode rather than linguistic memory mode. I have seen this single requirement transform how students approach problems.
I hide the code and ask them to find the machine
I give my students working software with the code completely hidden. They observe the inputs and outputs, then draw what they believe the internal machine looks like. The gap between their drawing and the actual code is where I do my most powerful teaching. That moment of surprise — "oh, that's how it actually works" — is the deepest learning I have ever witnessed.
I map every concept to a physical factory analogy
In my classroom, variables are storage bins, functions are assembly machines, APIs are loading docks, and data is a product moving down a conveyor belt. I arrived at these analogies after years of watching students struggle with abstraction. When I give the brain a physical hook — something it can picture and manipulate — the abstract concept clicks into place permanently.
I make my students act out the code
I call this Whiteboard Debugging. One student becomes the variable, another becomes the function. They physically pass "data" — a piece of paper — to each other as the programme runs. When you live inside the flow rather than watching it from outside, the logic stops being abstract. It becomes a physical memory. I have never seen a student forget a concept they have acted out.
Before vs. After
How my students change the way they think.
| Before my programme | After my programme | |
|---|---|---|
| Starting point | Open the IDE and start typing | Draw the data flow on paper first |
| Focus | Memorising keywords and syntax rules | Mapping the machine and its components |
| Error handling | Panic at red squiggles in the IDE | Finding where my conveyor belt is stuck |
| Success metric | "The code runs." | "I can explain the transformation of data." |
| Errors mean | I am failing. I am doing it wrong. | My diagnostic sensors are giving me feedback |
Why I believe this matters more than ever
In the AI era, visualisation is the skill.
I have watched the bottleneck shift in real time. Speed is no longer the constraint. The ability to verify, debug, and understand is.
AI writes. My students learn to verify.
If my students cannot visualise what code should do, they cannot catch what AI generates incorrectly. I teach them to be the reviewer — the human in the loop who understands the machine well enough to catch the 20% that AI gets wrong.
Legacy systems cannot be prompted away.
I have worked with systems that are 16+ years old. AI cannot know their history, their constraints, or their technical debt. Only an engineer with a strong mental model can make the architectural calls that protect a business. That engineer is who I am training.
Logic is the 10% I am teaching.
Syntax is now a commodity. The skill I am building in my students — decomposing a problem, anticipating edge cases, tracing a broken system — is exactly what employers cannot automate and will not stop paying for.
In the age of AI, your value is no longer measured by the code you write, but by the logic you can defend.
The Beyond Syntax Philosophy
Selective 2026 Cohort — Limited Seats
Ready to learn
to see the machine?
I am forming a small, high-calibre cohort for 2026. I review every application personally. If I believe you are ready to make this shift, you will receive a personal invitation from me.
Apply Now — Limited Seats →Already invited? Sign in here