Nobody solves the big problem. They cut it up until every piece is too small to be interesting, then do the small pieces. Your course calls this top-down design and says it is the main event.
Nobody solves a big problem. They cut it into smaller problems, and cut those up too, until every piece left is so small it is obvious — then they do the obvious pieces.
This has a name in your course description. It is called top-down software design, and the catalog says it is the major focus of the lectures. It sounds grand. It means exactly what you just read: start at the top with the whole messy thing, and keep breaking it down.
Here is the part people miss. You are not looking for the right answer when you break something down. You are looking for pieces small enough to stop thinking about. That is the only test. A step is finished being broken when you could just sit down and do it.
Staring at a whole assignment and feeling like you have no idea where to start is not a sign you are bad at this. It is the correct feeling. Nobody can hold the whole thing at once. The feeling goes away the moment you write down the first three pieces — even if they are wrong.
Below is one big task. For each piece, make a judgment call: could you sit down right now and just do it, start to finish, without stopping to think? If yes, it is small enough. If no, break it open.
Keep going until nothing is left that still needs thinking.
Look at the last branch you opened — working out whether you made money. Broken all the way down it becomes: add up what you spent, add up what you took in, subtract one from the other. Three steps, no judgment required, no cleverness left in them.
That is code. Not code-like, not nearly code — those three steps are a program, and translating them into C++ is close to typing. The hard part already happened, up in the tree, where you decided what the pieces were.
When you get a programming assignment this semester, do not open your editor. Write the task at the top of a page and break it down on paper until the bottom row is boring. Then open your editor and type the bottom row. People who do this finish early. People who start typing get lost in the middle and cannot say why.
Look again at the bottom of your tree: add up everything we spent. That is not just a step — it is a little job with a clear edge. You could hand it to somebody, walk away, and come back to an answer. You would not need to watch.
In a program, a named piece like that is called a function, and it has three parts and only three:
What you give it — the receipts. What it does — adds them up. What it hands back — one number. That is the whole idea. Give it something, it does one job, it hands something back.
Which means your tree was never just a plan. The bottom row of your breakdown is the list of functions you are going to write. A real program for that bake sale would have a piece called something like totalSpent, another called totalTaken, and a third that subtracts one from the other — three named jobs instead of one long tangle.
That is the difference between a program someone can read and one nobody can, including you, three days later. And it is why the breaking-down is the real work: you are not making a to-do list, you are deciding what the parts of your program are.
Everyone’s first instinct is one enormous piece that does everything top to bottom — read the numbers, add them, work out the change, print it, all in one run-on breath. It works, right up until it does not, and then there is nowhere to look. Small named jobs are how you keep being able to find things.
Say the task, then split it into three or four pieces out loud. Do not aim for right. Aim for said out loud.
For every piece ask one question and only this question: “Could you sit down right now and just do that?” If the answer has an “um” in it, it gets broken again.
Good tasks to try: plan a birthday dinner · move to a new apartment · get a passport · do the weekly laundry properly. Swap roles halfway. Being the sceptic is the half that teaches you the most, because it is the exact question you will be asking yourself alone at 1am in week nine.
The test is never “is this right?” It is “could I just do this without thinking?”
The thinking happens in the tree. Typing is what you do once the thinking is finished.
Not knowing what to type almost always means the piece in front of you has not been broken down enough yet.
Not recall — these are the shapes an exam actually uses. Every answer below was produced by compiling and running the code, so if you disagree with one, the compiler is the one to believe.
Have a real go before revealing. Being wrong here is worth more than being right in three weeks.
When do you stop breaking a task into smaller pieces?
You are staring at an assignment with no idea where to start. What does that usually mean?
What is a function, in one sentence?
← back to all 12 levels · stuck on anything? ask peter.