“Can you help me for a second?”
Just F***ing Google It.
How to take this advice.
Every new programmer has gone through it. You get an error and all progress screeches to a halt. Maybe you go out on a limb and ask another programmer for help; maybe you post a question on a message board. At some point, you’ll get the slap in the face: “Just f***ing Google it.”
Before diving into strategies about effectively utilizing Google to find a solution for your problem, let’s take a moment to unpack this advice — because it is advice, and not just a dismissal.
If you don’t know what the “it” represents in, “Just f***ing Google it,” you’re going to have a difficult time finding the “it” in, “It worked!”
“Just” is in there because we all know how to use Google — you type words in, you get pages back. The interface is not rocket science. But similar to all things that take minutes to learn and lifetimes to master, there are layers of nuance involved in getting what you want out of Google. If you put garbage in, you’re going to get garbage back. People with strong “Google-fu” are people who have learned to stop using the search engine like a garbage disposal masquerading as a wishing well.
Depending on the situation, the “f***ing” may or may not be called for. Most people are pretty nice and helpful at first, but everyone reaches a breaking point. If somebody escalates their response with colorful language or a harsher tone, it could be an indicator that you need to pump the brakes. Many new programmers latch onto the first helpful resource they encounter, and when that resource is another person, it can be incredibly draining. I say this as a former AP Computer Science teacher who handled this question much more nicely (and more frequently) than your coworker. Learning how to find answers on your own — without the help of another person — truly is the barrier that stands between dabbling with code and solving problems or delivering products as a professional.
“Google.” What is it? In this case, it’s a verb, but what even is Google? In the spirit of this post, please watch this video made by Google, then come back. In a nutshell, you put words into the search bar, Google uses a variety of methods to guess what you’re looking for, and then it returns what it “feels” are the most relevant results. This might sound patronizing, but understanding this interaction is a key step in getting the most out of Google — the words you put in directly affect the results you get back. If you’re trying to figure out why you got an error and you copy and paste your error into the search bar, you’re probably going to get results from people who just copied and pasted their error into a message board (which may or may not be helpful). Learning how to effectively Google means becoming mindful of the combinations of words you put into the bar, including terms that enhance the odds of the search engine’s algorithms returning helpful pages, and deliberately excluding the terms that muddy the waters.
Finally, we come to the most loaded word in the title of this article (yes, even more so than the f-bomb): “it.” I’ve found that most people don’t really struggle with understanding the first three words; their problem rests almost entirely on their interpretation of this final one. If you don’t know what the “it” represents in, “Just f***ing Google it,” you’re going to have a difficult time finding the “it” in, “It worked!”
Now that we’ve broken down the title of this article, let’s talk about how to actually get your answer from Google. This isn’t going to be a list of tips and tricks — there are plenty of other resources for that. This is going to approach Google as a tool in your debugging toolkit, instead of as a panacea for all your programming woes. You might be surprised, given the title of this article, how little time we’re actively going to spend on Google.
Let’s break down our Googling strategy into three different phases:
- Pre-Googling. What should you do before you head over to Google? What pieces of information do you need to bring with you?
- Googling. How can you interact with Google effectively? What increases the odds of getting a helpful result? What decreases the odds?
- Post-Googling. What if you solved your problem? What if you didn’t solve your problem? Next steps for both situations, and tips for reducing your Googling needs.
I’m gearing my example questions and word choice towards Python programmers, but the same general advice should apply to most programming languages.
1. Pre-Googling
Like with most tasks, it’s always a good idea to spend some time planning before you dive into doing.
First, make sure you understand what your code is supposed to be doing. You should really know the answers to the following questions before you start asking anyone, including Google, to help you with your code. Do not wait for somebody to ask you these questions. That’s the quickest way to get a coworker to burn out on helping you.
How do you know there is an error? This can be an easy answer when an error message is produced, and a difficult one when the code runs, but produces unexpected output. More on that in a minute. But take a moment to be very deliberate in identifying the dead giveaways that you have an error — this will help you recognize them in the future.
What line of code caused the problem? This can be a tough one to track down if you don’t run (or compile) your code often enough. In order to make it easier for you to answer this question, you should really be testing your code more frequently. I’m talking like, add a line, run your code, make sure that line does what you want, then add another line, run your code, and make sure that line does what you want. If you’re doing this, you’ll both understand your code better and make it easier to track down the bug. Hint: If the code was working until you added that last line, which line might have caused the problem?
Is it a syntax error? This type of error prevents your code from even running or compiling in the first place. Syntax errors are problems like forgetting to close your parentheses, forgetting a colon at the end of anif statement, or not aligning your indents properly. I hope you will respect the spirit of what I’m about to tell you: if you’ve been programming long enough to be drawn to this article, you should not be asking anyone to help you fix a syntax error, full stop. Everyone makes syntax errors while writing code, and everyone who continues programming eventually learns to deal with them on their own. Asking for help with them only delays you from developing that resilience.
Is it a runtime error/exception? This type of error occurs when your code starts to run, then halts due to some expectation not being met. Generally, this will be accompanied by a stack trace, which is a cascading list of the function calls that eventually resulted in an error. Learning how to read a stack trace is a critical skill in developing your debugging talent, so I strongly recommend reading that linked article if you find them confusing. Runtime errors can be tricky because they generally arise not from small mistakes in single lines, but from mistakes made in how functions and objects are supposed to interact with each other. You should familiarize yourself with the main types of runtime errors (mentioned on the same page) in order to start wrapping your head around what typically causes them.
Is it a logic error? These are the most frustrating and insidious errors in programming because unlike the previous two, they do not announce their presence. The code runs perfectly, and it does exactly what you told it to, but the problem is that you didn’t tell it to do exactly what you wanted. Logic errors are specific to your particular program, and are virtually unGoogleable. To find help with a logic error via Google, you need to break down your problem into Googleable components.
What is the piece of code supposed to do? In order to get code to do what you want, you have to actually know what you want from it. Clearly define, in words (not in thoughts), what you want to happen when that line of code runs––in other words, rubber duck it. Be very, very specific, and avoid that loaded word, “it,” which tends to replace the nouns that are causing us the most trouble. Write a comment explaining to yourself exactly what values you expect to be in each variable before that line executes, and exactly what values you expect to be in each variable after that line executes. Read the documentation for the functions you call in that line. Did you pass it the types of values it was expecting? If you’re working in a dynamically-typed language like Python, how do you know what data type is in each of the variables you passed to the function? What is the function’s return type? Are you handling that return type correctly? If you’re calling a method on an object, does that object even have that method? Have you even instantiated that object? Could there be any default values you’re overlooking in the object’s constructor or__init__ method?
What does the line of code actually do? Answering the previous question gives you a head start on answering this one. Compare your expectations with your reality. When you know exactly what you want your code to do, you can more readily identify areas where it is failing to meet your expectations. Often, answering these two questions leads you to an answer without even needing to Google anything.
Can you reproduce the problem with another, smaller, piece of code? In order to better understand your errors, you can always open up a new program and deliberately try to cause the error you’ve encountered. Doing this forces you to understand what your code is really doing, and gives you a structured reason to do a deep-dive into the internals of your programming language. Use the scientific method, but be careful — you’re applying the scientific method to the hypothesis, “This code will cause the same error as my code,” and not to the hypothesis, “This will fix the error in my code.” People who are good at identifying and resolving errors tend to be people who are good at engineering them.
2. Googling
Once you’ve identified your expected behavior and your observed behavior, you can turn to Google. Remember that Google works by finding web pages that have somehow associated themselves with the search terms you enter. If you’re too specific, you run the risk of typing in a combination that is not associated with any helpful websites. If you’re too vague, you run the risk of getting websites that use those terms in entirely different contexts.
A helpful thing to Google is the error message itself — just the error name and error message, not the entire stack trace (which is specific to your situation). People frequently ask questions about specific error messages on websites like StackExchange, so if it’s a message coming from the core of your programming language or popular libraries, there are almost guaranteed to be websites associated with the text in that error message. It’s worth familiarizing yourself with StackOverflow’s strict rules on how to ask questions, so you can find the information you’re looking for more quickly, and learn how to ask better questions in the future. The most helpful answers will probably fly over your head at first, but many of them can shed an incredible amount of light on what’s going on behind the scenes.
If that didn’t work, try Googling just the name of the error you encountered (e.g. TypeError, ValueError, or OverflowError, and read about what might cause those types of errors. Try to understand examples of code that lead this error on StackExchange, and you’ll learn to start recognizing their hallmarks.
If that doesn’t work, try to pick out a small collection of words or phrases that summarize the issue. These are generally going to be nouns and verbs. Words that tend to be helpful here are the name (and possibly version) of the programming language you’re using, names of the classes or modules/libraries involved, the names of functions you’re trying to call, the types of variables involved, and the verbs you’re trying to pull off. If you were going to make a post asking for help and could only include five category tags, what would those tags be?
If you still haven’t found help there, try Googling the name of the class or method with the word “documentation” in the query. This will lead you to the library’s official documentation, which will (hopefully) explain in detail how to interact with those classes and methods.
The more you break down your problem prior to Googling, the more you’ll see these key words and phrases start to emerge.
If you want to learn how to Google well, try Googling how to do it. No, I’m serious — literally Google the phrase, “how to google well.” You’ll get a wealth of tips and tricks about terms you can include in your query to modify your results. For example, you can enclose a specific phrase in “double quotes” to return only pages that have exactly those words in exactly that order — compare the number of pages returned when using double quotes to the number of results returned when leaving them out. Or You can say site:nameofwebsite.com along with your search terms to limit your search results to nameofwebsite.com. You can exclude search terms — for instance, if you’re trying to understand the concept of inheritance in programming, but you keep getting results for inheritance in Java, you can include -Java in your search terms to return only pages that do not contain the word “Java”. You can start by Googling a large phrase, then remove the least relevant words one at a time. Alternatively, you can Google one word at a time, and gradually add more relevant words. If you experiment with these features and pay attention to how they affect the number of pages returned, you’ll start to develop an intuition for what an effective Google search feels like.
3. Post-Googling
If you’ve fixed your error, yay!
Before moving on, take a moment to reflect on how you got there.
Jot down a quick explanation and some minimally reproducible code in a personal error log with an explanation of how you arrived at that error, and if you ever encounter it again, you’ve got an explanation in your own words of how you fixed it.
Bookmark useful pages you found, so you can skip Google all together and jump straight to the pages that helped you the most. This might be pages on geeksforgeeks or ww3schools, the official documentation, a tutorial that happened to explain what you were trying to accomplish, or even a helpful series on YouTube.
If you did not fix your error, now is a good time to ask for help. Identify someone who seems helpful and doesn’t seem busy, ask if they have a couple of minutes to help you with an error, and explain the error to them. Give them context. Tell them what you were expecting the code to do, and what the code did instead. Tell them the things that you’ve done to try to fix the error, and why you think they didn’t work. Tell them what references you’ve checked. If you were able to reproduce the error, explain the major takeaways from that process. Give them as many pieces to the puzzle as possible so they don’t have to try to tease them out of you.
Show your code to that person as a last resort. When it comes to the code that you have written, you are the subject matter expert. Nobody knows what you were trying to accomplish better than you do. Helping you debug your code requires you to transfer as much of that knowledge as possible to the person you’re asking for help, because no bugs happen in a vacuum. Simply understanding the context of that single line might be a monumental burden to place on that person’s shoulders. The person helping you work through your bug will have to go through all of the steps that we went through in the pre-Googling stage — and it may turn out that they have to turn to Google themselves. If you’re going to ask for help, be respectful and make it as easy as possible to help you.
When you ask questions judiciously, provide ample evidence that you’ve exhausted all options before turning to someone for help, and give that person all of the information they need to help you find an answer, you give them significantly less reason to tell you to, “Just f***ing Google it.”
