Computational Thinking (Years 6–9) — Computer Science

Solving problems the way a programmer does: decomposition, pattern recognition and abstraction.

Imagine you are handed one instruction: "Organise the whole school sports day." Panic? Of course — it is far too big to do in one go. But split it into buying medals, drawing up a timetable, marking out lanes and printing the programme, and suddenly it is a to-do list you can actually tick off. That trick of breaking a scary problem into small, do-able pieces is the heart of computational thinking — the way of reasoning a programmer uses long before they touch a keyboard.

Why this matters: Computers only do exactly what they are told. Before you can write a single line of code you have to understand the problem so clearly that it could be handed to a machine. Computational thinking is that understanding step — get it right and the coding becomes the easy part.

Decomposition: one huge job breaks down into small tasks you can actually finish.

Decomposition — break it down

Decomposition means splitting a big problem into smaller sub-problems. Each piece is easier to think about, easier to solve, and — handily — different people can tackle different pieces at the same time. It is exactly how a recipe works: "make lasagne" is really "make the sauce" plus "make the pasta layers" plus "bake it".

Pattern recognition — spot what repeats

A repeated pattern becomes a single loop instead of copied-out steps.

Once a problem is broken up, you often notice the same shape appearing again and again. Pattern recognition is spotting those similarities. If drawing lane 1, lane 2 and lane 3 all follow the identical steps, you have found a pattern — and a pattern you can repeat is a pattern you can turn into a loop in code, instead of writing it out three times.

Abstraction — hide the clutter

Abstraction throws away roads and distances, keeping only what a traveller needs.

Abstraction means ignoring the details that do not matter so you can focus on what does. A Tube map is the classic example: it throws away real distances, roads and rivers, keeping only the stations and lines you need to plan a journey. A programmer abstracts a "customer" down to just a name and an order number — their eye colour is irrelevant to the till.

Skill	What you do	Everyday example
Decomposition	Break the problem into parts	Split a recipe into steps
Pattern recognition	Spot what repeats	Every lane drawn the same way
Abstraction	Keep only what matters	A simplified Tube map

Worked reasoning: A shop wants an app to email a receipt after each sale.

The D-P-A pipeline: understand the problem before touching a keyboard.

Decompose: (1) record the items, (2) add up the total, (3) build the email, (4) send it.
Pattern: "add up the total" is the same repeated step for item 1, 2, 3… — a loop.
Abstract: the email only needs item names, prices and the total; the shop's carpet colour is ignored.

Common mistake: Confusing abstraction with decomposition. Decomposition breaks a problem into pieces; abstraction removes unnecessary detail. You can do both to the same problem, but they are different moves.

Memory hook: Don't Panic Alone — Decompose, find the Pattern, then Abstract away the clutter.