Let's start with a story.
It's 1947, at Harvard University. A team of engineers is working with a gigantic early computer called the Harvard Mark II. It's the size of a room and full of thousands of little electrical switches called relays. One day, the machine starts giving wrong answers.
The team searches for the problem, and eventually they find it: a moth has flown into the machine and got stuck in one of the relays.
They carefully removed the moth, taped it into their logbook, and wrote next to it: "First actual case of bug being found." The computer pioneer Grace Hopper, who worked on that team, loved telling this story, and it helped make "bug" and "debugging" part of every programmer's vocabulary. (Engineers had actually been calling problems "bugs" for decades before that, but this was the first time a bug was, well, an actual bug.)
Today, a bug is any mistake in a program that makes it behave in a way you didn't intend. And debugging is the process of finding and fixing those mistakes.
Here's the most important thing to understand about bugs:
Bugs are normal. Everyone writes them.
Beginners write bugs. Experts write bugs. The people who built your phone's operating system write bugs. Professional developers often spend more time debugging code than writing new code.
So when your code doesn't work, it doesn't mean you're bad at programming. It means you're programming. Every bug you fix makes you a better developer, because you'll recognize it instantly next time.
Debugging is detective work. Something has gone wrong (the crime). You gather clues (error messages, strange output). You form a theory ("I bet this variable is a string, not a number"). You test your theory (add a console.log). And eventually, you catch the culprit. Grab your magnifying glass. 🔍