Join the DZone community and get the full member experience.
Join For FreeOver 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!
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, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments