Introduction to Computational Thinking

AQA 4.4.1 — Thinking abstractly

Retrieval: Algorithm Performance asked you to compare four specific algorithms. This sequence steps back from specific algorithms to the general thinking skills — starting with abstraction — that let you design a solution to a problem no one has given you a ready-made algorithm for yet.

Abstraction means deliberately focusing on the details that matter for a given purpose, and ignoring the ones that don't. It isn't "simplifying" or "dumbing down" — it's a precise design choice about which level of detail is useful right now.

Levels of abstraction, in one everyday example

A car's steering wheel is an abstraction: turning it left turns the car left, and the driver doesn't need to know anything about the steering column, rack-and-pinion gearing, or tyre alignment underneath. A mechanic, fixing the car, needs exactly that detail the driver doesn't. Neither view is "more correct" — they're different, deliberately chosen levels of abstraction for different purposes.

Common mistake

Treating abstraction as simply "leaving stuff out" or making something easier. Abstraction is a deliberate design decision about which details are essential for the task at hand — the same system can have many valid abstractions depending on who's using it and why, and choosing the wrong level of detail for the audience is itself a real design failure, not a shortcut.

Worked example — abstracting a login system

A student explaining a login system to a user might say: "enter your username and password, and you're logged in." A student explaining it to a fellow programmer would need far more: how the password is checked, what happens on failure, how sessions are managed. Both descriptions are legitimate abstractions of the same system — they simply serve different audiences and hide different amounts of detail.

Apply it — identify relevant vs irrelevant information

A school wants a simple system to record which students attended each lesson. For the purpose of just recording attendance, decide which of the following are relevant, and which are irrelevant detail to abstract away: student name; student's favourite subject; date of the lesson; teacher's shoe size; whether the student was late; the school's postcode; present/absent status.

(Relevant: student name, date, present/absent status, and arguably lateness. Irrelevant to this specific purpose: favourite subject, teacher's shoe size, school postcode — real facts, but not needed for attendance recording specifically.)

Challenge

Choose a real-world system you use regularly (a ride-booking app, a music streaming service, a school timetable) and describe it at two different levels of abstraction: one for a brand-new user, one for a programmer who'd need to build it. Identify at least two details that appear in one description but are deliberately abstracted away in the other.

Looking ahead: the next lesson (Decomposition) is the natural partner skill to abstraction — once you've decided what matters about a problem, decomposition is how you break that problem down into manageable pieces.