In this chapter
We'll learn how programmers think before they type: breaking a big, scary problem into small, easy ones, and solving them one clear step at a time — using a dinner party, and then Anna's seat-hold problem.
The Problem in Real Life
Week eight. Samantha stops at Anna's desk with a problem from the last big sale. "Two fans picked the same seat at almost the same time. Both reached the payment page. Only one got the seat — the other paid and got an angry refund email."
Then she gives the new rule: "When someone picks a seat, hold it for them for ten minutes. Nobody else can take it. If they don't pay in time, give it back." She smiles. "Can you build that?"
Anna opens her code editor — and freezes. Where do you even start with something like this? Timers? Two people at once? Payments? It feels like one giant, tangled knot.
Close the editor. The first step of a hard problem is never code. It's thinking.
John
One Giant Problem vs. Many Small Ones
Big problems freeze people
"Build a seat-hold system" is too big to start. Nobody can write that in one go.
Every big problem is made of small ones
Split it into pieces until each piece is simple enough to solve on its own.
Computers need every step
A person fills in missing steps without noticing. A computer can't — so you must find them all.
Thinking Like a Programmer
John asks a strange question: "Have you ever cooked dinner for twenty people?"
The dinner party analogy: "Cook dinner for twenty" sounds overwhelming. But nobody actually does it in one step. You break it down: starter, main course, dessert. Then the main course becomes: buy chicken, marinate it, cook rice, make the sauce. Then "make the sauce" becomes: chop onions, fry them, add tomatoes... Keep going, and at some point every piece is something you already know how to do. The giant task was just many small, easy tasks stacked together.
That way of thinking has a name: computational thinking — approaching a problem the way you'd explain it to a computer. It's not about computers at all; it's a way to make any hard problem solvable. It has four simple habits:
- Decomposition — break it down: split a big problem into smaller problems, and those into smaller ones, until each piece is easy. "Dinner for twenty" becomes "chop onions."
- Pattern recognition — spot what repeats: notice when pieces are the same. Cooking rice for twenty is the same as for two, just more. In the seat-hold problem, "check if a seat is free" will be needed in several places — solve it once.
- Abstraction — ignore what doesn't matter: keep only the details that matter for this problem. For holding a seat, the seat's colour on the map doesn't matter; whether it's free, held or sold does.
- Algorithm — write the steps in order: put the small pieces into a clear sequence that always works. That's the recipe — and the next chapter is all about it.
| Habit | Dinner for twenty | Hold a seat for ten minutes |
|---|---|---|
| Decomposition | Starter, main, dessert → chop, fry, boil | Check free → hold → time → pay or release |
| Pattern recognition | Rice for 20 = rice for 2, just more | "Is it free?" is needed in several places — solve once |
| Abstraction | The plate colour doesn't matter | Seat colour doesn't matter; free / held / sold does |
| Algorithm | The recipe, in order | The seat-hold steps, in order |
| A person hears | A computer needs to be told |
|---|---|
| "Make tea" | Find a cup. Fill the kettle. Switch it on. Wait until it boils. Put a tea bag in the cup. Pour the water. Wait 3 minutes. Remove the tea bag. |
| "Hold the seat" | Check the seat exists. Check it's free. Record who holds it. Record the time. Block everyone else. Start counting ten minutes. |
Decomposing "hold a seat for ten minutes"
Hold a seat for 10 minutes
the big problem
Is the seat free?
check
Mark it held
for whom, until when
Time it
when are 10 min up?
Fan pays
seat becomes sold
Fan doesn't pay
seat becomes free again
Step-by-step thinking — why computers need it: if you ask a friend to "make tea," they just do it. They fill in a hundred small steps without thinking: find a cup, boil water, wait, add the tea bag. A computer can't fill in anything. It needs every step, in the right order, with nothing assumed. So a programmer's real job is to find all the steps a person would skip without noticing.
Now the seat-hold problem: Anna takes a sheet of paper and does what John showed her — she breaks it down. "Hold a seat for ten minutes" turns into five smaller questions. When a fan picks a seat, how do we know if it's free? If it's free, how do we mark it as held, and for whom? How do we know when ten minutes have passed? What happens when the fan pays? What happens if they don't?
Each question is still a problem — but each one is small enough to think about on its own. The tangled knot is now five short threads. Anna looks at the paper and, for the first time today, feels like she can do this.
Key Takeaway
Computational thinking means breaking a big problem into small ones (decomposition), spotting repeats (pattern recognition), ignoring details that don't matter (abstraction), and writing the steps in order (algorithm). Computers need every step spelled out — finding all of them is the programmer's real job.
Why This Matters
This is the most important skill in this whole course, and it isn't about any language. Every feature Anna builds this year — and every bug she fixes — starts with breaking a big problem into small ones. Engineers who are great at this are rarely the ones who type fastest; they're the ones who think the problem through before they type.
Anna has five small problems on paper. Now she needs to turn them into a clear list of steps — something precise enough that a computer could follow it, but still written in plain words. That list has a name: an algorithm.