Algorithms, Pseudocode and Flowcharts

In this chapter

We'll learn what an algorithm really is (a recipe), how it differs from a program, and two ways to write one before any code: pseudocode and flowcharts — then write the first version of the seat-hold algorithm.

12–14 min

The Problem in Real Life

Anna has her five small problems. "Now I write the code?" she asks.

"Not yet," says John. "If you write code now, you'll be fighting two battles at once: what the steps are, and how to say them in JavaScript. Win the first battle on paper. It's much cheaper to fix a mistake with an eraser than in production."

Think on paper before you type.

John

Jumping Into Code vs. Planning the Steps First

Two problems at once

Working out the steps and writing them in a language are different jobs. Doing both together causes mistakes.

Plain words first

Pseudocode lets you write the logic in simple English, without worrying about brackets or syntax.

See the whole path

A flowchart shows every decision and every route at a glance — including the ones you forgot.

The recipe analogy: an algorithm is a recipe. It's a clear, ordered list of steps that solves a problem and always finishes. A good recipe has three things: what you start with (ingredients — the input), exact steps in order, and what you end up with (the dish — the output).

You use algorithms every day without calling them that: the steps to tie your shoes, the route you take to work, the way you look up a word in a dictionary (open near the right letter, then go forward or back). A computer algorithm is the same thing, written precisely enough that a computer could follow it.

Algorithm vs. program — the recipe vs. the cooking: the recipe for pancakes is the same whether it's printed in English, Hindi or Spanish, and whether you cook on gas or electric. A program is the recipe actually written in one specific programming language, for one specific computer. One algorithm can become many programs: the same seat-hold algorithm could be written in JavaScript, Python or Java. The algorithm is the idea; the program is one way of carrying it out.

Pseudocode: the recipe written in plain, structured English — "fake code." No brackets, no semicolons, no special language rules. It uses a few capital-letter keywords so the structure is clear: IF, ELSE, WHILE, FOR EACH, RETURN. One step per line, and indentation shows which steps belong inside which decision.
Flowchart: the recipe drawn as a picture. Steps are boxes, decisions are diamonds, and arrows show the order. A flowchart is great for seeing every possible path — especially the ones that loop back or end early.

Table — Algorithm vs. program

Feature	Algorithm	Program
In the kitchen	The recipe	The recipe cooked in one kitchen
Written in	Plain steps, pseudocode or a flowchart	A programming language
Runs on a computer?	No — it's the idea	Yes
How many versions?	One	Many (JavaScript, Python, Java...)

Table — Flowchart shapes

Shape	Means	Example
Oval	Start or end	Start: fan picks a seat
Rectangle	One action	Mark the seat as HELD
Diamond	A yes/no decision	Is the seat FREE?
Arrow	What happens next	From "FREE?" to "mark HELD"

Table — An everyday algorithm: finding a word in a dictionary

Step	What you do
1	Open the dictionary near the middle
2	If your word comes earlier in the alphabet, go to the left half; if later, the right half
3	Repeat with that half until you find the page
4	Read down the page to the word

This "halve it each time" idea is a real computer algorithm called binary search — you'll meet it in Act 09.

The seat-hold algorithm as a flowchart (version 1)

Start: fan picks a seat

oval — start

Is the seat FREE?

diamond — yes / no

Yes → mark HELD for 10 min

rectangle — an action

No → show "seat taken"

rectangle — then end

after holding

Paid within 10 minutes?

diamond — yes / no

Yes → mark SOLD

then end

No → mark FREE again

then end

Seat-hold algorithm, version 1, in pseudocode

WHEN a fan picks a seat:
    IF seat.state is FREE THEN
        set seat.state to HELD
        set seat.heldBy to this fan
        set seat.heldUntil to now + 10 minutes
        show the payment page
    ELSE
        show "Sorry, this seat is taken"

WHEN the fan pays:
    set seat.state to SOLD

WHEN ten minutes pass without payment:
    set seat.state to FREE

No brackets, no semicolons — just the logic. Notice the gap: what if the fan pays after the ten minutes are up? The next chapter deals with it.

Flowchart shapes — only four to learn: an oval marks the start and the end. A rectangle is one action ("mark the seat as held"). A diamond is a yes/no question ("is the seat free?") with two arrows coming out — one for yes, one for no. And arrows show which step comes next.

Pseudocode rules — keep it simple: one action per line; use IF / ELSE for decisions and indent what's inside; use FOR EACH or WHILE for repetition; name things clearly (seat, buyer, heldUntil); and write it so a teammate who has never coded could follow it. There's no single "correct" pseudocode style — clarity is the only rule.

The seat-hold algorithm, version 1: Anna turns her five questions into steps. A fan picks a seat. IF the seat is FREE, mark it HELD, remember who holds it, and set heldUntil to now plus ten minutes. ELSE, tell the fan the seat is taken. Later, IF the fan pays before heldUntil, mark the seat SOLD. IF ten minutes pass without payment, mark the seat FREE again.

She draws it as a flowchart too — and in the drawing she immediately spots something the text hid: there's no arrow for "the fan pays, but after the ten minutes are up." A missing path. She writes it in the margin with a question mark. That's exactly why we plan on paper: the gaps are easy to see.

Key Takeaway

An algorithm is a recipe: clear, ordered steps that turn an input into an output and always finish. A program is that recipe written in one specific language. Before coding, write the algorithm as pseudocode (structured plain English) or a flowchart (boxes, diamonds, arrows) — mistakes are far cheaper to find on paper.

Why This Matters

Planning before coding is how experienced engineers move fast: they find the hard questions while changes are still free. In real teams, pseudocode and flowcharts are how you explain an idea to a product manager, a designer or another developer before anyone writes a line — and how you spot the missing path before a customer does.

Version 1 has a question mark in the margin, and Anna suspects it isn't the only gap. A seat can be free, held or sold — and a lot can happen between those. To handle it all, she needs to think carefully about decisions, repeated checks, and something called state.