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!

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.

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.