- Define and explain Breaking Problems Down in your own words
- Use key terms such as decomposition accurately
- Apply what you have learned to new examples and questions
- Avoid the common mistakes learners make with this topic
Long before anyone writes code, programmers think. Computational thinking is the four-part mindset behind every app, game and website: break problems down, spot patterns, ignore irrelevant detail and design step-by-step solutions. Master these habits and programming becomes far easier — they work for exam revision and everyday life too.
This lesson focuses on Breaking Problems Down: split large problems into smaller, solvable pieces.
Split large problems into smaller, solvable pieces.
Key ideas
Patterns turn one solution into many
Once you write a procedure that finds the largest number in a list, you have also solved finding the highest exam score, the warmest day and the most expensive item — the pattern is identical. Recognising this saves programmers from reinventing solutions.
The four pillars work together
Faced with organising a school fair, you decompose it into stalls, tickets and publicity; you recognise the pattern that ticket selling works like last year's concert; you abstract away details like the colour of the tickets; then you write the algorithm — the ordered steps for setting up each stall. Real programmers cycle through all four constantly.
Key term — decomposition: Breaking a large, complex problem into smaller sub-problems that are easier to solve one at a time.
You must organise a charity run. Name two ways to decompose the problem.
Possible splits: route planning, sponsorship and publicity; or before, during and after the event — any sensible split into smaller sub-problems scores.
Answer: Possible splits: route planning, sponsorship and publicity; or before, during and after the event — any sensible split into smaller sub-problems scores.
- Jumping straight to code without thinking Correction: spend ten minutes decomposing and planning on paper first — it prevents hours of rewriting later.
- Treating a coincidence as a pattern Correction: check a pattern holds in several cases before building a solution on it; one example is not a pattern.
Practice
It is a huge problem hiding dozens of sub-problems — graphics, controls, scoring — which must be decomposed and tackled one at a time.
False — it is a general problem-solving mindset that works for planning, studying and organising anything.
Questions sharing the same structure can be solved with the same method, so spotting the pattern lets you reuse a method instead of starting from scratch.
Abstraction — irrelevant detail (bus colour) is stripped away, leaving what matters (routes and times).
Quick check
Which of these best defines "decomposition"?
Give an example of automation in everyday life.
- Breaking Problems Down: split large problems into smaller, solvable pieces.
- Patterns turn one solution into many: Once you write a procedure that finds the largest number in a list, you have also solved finding the highest exam score, the warmest day and the most expensive item — the pattern is identical.
- pattern recognition: Noticing similarities or repetitions within and between problems, so a solution that worked before can be reused.
- Watch out for: jumping straight to code without thinking