Traditional debugging:
Modern debugging:
"For magic consists in this, the true naming of a thing." - Ursula LeGuin, A Wizard of Earthsea
to know the true name of an object... or a concept... is to have power over it
SO
you can't google an error until you know the name of the error
Often, bugs and errors come from programmers not quite understanding the library or language feature they are using.
While reading docs can be tedious, it can help you to understand what problem you're trying to solve...
...even if only to be able to ask for help elsewhere and start by saying, "I've read the docs and I still don't get it."
First, think of the name of the concept/library/feature/language/tool/error. Remember, names have power.
Search for it and half the time you'll find what you're looking for on the first page of results.
If the first page is filled with clutter, add a term that distinguishes what you're looking for from all those other results, and search again.
god vs god of war vs god of war greece vs god of war game
stack vs javascript stack vs javascript stack trace
Then once you find the docs, read the whole page.
If you get an error that you don't understand...
...the first thing to do is not to Google it.
Step 1: read the error
See Read the Error to learn how to read an error.
Often, reading the error reveals enough information to give you an idea for a solution.
Step 2: google the name of the error
You may find a relevant tutorial, blog post, or StackOverflow answer.
Step 3: google the name and context of the error
"context" here means either system information (like file paths) or abstract information (like a problem domain, or the name of a package you're using).
Step 4: Stack Overflow
After googling, you will probably find your question answered on StackOverflow.com.
Remember, though: not all answers are correct. You shouldn't just copy and paste code from the first result.
Read the words, not just the code, in the answer, to make sure the author really is solving a problem that is fundamentally similar to yours.
copy / paste / tweak / repeat
This workflow is far from ideal, but it is acceptable...
... with these caveats:
When a user reports a bug, the first thing to do is to write a test that exposes the bug, then run it and watch it fail.
This assures that you have actually identified the cause of the bug, and that once you think it's fixed, it's actually fixed.
1/14