Daniel came in on a Tuesday with his mum. He was nine | small for his age, very serious about Minecraft, and entirely convinced that making his own game was something that grown-up programmers did in dark offices after many years of suffering. He was about to become one fewer person who believed that.

He'd never written a line of code. The closest he'd come was following a YouTube tutorial for a Roblox game mod, which had worked | sort of | until an update broke it and he couldn't figure out why. That experience had left him suspicious of code. It felt like a thing that worked until it didn't, and he didn't yet know how to tell the difference.

His first session was disarmingly simple. His mentor, Tunde, didn't load up any tutorials or start explaining syntax. He asked Daniel one question: "If you were going to make the best game you could imagine, what would happen in the first ten seconds?"

Daniel thought about it. "You'd jump off a platform," he said. "And there'd be spikes. And if you hit the spikes, you'd restart."

"Okay," said Tunde. "Let's build that."

Session by Session: How It Actually Happened

Session0-1 | Week 1
The Sprite Moves. The World Begins.
Daniel built his first sprite | a white square he named "Guy" | and made it move left and right with arrow keys. Just that. At the end of the session, he pressed the right arrow key and Guy slid smoothly across the screen. Daniel stared at it for a moment, then quietly said: "That's sick." That's the moment. Every STEMulus mentor knows that moment.
Session0-203 | Week 2
Gravity Is a Bug Until You Write It.
Guy could move side to side. But he floated in the air like he'd never heard of physics. Daniel needed to understand that gravity is not automatic | it's a rule you write. His mentor introduced the concept of a variable: "y_velocity." Every frame, y_velocity increases by a small number (gravity), and Guy falls by that amount | until he lands on a platform. Daniel's face when he ran the code and Guy actually fell and landed | and stayed landed | was something else entirely.
Session0-405 | Week 3
Spikes. Logic. The Conditional.
Daniel wanted the spikes. So his mentor introduced conditionals | the if/then structure that is the backbone of all decision-making in code. If Guy touches a spike, then reset his position. Daniel immediately wanted the spikes to also play a sound, change the score, and flash the screen red. His mentor let him build every single one of those features. Debugging the reset position took most of session 5. Daniel didn't give up once.
Session0-607 | Week 4
Levels. Loops. The Game Becomes a Game.
They introduced a second level, then a third. Daniel designed the layout of each level himself | sketching it on paper first ("old school architecture," his mentor called it) and then building it block by block. He built a score counter, a timer, and a "You Win" screen with animated confetti. The confetti was his idea. He found a way to make 30 copies of a small dot sprite and randomise their direction. He'd discovered cloning.
Session0-8 | Week 5
He Tests. He Ships.
The final session was spent testing and polishing. Daniel played through his own game seventeen times | not to enjoy it (though he clearly did), but to find every bug. He adjusted the spike hitboxes. He tweaked the jump height. He added a pause menu because "the player might need a break." At 5:47pm, he pressed the green flag one final time, played through all three levels without dying, and looked up at his mentor. "It's done," he said. "It actually works."

What This Proves

Daniel is not exceptional in the way people mean when they say "exceptional." He's not a child prodigy with a parent who codes. He's a nine-year-old who likes Minecraft, gets bored in double maths, and is very particular about which biscuits are worth eating. What he is | and what most children are if given the right conditions | is capable.

What made the difference wasn't the platform (though Scratch is excellent). It wasn't the number of sessions (though 8 sessions are a true learning adventure). It was the structure of the learning. A single mentor. A single project goal defined by the student. No templates to copy. No answers handed over. Just questions | "what do you want to happen next?" | and the space to figure it out.

When you give a child ownership of what they're building, something changes. It's not a school project anymore. It's theirs. They care about it in the same way you care about something you've made with your own hands. That's when the magic learning happens | fast, deep, and lasting.

Where Is Daniel Now?

Three months after that first session, Daniel is building his second game | this time in Python, using Pygame. He's twelve sessions in. The game involves procedurally-generated dungeons and an enemy that "actually thinks," which turns out to be a very enthusiastic way of describing a basic pathfinding algorithm. His mum says he now explains his code to the family at dinner.

His younger sister, who is seven, has asked if she can start too. She starts next month.