Breaking a Problem into Small Steps

Ask a beginner to "build a shopping app" and they'll open an editor, stare at the empty file, and close it again. Ask them to "add two prices together" and they'll have it done in a minute.

The second problem isn't easier because they learned more. It's easier because it's small. Every experienced programmer has the same secret: they never solve big problems. They cut big problems into small ones until each piece is obvious, then solve those.

This lesson teaches that cutting. It matters more than any programming language you'll ever learn.

---

Big problems are just many small problems

"Build a shopping app" is not something anyone can sit down and type. It's too big and too vague. But "show the price of one product" is something you could figure out. And "add two prices together" is easy.

Programmers work like this all the time. They take a problem that feels impossible and keep cutting it into smaller pieces until every piece is so small it feels boring. Boring is good. Boring means you know exactly what to do.

This skill is called decomposition, and it matters more than knowing any programming language. Languages change every few years. This skill doesn't.

A worked example: splitting a restaurant bill

The problem: "Help friends split a restaurant bill."

That's vague. Let's ask questions until it's clear:

• What do we know at the start? The total bill and the number of people.
• Is there a tip? Yes, 10%.
• What should the result be? How much each person pays.
• Should we round? Yes, to the nearest 100 riel.

Now we can write the steps:

1. Get the total bill.
2. Get the number of people.
3. Add a 10% tip to the total.
4. Divide the new total by the number of people.
5. Round the result to the nearest 100.
6. Show how much each person pays.

Each step is now small enough that you could do it on a calculator. That's the sign you've split it far enough.

Pseudocode: code in plain language

Pseudocode means writing your steps in a code-like shape, but in plain words. No rules, no syntax errors. It's a sketch before the painting.

ask for total bill
ask for number of people

tip = total × 0.10
grand total = total + tip
each person pays = grand total ÷ number of people
round each person pays to nearest 100

show each person pays

Later, turning this into real JavaScript is almost mechanical:

const total = 85000;       // riel
const people = 4;

const tip = total * 0.10;
const grandTotal = total + tip;
const perPerson = Math.round(grandTotal / people / 100) * 100;

console.log("Each person pays:", perPerson, "riel");

Paste that into your browser console. It prints 23400. Don't worry about understanding every word yet; notice how closely it follows the pseudocode. The thinking happened in the pseudocode. The code is just translation.

Check your plan: what could go wrong?

Good programmers ask "what if?" before writing code. These unusual situations are called edge cases.

You don't have to handle every edge case in your first version. But writing them down means they won't surprise you later.

A method you can reuse every time

When you face any new problem, run through these four questions:

1. What do I have? (the inputs)
2. What do I want? (the output)
3. What steps get me from one to the other? Keep splitting until each step is boring.
4. What could go wrong? (the edge cases)

Write the answers down, on paper or in a comment, before you write a single line of code. It feels slower. It's actually much faster, because you stop getting lost halfway.

Practise without a computer

You can practise decomposition anywhere. Try writing steps for:

• Making instant noodles
• Finding the biggest number in a list of numbers written on paper
• Deciding whether to bring an umbrella today

For the last one you'll notice a step like "if it looks like rain, then take an umbrella". That's a decision, and it's exactly what lesson 4 is about.

---

What to remember

• Decomposition means splitting a problem until every piece is small and obvious.
• Pseudocode is a plain-language plan. The thinking happens there; code is translation.
• Edge cases are the "what ifs". Write them down early.
• Use the four questions: what do I have, what do I want, what are the steps, what could go wrong?

Try it yourself

1. Write pseudocode for converting a price in US dollars to riel (use 1 USD = 4,100 riel).
2. List three edge cases for your converter.
3. Bonus: turn your pseudocode into JavaScript in the console, using the bill example as a pattern.

Next, we look at the first real building block: variables, the named boxes where programs keep information.