How Do You Break a Problem Into Steps?
Root Concept
Useful steps are three things at once: small enough to do, in an order where each one is possible when it arrives, and precise enough that a literal follower cannot misread them.
CodePLU Goal
Upgrading Human Mental Models
Learn how to think in Workflows
Concept Development By codeplu.com
Five steps in the only order that works — each one possible when it arrives
Why Is Writing Simple Steps So Surprisingly Hard?
There is a classroom exercise that goes wrong every time. Children write instructions for making a jam sandwich, then the teacher follows them exactly as written. 'Put the jam on the bread' produces a jar placed on top of a loaf. 'Spread the butter' with a bare hand. Nobody wrote it badly on purpose — they simply assumed a reader who fills in the gaps, and the teacher refused to be one.
That is the real lesson of breaking a problem into steps. Splitting a big task into smaller ones is the easy half, and most people do it naturally. The hard half is that the steps must also be in an order where each one is genuinely possible when it arrives, and precise enough that somebody who knows nothing and assumes nothing could follow them.
Computers are that literal follower, permanently. They will happily execute step three before you have created what step three needs, and they will interpret 'a little' however their instructions define it. In the playground above you will order the steps for something you have done a thousand times — and discover that the order is not arbitrary at all.
How Do You Turn a Task Into Steps That Work?
How small should a step be?
Small enough that you could do it right now without further thought, or hand it to someone else without extra explanation. That is the test, and it is stricter than it first appears. 'Sort out the catering' fails it, because it is really a series of decisions wearing one label — how many people, what food, what budget, which supplier. 'Phone three caterers for quotes' passes. Beginners consistently stop splitting too early, which leaves them with a shorter list that is just as paralysing as the original problem. If a step still makes you hesitate about what to actually do, split it again.
Why does the order matter so much?
Because most steps quietly depend on earlier ones. You cannot toast bread that is still in the bag, or butter toast that does not exist yet. These dependencies are obvious in a kitchen and much less obvious in unfamiliar work, which is why swapped steps are such a common source of confusion: each instruction looks correct in isolation while the sequence cannot be executed. A quick way to check is to walk the list pretending you have only what earlier steps produced. The first moment you need something nobody has made yet, the order is wrong — or a step is missing entirely.
What counts as precise enough?
Imagine the most literal reader possible and ask what they could get wrong. 'Add a little salt' invites a guess; 'add half a teaspoon' does not. 'Wait until it is done' is unanswerable; 'wait until it pops up, about two minutes' is followable. The same applies to conditions and edges: what should the follower do if the toaster is already full, or the bag is empty? Beginners assume shared common sense and are then surprised when the result is wrong, which is exactly what happens with computers — they carry out precisely what was written, including the reading you never intended.
How do you find the steps you forgot?
Do the task slowly and narrate it, or better, have somebody else follow your written steps exactly while you watch and stay silent. Missing steps are almost invisible to their author, because you perform them automatically and your description skips them — the bag was opened, the plate was fetched, the toaster was plugged in. Watching someone else stall at the exact point where your instructions run out is uncomfortable and extremely effective. This is also precisely what happens when you run a program: it stops, or misbehaves, at the moment your steps stopped matching reality.
Does this only apply to computers?
Not remotely, and that is why it is worth practising. Handover notes for a colleague, assembly instructions, a recipe, a form asking somebody for information, directions to your house — all of these fail in exactly the same three ways: a step too big to act on, steps in an impossible order, or wording open to interpretation. Programming simply gives you the fastest feedback in the world about which of the three you got wrong, because the computer never fills a gap for you or quietly guesses what you probably meant.
Real World Example
Why Did the Instructions for a Simple Bank Transfer Fail?
A small charity asks a volunteer to pay their suppliers. The written instructions look complete and fail on all three counts.
The original instructions
Three lines: 'Log into the bank account. Pay the invoices. Record the payments in the spreadsheet.' Every line is true, and every line is useless to somebody who has never done it. This is what steps that are too big look like in real life.
The first failure: a step too big to act on
'Pay the invoices' is not one action; it is finding the invoices, checking each one was approved, reading the supplier's account details, entering them, and confirming the amount. The volunteer stalls immediately, not because the task is hard but because the step never told them what to do.
The second failure: an impossible order
Recording payments comes last, so the volunteer pays everything first — and then cannot remember which reference belonged to which supplier. Recording each payment as it happens is the order that works. The written sequence looked fine and could not actually be followed.
The third failure: wording open to interpretation
'Pay the invoices' does not say which ones. The volunteer pays all of them, including two still under dispute and one already paid last month. Nothing in the instructions was false; the instructions simply assumed judgement the reader had no way to apply.
The rewritten version
Small, ordered, precise: open the approved-invoices folder; take the oldest invoice; check it has a signature; enter the account number exactly as printed; enter the amount; confirm; write the reference in the spreadsheet immediately; then repeat with the next invoice. A stranger can now do this correctly on their first attempt.
FAQs
Final Words
Breaking a problem into steps means three things at once: each step small enough to act on, ordered so that every step is possible when it arrives, and worded so a literal follower cannot go wrong. In the playground you ordered five steps for buttered toast and saw that the order was forced by what each step needs.
Test your steps by handing them to somebody who assumes nothing — a colleague, or a computer, which is the same test with faster feedback. Next comes the habit that saves you from writing these steps over and over: noticing when a problem repeats, and capturing it as a single rule.
Continue This Track
This concept is part 2 of Thinking Like a Computer Scientist.
What Is Computational Thinking?
Computational thinking is not thinking like a machine. It is four ordinary habits — breaking things down, spotting patterns, ignoring what does not matter, and being exact — that you already use when planning a trip or reading a metro map.
How Do You Break a Problem Into Steps?
Breaking a problem down is only half the job. The steps must also be in the right order and precise enough that a completely literal follower could not go wrong — which is harder than it sounds.
How Do Patterns Turn Many Problems Into One?
The most valuable move in problem solving is noticing that you are doing the same thing repeatedly — and replacing all of it with one rule. Learn to spot repetition and turn it into something reusable.
