How to Teach Computational Thinking to Kids (Ages 8–10): #1 Sequencing

She wanted to build a Sherlock Holmes mystery. We built a construction site instead. Here’s what happened.

My nine-year-old daughter Sabi was sitting across from me at her study table, genuinely annoyed.

“But WHY can’t I just build the Sherlock Holmes game?”

She had an entire mystery mapped out in her head( clues, suspects, a big reveal) and I was asking her to build something simpler first. The disappointment was real. She slumped back in her chair and stared at the ceiling.

I didn’t blame her. It was a great idea. It was just the wrong idea for day one.

Start with life, not logic

I opened with her morning routine, not theory.

Sequencing, I told her, is just the idea that order matters. Can you brush your teeth before you put toothpaste on the brush? Can you wear your shoes before your socks?

She laughed. Obviously not.

That’s sequencing. Order matters. Do things in the wrong order and the whole thing falls apart. Not because you did the wrong thing, but because you did the right thing at the wrong time.

That’s the thing about sequencing: kids already know it. They just don’t have the vocabulary. Once you name it, it clicks.

We went through a few more examples together. A recipe: you don’t put the cake in the oven before you’ve mixed the batter. A building: you don’t paint the walls before you’ve put them up. Getting dressed: you don’t put a jumper on before your shirt.

How she chose what to build

Once she understood the concept, I gave her the challenge: design a game that uses sequencing. Your rules, your theme, your design.

One condition: think it through first. Write it down before we build anything. The Google Doc is the algorithm.

Her first idea arrived immediately. A Sherlock Holmes mystery. She was off: mapping clues, sketching suspects, planning a dramatic reveal. The energy was great. The ambition was real.

And it was entirely wrong for day one.

Building a mystery game well requires things she didn’t have yet: conditional logic, narrative branching, deductive structure. She’d be trying to build a roof before the walls were up — which, as it turned out, was rather on theme for what came next.

I didn’t shut it down. I told her: this is a great game. We are going to build this game. But not today. You need more tools first and we’re going to get them one at a time. We put it in the backlog.

Then I asked her: think of something from real life. Something with steps that genuinely have to happen in a fixed order. Something where if you get the sequence wrong, it’s visibly, obviously broken.

She didn’t have to think long. We’d recently finished a house renovation.

The design doc and unexpected variables

She decided to build a construction game. You’re building a house. Complete each phase in the right order or the whole thing falls apart. She started writing down steps, foundation, walls, roof, but quickly got stuck. 

She didn’t know the nuances: what actually happens between laying the foundation and putting up the walls? What comes before the roof and what comes after? The sequence had gaps and she knew it.

So she stopped. She ppened a tab, read about how buildings are actually constructed and then came back 20 minutes later with a refined list.

It wasn’t just a list of steps but a complete game design.

Constructing a Building

Mission - You have to construct a building within a limited period of time. 

Variables

* Time - You have just 28 days to do these tasks
* Money - You have just 1,500 rupees
* Energy -  You have just 120 energy pts

Unexpected Variables

* There is GRAP 3 going on so you have to shut down work for a week. 
* There is a rainstorm. You must cover the building properly which will cost rupees 500. 
* There is an MCD issue. You have to shut down work for 5 days.

Rules
* If the correct order is given then continue
* If an incorrect order is given then a penalty will be there in which you lose 100 rupees, 20 energy pts, and 4 days of time.

Steps

1. Prepare and level up the land
2. Lay the foundation
3. Build the structure
4. Add the Walls
5. Install a roof
6. Add the doors and windows
7. Install water pipes
8. Finish the wiring 
9. Install lights
10. Add a gas pipe
11. Paint the walls
12. Polish the floors

Look at that. She invented unexpected variables. She gave the penalty system three dimensions (money, energy, and time) without me suggesting it. She included real-world disruptions she’d observed during our actual renovation: GRAP restrictions (Delhi’s pollution-based construction bans), MCD (Municipal Corporation of Delhi, the body that issues construction approvals) approvals, monsoon problems.

The design doc wasn’t an exercise. It was a nine-year-old telling a complete story about how construction actually works, with all the variables she’d seen her parents worry about.

Watch for these green flags with your own child. They tell you it’s landing:

• They catch their own mistake before you do.
• They ask “but what if…?” unprompted.
• They want to add a step you didn’t suggest.

When you see these, resist the urge to jump in. The productive struggle is the point.

Design → Build → Ship

With a solid design doc in hand, we opened ChatGPT.

I want to be precise about what happened here, because it’s easy to misread. She wasn’t watching me build something. She wasn’t following a tutorial. She was the designer handing a brief to an implementer.

What she typed (roughly)

Build me a browser game where a player has to complete house construction steps in the right order. If they do a step too early, show an error and explain why it's wrong. If they complete all steps in order, they win. Can you create this into a single file HTML. Use pastel colors that attract people. Whenever something becomes right, confetti should rain down." 

Then she copy pasted what she had written in Google Doc.

That prompt worked because the thinking behind it was solid. The AI had something real to implement. Garbage in, garbage out — it applies here exactly as it does in any professional design process.

The game came back. We tested it together. The roof step was appearing before it should — a sequencing error in the output, caught by the person who designed the sequence. She told the AI what was wrong. It fixed it.

That took twenty minutes. The next two hours were harder.

She wanted the steps to shuffle every time a player hits Play Again — so the game wouldn’t be memorisable. Reasonable design instinct. Completely correct thinking. And ChatGPT kept getting it wrong. The shuffle wasn’t working. The steps were coming back in the same order every time, or scrambling in ways that broke the game logic.

She prompted. Fixed one thing, broke another. Prompted again. By the twelfth attempt she was on the verge of tears, genuinely frustrated. The kind of frustration that comes from knowing exactly what you want and not being able to get there.

I didn’t fix it for her. I asked her to describe the problem out loud, precisely. Not “it’s not working” — what specifically is not working, and when? She took a breath and tried again.

It took twelve prompts in total before the final version worked the way she’d designed it. Somewhere in the middle of all this, she copy-pasted an output and the screen went blank. She stared at it. “Mum, it stopped working.”

I glanced over. ChatGPT had returned JavaScript only, no HTML wrapper. She’d pasted raw JavaScript into the browser and it had nothing to run inside.

“HTML is missing,” I said.

She went very quiet for a second. Then fixed it.

The final game had a working shuffle, penalty logic for wrong-order attempts, three resource variables, and real disruptions built into the unexpected events. It took twelve prompts to get there. She built it.

What this is actually building

It wasn’t the finished game that surprised me. The game was good, but the game was expected.

It was the research.

The moment she hit the knowledge gap in her construction sequence, she didn’t ask me to fill it in. She didn’t guess. She stopped, found a source, read it, and came back with better thinking.

I praised the research, not the result. “You found a gap in your own thinking and you went and fixed it. That’s the skill.” She seemed mildly pleased and immediately wanted to know when we could make it harder.

That moment is what I keep coming back to when people ask what I’m actually teaching her. Because I keep saying it’s not coding, and people nod, and then ask which programming language she’s learning.

So let me be specific.

The research rabbit hole was the point. The Sherlock Holmes backlog was the point. The design doc she had to fill in before touching any tool, that was the point. Every constraint in the session was designed to put her in a situation where the quality of her thinking visibly mattered. Where a gap wasn’t just an abstraction — it was something broken in her own work that she could see and fix.

That instinct: to close the gap yourself rather than work around it, to care about the thinking before the output, isn’t a coding skill. It’s not even a tech skill. It will be just as useful if she becomes a lawyer, a doctor, or something that doesn’t exist yet.

The sequencing was just where we started. ⚡️

What’s next

The Sherlock Holmes game is still in the backlog. She asks about it occasionally.

Next up is patterns: spotting what repeats, predicting what comes next. She’s been watching cricket scores for years without knowing she was already doing it. That’s post two.

#2 of 12 — next post: Patterns

New here? Start with the series introduction: How to Teach Computational Thinking to Kids (Ages 8–10)