You already know that an algorithm is a set of clear steps in the right order. But a long list of steps written in words can be hard to follow — especially once the algorithm has to make a choice and go one of two ways. A flowchart is a way to draw an algorithm as a picture, so you can see the whole thing at a glance and trace any route through it with your finger.

Think of it like a map of a journey. Each box is a place you pass through, and the arrows are the roads between them. Start at the top, follow the arrows, and you always know exactly where the algorithm goes next — and, crucially, where it splits when a decision has to be made.

Engineers, programmers and designers draw a flowchart before they write any code, because it is far quicker to spot a mistake in a picture than to hunt for it inside a program that is already running. Get the flowchart right, and the code almost writes itself.

The standard symbols

Flowcharts use a small set of standard shapes, and everybody agrees on what each shape means. That is the whole point: because the shapes are standard, anyone in the world can read your flowchart without you explaining it. There are four you need to know:

• Terminator — a rounded box (a pill shape). It marks the start and the end. Every flowchart has exactly one start, and every route must finish at an end.
• Input / output — a parallelogram (a leaning rectangle). Use it whenever the algorithm takes something in (reads a number, asks a question) or sends something out (prints a message, shows a result).
• Process — a plain rectangle. This is a step of work: a calculation, or an action the computer carries out, like "add 1" or "work out the remainder".
• Decision — a diamond. It asks a yes / no (true / false) question, and has two arrows leaving it, one labelled for each answer. This is where the flow splits.

Every one of these is joined to the next by an arrow, and the arrowhead always shows which way the flow goes. Follow the arrows and you are following the algorithm.

A real flowchart: is a number even?

Let's draw a genuine algorithm — one that decides whether a number is even or odd. The trick is the remainder: divide the number by 2, and if nothing is left over the number is even. Step through the flowchart below one symbol at a time and watch how the four shapes fit together, ending with the decision diamond that splits the flow two ways.

Notice the shape of it: everything funnels down to the diamond, the flow splits into a Yes road and a No road, and then both roads join back together and arrive at the single END. That "split, then re-join" pattern is the heart of almost every useful flowchart.

Tracing a flowchart

To trace a flowchart is to pretend you are the computer: start at the top and walk the arrows, answering each decision as you reach it. Let's trace our even/odd chart twice.

Trace n = 6: read in the number 6 → work out the remainder of 6 \div 2, which is 0 → reach the diamond "is the remainder 0?" → the answer is Yes, so take the Yes branch → output "n is even" → END.

Trace n = 7: read in 7 → the remainder of 7 \div 2 is 1 → reach the diamond → the answer is No, so take the No branch → output "n is odd" → END.

Same flowchart, two different numbers, two different routes — but every route reaches the end. That is exactly what a well-drawn flowchart guarantees.

From flowchart to code

A flowchart isn't just a drawing — it maps almost line-for-line onto real code. The diamond becomes an if / else, the two branches become the two blocks, and the input/output boxes become reading a value and printing a message. Here is our even/odd flowchart written out in TypeScript:

Read the flowchart and the code side by side and you can point to each symbol in the drawing and find the matching line in the program. Draw first, then code — the flowchart is the plan.