The first "actual" bug was a moth: 4 debugging steps that still work

Why do we call software problems "bugs"? Part of the story involves a real moth.

On September 9, 1947, Harvard's Mark II computer malfunctioned. Engineers traced the fault to a relay, found a moth stuck inside, taped it into the logbook and wrote: "First actual case of bug being found."

That logbook page is now at the Smithsonian's National Museum of American History. Computing pioneer Grace Hopper, who worked on the team and later helped drive the creation of COBOL, made the story famous.

The fun twist: "bug" already meant a fault long before 1947. Edison used the word in the 19th century. So the note was an engineer's joke: this time it was an actual bug.

Debugging still follows the same four steps:

1. Reproduce it reliably. "Sometimes it happens" is the hardest bug to catch.
2. Narrow it down by halves, like a guessing game.
3. Write down what you find, just like that logbook page.
4. Verify the fix. Run it again and confirm it is really gone.

Bonus: rubber-duck debugging. Put a rubber duck on your desk and explain your code to it line by line. Halfway through, you often spot the problem yourself. The trick comes from The Pragmatic Programmer, and it is ridiculously simple, but it works.

What's the weirdest bug you've ever caught?

(Some images AI-generated)