By the end of this lesson you will be able to
- Explain what an algorithm is using an everyday recipe as an example.
- Put the steps of a simple job in a correct sequence and say why order matters.
- Write a short algorithm in pseudocode using plain words.
- Read and draw a simple flowchart that includes a yes or no decision.
- Break a bigger job into smaller steps that are each easy to describe.
Before anyone writes a program, they decide what the program should do, one step at a time. That plan is called an algorithm, and you already use algorithms every day when you make tea, follow a bus route or count change. Learning to describe a job clearly in steps is the most important programming skill, and it needs no software at all: only a pen and paper. Everything later in this path, from web pages to JavaScript, rests on this habit of thinking.
An algorithm is a recipe
An Algorithm is a list of clear steps that, when followed in order, solves a problem or finishes a job. A cooking recipe is the best everyday picture. It names what you start with (the ingredients), says what to do in what order, and ends with a result (a meal). A computer Program is an algorithm written in a language the computer can follow.
Computers are very fast but completely literal. A person who reads "make a cup of tea" fills in the gaps without noticing. A computer fills in nothing. If a step is missing or vague, the computer does the wrong thing or stops. So a good algorithm is precise (each step has one clear meaning), ordered (the steps run in a sensible sequence) and finite (it reaches an end).
- Step 1: Boil waterFill kettle, switch on
- Step 2: Tea bag in cup
- Step 3: Pour waterAfter it has boiled
- Step 4: Wait 3 minutesRemove tea bag
- Step 5: Add milkOnly if wanted
Read this figure as text
A flow of five numbered steps for making a cup of tea, from boiling water to adding milk.
Five numbered boxes joined by arrows. Step 1: fill the kettle and switch it on. Step 2: put a tea bag in a cup. Step 3: when the water has boiled, pour it into the cup. Step 4: wait three minutes, then remove the tea bag. Step 5: add milk if you want it. The arrows show that each step starts only after the one before has finished.
Sequencing: why order matters
Sequencing means putting steps in the correct order. Swap two steps and the result changes, or the job fails. Pouring water before the tea bag is in the cup gives you a different drink. Adding milk before boiling the water is wasted effort. The same is true in a program: a computer runs instructions from the top, one after another, unless it is told otherwise.
Here is a smaller example with numbers. Amina buys 3 notebooks that cost 200 shillings each and then has a 100 shilling coupon. The total she pays depends on the order of the steps.
| Order of steps | Working | Amina pays |
|---|---|---|
| Multiply first, then take off the coupon | 3 x 200 = 600, then 600 - 100 | 500 shillings |
| Take off the coupon from one notebook first, then multiply | 200 - 100 = 100, then 3 x 100 | 300 shillings |
Only one of these matches the shop's rule (one coupon for the whole bill). The lesson is not about shopping. It is that an algorithm must state its order exactly, because the computer will follow it exactly.
Precise steps beat vague steps
A common beginner mistake is to write steps that feel clear to a human but hide decisions. Compare two versions of the same job: sending a text message to Joseph.
- Message Joseph
- Say it is urgent
- Make sure he got it
Too many gaps to follow.
- Open the messaging app
- Choose the contact Joseph
- Type: Please call me at 5 o'clock
- Press Send
- Look for the word Delivered
Every step can be done and checked.
Read this figure as text
Two columns comparing vague and precise instructions for sending a message to Joseph.
Left column, vague: "Message Joseph", "Say it is urgent", "Make sure he got it". Verdict: the computer cannot tell which app, what words, or how to check. Right column, precise: 1. Open the messaging app. 2. Choose the contact called Joseph. 3. Type the text "Please call me at 5 o'clock". 4. Press Send. 5. Look for the word Delivered under the message. Verdict: every step can be done and checked.
Pseudocode: planning in plain words
Pseudocode means "fake code". It is a way of writing an algorithm in short, plain sentences that look a little like a program but follow no strict rules. Nothing can run it. Its job is to help you think. Because it has no special symbols to remember, you can focus on the logic.
Most pseudocode uses a few agreed words in capital letters: SET to give something a value, ASK to get an answer from a person, IF, ELSE and END IF for decisions, REPEAT for doing something again, and SHOW to display a result. These are not real commands. They are labels to keep your plan tidy. Here is pseudocode for deciding whether to take an umbrella:
ASK the person: "Is it raining?"
IF the answer is yes
SHOW "Take an umbrella"
ELSE
SHOW "Leave the umbrella at home"
END IFNotice the indentation: the lines pushed in to the right belong to the IF or the ELSE above them. You will see exactly the same layout in real code in the next lesson, so it is a good habit to start now.
Flowcharts: drawing the plan
A Flowchart draws an algorithm as boxes and arrows. You follow the arrows from the start. Most flowcharts use a small set of shapes: a rounded box for start and end, a rectangle for an action, and a diamond for a yes or no question, with one arrow leaving for each answer. The decision tree below is the umbrella algorithm drawn this way. In this academy the diamond questions are shown as boxes with Yes and No branches.
- Is it raining?
- YesDo thisShow: Take an umbrella
- NoDo thisShow: Leave the umbrella at home
Read this figure as text
A decision diagram that asks whether it is raining and shows an umbrella message for yes and a different message for no.
Start: the question "Is it raining?" If the answer is Yes, the result is "Take an umbrella". If the answer is No, the result is "Leave the umbrella at home". Both paths then end. This is the same logic as the pseudocode: one question, two possible outcomes.
Breaking a big job into small ones
Big problems feel impossible until you split them. This is called decomposition. "Plan a birthday party" is too large to act on, but "make a guest list", "choose a date", "order a cake" and "send invitations" are each small enough to do. Each small part can be broken down again until every step is something you can actually do. A website works the same way: structure, appearance and behaviour are separate parts, which is why this path teaches HTML, CSS and JavaScript one after another.
- Plan a party
- Guests
- Make a list
- Send invitations
- Food
- Choose the menu
- Order the cake
- Venue
- Pick a date
- Book the hall
Read this figure as text
A tree starting with the job Plan a party and branching into guests, food and venue, each with small tasks.
The top box is "Plan a party". It has three branches. Guests: make a list, send invitations. Food: choose the menu, order the cake. Venue: pick a date, book the hall. Each leaf at the bottom is a single small task that can be done and ticked off.
Common mistakes
✖ Instead of: Writing steps like "do the usual thing" or "sort it out".
✔ Do this: Spell out each action so that someone who has never done the job could follow it without asking questions.
✖ Instead of: Trying to write the whole program straight away without a plan.
✔ Do this: Write the algorithm in pseudocode or draw a flowchart first, then turn it into code. Mistakes are much cheaper to fix on paper.
✖ Instead of: Forgetting what happens in the "no" case of a decision.
✔ Do this: Every question needs a path for each answer. Check that both the yes arrow and the no arrow lead somewhere.
If something goes wrong
- My flowchart has arrows that loop forever and never end.
- Check that at least one path reaches an end box. Add a decision that lets the process stop, for example "Is the cup full? Yes: stop".
- I cannot tell if my steps are detailed enough.
- Hand your algorithm to a friend and ask them to follow it literally. Every time they have to ask a question, add that answer as a new step.
- My pseudocode feels different from my friend's pseudocode.
- That is normal. Pseudocode has no official rules. As long as the steps are clear, ordered and use consistent words, it is correct.
Key terms
- Algorithm
- A step-by-step set of instructions for solving a problem or completing a task.
- Pseudocode
- A plan for a program written in plain, everyday words instead of a real programming language.
- Flowchart
- A diagram that shows the steps of an algorithm as boxes joined by arrows, with branches for yes or no questions.
- Program
- A list of instructions that tells a computer how to do a job.
Practise it for real
Reading is not the same as being able to do it. Complete these on your own computer, then tick only what you have actually done. These ticks are your own honest record: nothing checks them for you.
Write and draw an algorithm on paper
On paper, write an algorithm for "deciding what to wear" using pseudocode with SET, ASK, IF, ELSE and END IF. It must ask whether it is cold and show one message in each case. Then draw the same algorithm as a flowchart with one question and two outcomes. Finally do a dry run: pretend the answer is yes, follow your steps with a finger, and then pretend the answer is no.
Challenge: repair the washing-up algorithm
A friend wrote these steps for washing dishes in this order: dry the plates, rinse the plates, put the plates away, fill the bowl with water, wash the plates with soap. Without looking back at the lesson, put them in the right order, then rewrite the whole thing as precise pseudocode with one IF that checks whether the water is warm before washing.
Knowledge check
6 questions. You need 80% to pass. Mistakes here are part of learning, and you can retry as often as you like.
Summary
- An algorithm is a precise, ordered, finite list of steps that completes a job.
- Order matters: a computer follows steps exactly as written.
- Pseudocode is a plain-word plan; it is for people and cannot be run.
- A flowchart draws steps as boxes and decisions as yes or no branches.
- Decomposition splits a big job into small tasks that are easy to describe.
Checklist: can you do these?
Marking a lesson as read does not prove you can do it. Skills count as demonstrated when you pass the quiz (not yet) and complete the practical tasks (not yet).
Related lessons
References and further reading
Official sources for details that can change between versions.
- Algorithm (glossary) (MDN Web Docs)
- Learn web development (MDN Web Docs)