Flowcharts & Pseudocode
Before you build something, it helps to sketch it out. Carpenters draw plans before cutting wood. Filmmakers storyboard before shooting scenes. In the same way, flowcharts and pseudocode let you design an algorithm before writing code — or before implementing any process at all.
This chapter covers how to visualize and write out your thinking before committing to implementation, in both everyday and technical contexts.
Why Plan Before You Build?
Jumping straight into implementation — whether it is writing code, organizing an event, or building furniture — often leads to rework. You discover halfway through that you missed a step, handled a decision incorrectly, or built things in the wrong order.
Planning with flowcharts or pseudocode is cheap. Erasing a line on paper costs nothing. Rewriting a system that was built on the wrong logic costs a lot.
Planning helps you:
- See the overall structure before getting lost in details
- Spot missing steps and logical errors early
- Communicate your approach to others for feedback
- Separate the "what should happen" from the "how to make it happen"
Flowcharts
A flowchart is a visual representation of a process. It uses shapes and arrows to show the flow of steps and decisions.
The basic shapes:
+-------------+
| Rounded box | Start / End
+-------------+
+-------------+
| Rectangle | Process step (an action)
+-------------+
/ \
/ ?? \ Decision (yes/no question)
\ /
\ /
+-------------+
| Parallelogram| Input / Output
+-------------+
Arrows connect the shapes to show what happens next.
An Everyday Flowchart: Should I Take an Umbrella?
[Start]
|
v
Is it raining now?
/ \
Yes No
| |
| v
| Is rain forecast?
| / \
| Yes No
| | |
v v v
Take Don't take
umbrella umbrella
| |
v v
[Leave the house]
This is simple, but it captures the logic completely. Anyone reading it can follow the same decision process and reach the same conclusion given the same conditions.
A Customer Support Flowchart
Many businesses use flowcharts as troubleshooting guides:
[Customer calls with internet issue]
|
v
Is the router power light on?
/ \
No Yes
| |
v v
"Please plug Can you connect to Wi-Fi?
in router." / \
| No Yes
v | |
Is light on? v v
/ \ "Try Can you reach google.com?
Yes No restarting / \
| | router." No Yes
| v | | |
| "Router v v v
| may be Did it "DNS "Sounds like
| faulty." work? issue. the issue may
| | / \ Let me have resolved.
| v Yes No check." Is it working?"
| [Schedule | | |
| technician] v v v
| | [Continue [Escalate] [Close ticket]
v v troubleshooting]
[End] [End]
This kind of flowchart is a decision tree — each branch leads to a different action depending on the answer to a question. It lets support agents handle calls consistently without memorizing every scenario.
Pseudocode
Pseudocode is a way of writing an algorithm in structured, plain language. It is more precise than a casual description but more readable than actual code.
There is no official syntax for pseudocode — the only rule is that it should be clear and unambiguous.
An Everyday Example: Making a Grocery Run
check the pantry and fridge
make a list of items that are low or missing
for each item on the list:
check if the item is available at the nearest store
if yes:
add it to the shopping list for that store
if no:
check the next nearest store
add it to that store's list
for each store that has items on its list:
drive to the store
for each item on that store's list:
find the item
put it in the cart
go to checkout
pay
drive home
put all groceries away
This reads like plain language, but it has structure: loops ("for each"), conditions ("if yes"), and a clear sequence. Someone reading this knows exactly what the process is.
A Thermostat in Pseudocode
every 5 minutes:
read current temperature
if current temperature < desired temperature - 2:
turn on heater
else if current temperature > desired temperature + 2:
turn on air conditioning
else:
turn off heater and air conditioning
The "+/- 2" prevents the system from constantly switching on and off when the temperature hovers near the target. Writing this in pseudocode makes the logic clear before anyone has to wire a thermostat or write control software.
When to Use Flowcharts vs Pseudocode
Both tools accomplish the same goal — making your thinking explicit — but they have different strengths:
Flowcharts are better when:
- The process has many decision points and branches
- You need to communicate with non-technical people
- You want to see the overall structure at a glance
- The audience is visual
Pseudocode is better when:
- The process is mostly sequential with some decisions
- You are preparing to write actual code
- You need to express precise logic
- The audience is comfortable reading structured text
In practice, many people use both. A flowchart gives you the big picture, and pseudocode fills in the details of each step.
Flowcharts & Pseudocode in Technology
State Machines
A state machine models something that can be in different states and transitions between them based on events. Flowcharts are a natural way to design them.
[Locked Door]
|
v
Correct key inserted?
/ \
Yes No
| |
v v
[Unlocked] [Stay Locked]
| |
v v
Door opened? Wrong key 3 times?
/ \ / \
Yes No Yes No
| | | |
v v v v
[Open] [Unlocked] [Alarm] [Stay Locked]
This models a door lock's behavior. In software, the same idea applies to things like user login flows, order status tracking, and game character states.
Software Design
Before writing a complex function, experienced developers often sketch it in pseudocode. This pseudocode can be reviewed by the team before anyone writes real code. Catching a logical error at this stage saves hours of debugging later.
Common Pitfalls
Too much detail too soon
A flowchart or pseudocode is a planning tool, not the final product. If it becomes as complex as the thing you are building, you have gone too far. Keep it at the right level of abstraction for its purpose.
No clear start and end
Every flowchart needs a defined beginning and ending. Every pseudocode algorithm needs a clear starting point and a result. Without these, you do not have an algorithm — you have a collection of disconnected ideas.
Forgetting the unhappy path
It is easy to design the path where everything goes right. But what happens when the payment fails? When the file is not found? When the user enters invalid data? Good flowcharts and pseudocode include error paths.
Treating it as permanent documentation
Flowcharts and pseudocode are most valuable during design. Once the system is built, the real source of truth is the system itself. Maintaining detailed flowcharts for code that changes frequently is often not worth the effort.
Making flowcharts unreadable
A flowchart with fifty boxes and crossing arrows everywhere helps no one. If the process is that complex, break it into sub-flowcharts, each handling one part of the overall process.
Key Takeaways
- Flowcharts and pseudocode are tools for thinking through a process before implementing it.
- Flowcharts are visual and excel at showing decision points and branching paths.
- Pseudocode is textual and excels at expressing precise sequential logic.
- Both are used outside of technology — in customer support, business process design, troubleshooting guides, and more.
- In technology, they are used to design state machines, plan software logic, and coordinate business processes.
- The goal is to make your thinking explicit and catch errors early, when they are cheap to fix.