- print statements
- interactive debuggers
- stack traces
- rubber ducks
- in-browser dev tools
"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
you can't google an error until you know the name of the error
Google to Learn
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."
tech support cheat sheet
How to Google
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 of warvs
god of war greecevs
god of war game
Then once you find the docs, read the whole page.
- Don't just skim for code snippets!
Google is not a Debugger
If you get an error that you don't understand...
...the first thing to do is not to Google it.
Modern Debugging: Step 1
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.
Modern Debugging: Step 2
Step 2: google the name of the error
You may find a relevant tutorial, blog post, or StackOverflow answer.
Modern Debugging: Step 3
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).
- be aware that some parts of the context will be specific to your personal setup
- e.g. the first part of full file paths
- you may need to delete these parts and search again
Modern Debugging: Step 4
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 similar to yours.
SOOP: StackOverflow Oriented Programming
copy / paste / tweak / repeat
This workflow is far from ideal, but it is acceptable...
... with these caveats:
- you must write unit tests, to prove that the code
- (a) does what you want
- (b) doesn't do anything you don't want
- you should refactor the code after you get it to work
- you must at least try to understand it, then mark (with a code comment or commit message) what parts of the code you don't understand
- you should put a code comment with a link to the StackOverflow answer, so future coders (including you!) can learn more about how it works and why it was needed
Write a Failing Test
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.