You have written a lovely set of steps for your robot. You press play, all excited… and the robot trundles off and does something completely wrong. It bumps into a wall, or stops in the wrong spot, or makes toast when you asked for a sandwich.
Don't worry — this happens to everyone, even people who write code for a living. A mistake hiding in your steps is called a bug. And the clever detective work of finding that mistake and putting it right is called debugging.
Here's the good news: your steps aren't wrong everywhere. Usually just one little step is the troublemaker. Debugging is all about hunting down that one step.
The word is wonderfully old. Back in 1947, engineers testing one of the very first computers found
it misbehaving — and traced the fault to a real moth stuck inside the machine!
They taped the moth into their logbook with the note "first actual case of bug being found."
The pioneer who kept that logbook,
Our robot only understands two instructions: go right and go up. We wanted it to reach the star. Here is the set of steps we gave it. Press play and follow along…
Oh no! The robot stopped one square to the left of the star. There's a bug in our steps. But where? We don't need to throw the whole thing away — we just need to find the one step that's wrong.
Here is the best trick in the whole world for finding a bug. Pretend to be the robot yourself. Read the steps one at a time, and do exactly what each one says — no more, no less. Don't do what you meant to write; do what you actually wrote.
Our steps were:
Let's follow them like a literal robot. Right, right… that's two steps to the right. Then up, up, up. But to reach the star we needed to go right three times! We only wrote it twice. Found it — the bug is a missing "go right" step. 🔍
When you first write steps, your brain quietly fills in the bits you meant but forgot to say — so you read right past the mistake. Going one step at a time, doing each one for real, stops your brain cheating. It's like counting your change coin by coin instead of just guessing the total. Slow and steady catches the bug.
Now we fix the one broken step: we add the missing "go right". Our repaired steps are: right, right, right, up, up, up. Let's give it to the robot and see what happens…
The robot lands right on the star. 🌟 That last part is really important: after you fix a bug you must test again — run the steps and check they truly work now. A fix isn't finished until you've watched it work.
So debugging is really just four friendly steps of its own:
When you find a bug, don't just start changing bits and bobs at random and hoping. That almost never works — and worse, you can accidentally break something that was fine!
Instead, find the real cause — the actual step that's wrong — and fix that. Then test again. Sometimes fixing one bug reveals another one hiding behind it, or your "fix" causes a brand new bug. That's totally normal! Just debug again: read, follow, fix, test. Good detectives check their work every single time.
Way back in 1947, some computer scientists found that their giant room-sized computer had stopped working — and when they looked inside, a real moth had got stuck in it! They taped the moth into their notebook and wrote that they had been "debugging" the machine. People had used "bug" for little faults even before that, but the story stuck. So the next time you squash a bug in your steps, you're carrying on a tradition almost eighty years old!
A bug is really just a mistake in a set of steps, so you can find them all over the place. Imagine a recipe that says:
Follow it like a literal robot and you'll be eating dry cereal, then pouring milk onto an empty bowl! The bug is the order: "pour on the milk" should come before "eat the cereal". Read, follow, fix, test — and breakfast is saved. 🥣