New to Programming? Here’s How to Better Parse the Results from Googling Your Error Messages
Moving to programming from a field in which my job was to be a human resource library (to provide answers to questions people hadn’t yet realized they needed to ask), it was a big shift for me to rely so heavily on Google, as we do. Especially in the early days, I often wished for a guide to parsing the search results I was trying to slog through… et voilà!
Okay, so you’ve written a function/program/website, and it doesn’t work. Hopefully it’s giving you an error message somewhere — your testing environment, your terminal, the browser console. You copy and paste this into Google, and blindly click on results, but they’re all either completely obscure to you or else quite specific and not what you need. Now what?
First: is it even worth googling?
Some errors are never going to yield helpful search results, especially if you’re writing to a test, like I was in the early weeks of my bootcamp and pre-bootcamp coding. A non-exhaustive list of “errors” that are more technically failing tests:
- Error: Expected 32 to equal 173— Nobody else is going to be working with your same function. Your function is returning data; it’s just returning the wrong data. That’s a starting point you should be able to debug from (if not, see the next section).
- Error: Expected undefined to equal 173 — Still not google-worthy, but now you can see that your function is not returning anything. Are you missing a return statement? Using a forEach when you need a map?
- SyntaxError: homeworkFunction is not defined — This one is actually good news; it’s not hard to declare a function (at least in JavaScript), so if you know you did that correctly, this error means you have a simple syntax error somewhere. Count your curly braces, brackets, parentheses, quotation marks…
- TypeError: Cannot read property ‘keyName’ of undefined — careful, this one will yield Google results; they just probably won’t be relevant to you at this stage. Note that the property named is nearly always the key on an object; your problem, then, isn’t with the key but with the object itself! Keep this in mind as you look over your code.
Your best bet for errors like these is probably to identify where the problem truly is and/or read over the problem/specs carefully, paying particular attention to what you’re actually telling the computer to do, not what you intend for it to do.
How can I parse my errors before hitting up Google?
Sites like PythonTutor take you through your function one step at a time, visualizing how the machine reads your input; rubber duck debugging is also surprisingly helpful, especially for undefineds.
Does your error contain any numbers at the end of the line, like (22:14)? These direct you straight to source of the problem! You don’t have to figure it out yourself; in this example, just head to line 22 and look at character 14, and voilà: whatever’s there is what the machine can’t read.
What about those 8+ lines nested beneath your error itself? It can be immensely helpful to learn to read the stack trace, in time, but for now we can just sift it for the most immediately useful information. Most of the lines in the stack trace may refer to files you didn’t create (node_modules or something built-in, for example), but there’s usually at least one line where the filename is some file you’ve actually worked in. This filename will end in a line number, giving you an exact pointer to where the problem is — or, at least, to the first time your program hit this problem.
I have no error message; what do I search?
If you can’t get to the root of the problem, you’ve still got two very powerful tools at your disposal: console.log* and the debugger.
- Console.log(‘explanatory string’, variable) — Sprinkling these in relevant places in your code can be an excellent way to test 1) what the data looks like in the middle of the function, 2) whether a part of the function is even being run, 3) whether the data being returned is the same type it’s supposed to be, and much more! I love this method for pinpointing exactly where and how my programs are going wrong. However, they can quickly become unwieldy, especially if unlabeled or if left in the code after the bug is resolved. And there’s nothing worse than someone else’s console logs left behind in shared code.
- Debugger — Every browser console has a debugger function, as does every IDE (and PythonTutor does something similar). These permit you to watch, step by step, as the computer executes your function, demonstrating clearly at what step your function is breaking, and what value the computer is receiving for each variable instead of what it should be receiving. This is a must-have for every programmer’s bug-detective kit.
* Every language has these, under some name or other: print, puts… the point is that it sends data to the console for the developer to read, behind the scenes. I expect you already know the relevant command in your language of choice.
Are we finally ready to search yet?
Okay, after you’ve reasonably exhausted your more basic options — or if you’re feeling lazy and choose to skip some of them (I don’t judge; I just don’t vouch for the relevance of the results in that case) — we’re ready for Google. But let’s do this efficiently; what’s the best way to bring up relevant results on the first page?
- Narrow the scope of your search: What can you figure out about the root of the problem? Phrase that concisely, as generically as possible, with appropriate jargon.
- Add the name of the language and/or tech you’re working with to your search terms! The solutions may be the same in principle whether you’re working in JavaScript, Python, or Ruby, but until you’re experienced enough to translate, cut yourself a break and look for what’s familiar.
- Results appear outdated? (More on how to tell this below.) Append @2019 to your search string to prioritize recent results (or whatever the current year is — hello readers from the future; I’m flattered you still find this useful).
- Before naively searching your error message, delete your filenames and variable names, or replace them with *. This is especially important (the *) if you decide to enclose part or all of the error in quotation marks.
Great, we’re at where I started before reading this, thanks
Well, If you’re feeling that impatient, I hope you just skipped the bits above! (But we’ll talk about skimming in a moment.) Now let’s look at which results to click on and how to figure out quickly whether they have anything to offer you.
Occasionally you figure something out just by looking at your list of results, before even having to click on any! Usually that conclusion is just that your search terms were unhelpful, either too narrow or too broad. (See the next section.)
Conventional wisdom suggests the following hierarchy of programming websites:
- Official documentation of the language/library/whatever
- Stack Overflow
- Medium, Github gists (tie)
- Reddit, other blogs (tie)
So let’s take a look at these. Wherever you go, it’s tempting to open a page and just begin reading, but we can be more efficient than that! It’s entirely possible that your search terms don’t appear in a relevant way anywhere on the page. So a good first step is always to do a simple find (cmd-F/ctrl-F) for some of them. This doesn’t always indicate that you’ve found a winner, but it’s great for weeding out lemons quite fast!
Official documentation
This varies wildly depending on what language, what library, what piece of tech you’re using. Mozilla’s excellent docs for JavaScript are considered the industry standard for JS, and React’s official documentation is likewise extremely thorough and easy to navigate.
On the other hand, the docs for Sequelize, despite appearing extensive, are so notoriously unhelpful that my bootcamp actually recommended we use an alternative! To look to a different category, the Spotify API also provides documentation that is woefully inadequate to the mammoth task of working with it.
So it’s always a good idea to start here (possibly even before you hit up Google), but if you come up short, know that it’s not just you.
Stack Overflow
Stack Overflow designed their site to have the best answers to every programming question (a model so effective they cloned it for numerous other subjects). To manage this, their threads are less conversational and more answer-driven, with users voting to make helpful answers rise to the top. They also endeavor to avoid repeat questions on the same topic — which means that the questions hosted there tend to be very specific!
I don’t know how many times I laboriously tried to puzzle through 50+ lines of code before discovering that the original poster’s problem bore no resemblance to my own! I do not recommend reading the post carefully, except maybe if you’ve already determined it will be helpful.
Instead, head straight for the comments. Remember that OP is there in the first place because their code is buggy! The real meat is in the replies; after you have a potentially useful idea from there, you can skim the original post for context.
Medium
Medium has a lot of tech hubs, but you needn’t look for one of those to confirm that a post’s content is trustworthy. The thing you can rely on in a Medium article is a high proportion of words to code. So if you learn well by having someone narrate for you where they went and how they got there, Medium will always be a good site to favor.
Github
Github is mostly known for its code repositories (❤ version control), but it also has gists, which are single-page repos — with comment functionality — that can hold anything from a brief snippet of code to a full article’s worth of code and explanations. In practice, I’ve found most Github search results to be gists that function rather like unmoderated Stack Overflow questions.
I really expected reddit to be a brilliant resource for coding questions, being such a nerd hotspot; and there indeed are plenty of programming subreddits, but it seems that most redditors jump ship to someplace like Stack Overflow once it’s time to ask or answer a complicated question.
Other blogs and websites
The internet’s a big place! It contains other tech blogs, other forums, but the patterns are the same as what we’ve already seen here. I’ve found it to be surprisingly reasonable to trust whatever you’re reading on a random website, though. If you’re looking at something this technical, chances are very good the author already considers you “one of us” and is more interested in helping you than misleading you. (Of course, they may have their own bugs in the code, but how else do we learn?)
But none of that did it! Refining or reorienting a search
Sometimes it’s clear how to refine a search: if similar-ish errors are coming up (but not similar enough to be relevant to you), put the most specific part of your search terms in quotation marks; if the answers coming back address React alone, say, but you need them to address React and Redux working together, add redux to your search terms. If it’s not clear, see whether any of the tips above look sensible, with the new context of the search you’ve just finished.
No results, or too few? Remove quotes, or add terms, and see if that changes things. Otherwise, you might be stuck with the worst case scenario:
One notable exception: Are you trying to resolve a problem or confusion with Git, and the search results just aren’t cutting it? Is there any way at all for you to save your work in your local filesystem and bruteforce reintegrate it? This doesn’t sound ideal, but it’s exceptionally common practice, especially for the more unusual git commands.
Some closing notes
Here’s hoping that helped! Now, of course, getting the code to work is only half the battle (even if many coders do tend to stop there). Understanding why can save you the exact same search stress in the future. (I keep a list of lessons I’ve learned from particularly thorny bugs.)
Sometimes even Google won’t provide helpful answers, at which point I’m very grateful that software is such a social community. Reach out to a friend or co-worker, or (if you understand your bug in enough detail) even ask Stack Overflow.
And don’t worry! Remember that, in this field, everybody is always learning, so there will always be strange new error messages for you to Google, no matter how skilled you get!
