Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 536 posts at DZone. You can read more from them at their website. View Full User Profile

Debugging: Google vs The Manual

07.13.2012
| 3017 views |
  • submit to reddit

Over the last six months or so I’ve worked with a bunch of different people and one of the things that I’ve noticed is that when something isn’t working there tend to be two quite distinct ways that people go about trying to solve the problem.

The Manual

The RTFM crowd will go straight for the official documentation or source code if needs be in an attempt to work through the problem from first principals.

While this approach is more admirable it isn’t always quicker, especially if the reason that something’s gone wrong is because of an obscure dependency or something similar. That type of problem is unlikely to be documented!

On the other hand, if you’re an early adopter for something then you probably have no choice other than to read the source since the documentation probably doesn’t yet exist!

Google

The lazier amongst us will copy the error message and keep deleting parts of it until Google turns up a useful result.

This approach works pretty well when working with popular software/tools where the likelihood of someone coming across the same problem and posting about it on a mailing list or blog is higher.

It’s often possible to work backwards from a similar problem that someone else has to solve your own problem.

This approach works less well for obscure and/or proprietary software/tools where the community is less established and people haven’t reported problems.

Overall

A combination of the two approaches is what most people end up doing, although it’s interesting watching how long they’ll persist with their favoured approach before switching!

I fall in the second camp and a reasonable percentage of my blog posts consist of me recording problems I experienced so that other people don’t have to search for ages if they come across the same thing in future.

Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Stephane Vaucher replied on Sun, 2012/07/15 - 1:24pm

I've been confronted by too many people focusing on trying to Google a solution for a Q&D answer. The problem is that they use Google to find a solution when they should be using Google to find out what's the problem.That's a problem with their education/training.

Lance Semmens replied on Wed, 2012/07/18 - 6:00am

There's also an excellent option 3 - The mailing list

I'll often post a question on project X's mailing list if RTFM and Google fail. I make sure to post my answer on the thread so that Google will work for the next poor sod.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.