← Back to Blog Page

Google Better

Posted on August 11th, 2016 in Debugging, Searching by Ben Sears

When a developer encounters an issue the first thing they usually do is google it and hopefully google spits out a good answer in the form of a stackoverflow post detailing exactly what to do.

When google doesn’t immediately surrender the solution, don’t fret, you might still be able to get what you need by changing the tone of your google-fu.


The easiest way to filter results is by adding clarifying tags to the end of your search. For example if you get a php error message, make sure to clarify what system is using php so instead of googling “File not found” google “File not found drupal”. This will cut down on the useless information since generic error messages lead to generic results, this should be obvious to most but some still manage to just google the error message with clarifying what threw the error.

Avoid Irrelevant Information

Learning to look at a page filled with search results and being able to tell which links are useless to your plight will cut down on the time you spend trying to fix a problem. It’s difficult to give pointers on how exactly to do this since it really needs to be taken on a case by case basis. If you are developing on a platform that has changed over the years a lot - looking at old stuff may be completely useless to you.
The key thing to keep in mind is if you are dealing with a generic errors that languages throw, try and avoid the pages that have the error message but are built using a completely different system. For example if you are getting a mongo db error and your application is written in javascript, it usually is better to stick with results that are written in javascript instead of say python or ruby even though they are both using mongo db.

Clean up your search

This is a given - if you see things like line numbers, environment specific strings (like your table names or page names) and timestamps - delete them from your search since they will only confuse google.

Try and only google the main error - when you look at a stack trace the best part to search for is the part that was thrown by your code. It’s rarely a good idea to search for errors thrown by one of your dependant libraries or modules since those hopefully aren’t as bug filled as your own code is, although sometimes it’s inevitable and you will find bugs caused by your dependencies, it’s good to ignore that possibility until you’ve exhausted your own code being the culprit.


All in all, these tips are meant to help developers research their issues in an intelligent way instead of just aimlessly searching for the solution. If anything should be taken away from this it’s to think before you search and you may save yourself some time and time is your most valuable resource because you never get it back.