I have picked up a few new tools this summer (MongoDB, NancyFx and WebAPI), and it occurred to me that I’ve built certain habits these last few years in how I make use of all the learning resources out there.

I tried to identify all of them, to then categorize them, to finally order them according to in which phase of my study process I use them.

The written and spoken word

The first thing I look for online is documentation. It might be a coincidence, but all the documentation I found for these three tools was excellent. It seems obvious, now more than ever, that the early adaptation of new tools can be proportional to the quality of their documentation.

When there is no documentation - studying a concept instead of a technology, when the documentation is too dispersed, or when the quality is too low, I might order a book. The problem with technical books though, is that they are often too lengthy. I think the first publisher that cuts down on the number of pages, while guarding quality, will be pleasantly surprised by demand. I really like the “Little book” format Karl Seguin has been experimenting with.

When there is no documentation, and there are no books, I find myself turning to the spoken word. In general, I prefer reading over watching and listening because I can do that at my own pace, skip chapters, or quickly skim back for a look-up.

Although often on the slow side, the videocasts from Pluralsight are not bad. If you don’t want to subscribe to one of the paid videocast services, you can also watch recorded conference sessions instead. Before I commuted by train, I also listened to relevant podcasts.

Getting intimate

As I wrote earlier, I am a strong advocate of learning by doing. Find something small, and build it.

When I’m using a new tool, I also tend to regularly peek at its internals to improve my understanding of how the tool works under the covers. It’s never a bad idea to get intimate with the tools you rely on.

This becomes extremely easy when the tool you are using is OSS and uses a source control provider that makes it easy to browse or fork the source - read GitHub. If the tool isn’t OSS, you can still decompile the sources using one of the free decompilation options out there. If you have a Resharper 6 license, you can even decompile straight from Visual Studio.

Sipping from the fire hose

Once I start building something, I crank open the fire hose - Twitter Search, and take a sip. Although trying to consume all the information on a subject is hardly bearable, and feels as being waterboarded at times, I think it’s a necessary evil. Until you have assembled your personal digest, that is.

I’ll do my best to keep up with the Twitter Search feed for a while, and try to filter knowledgeable people to follow, blogs to subscribe to, and repositories to watch. Once I have a qualitative list of subscriptions, I’ll shut off the fire hose, and limit my consummation to my personal high quality-to-noise digest. This digest will serve as one of the biggest aids in continuously improving my knowledge of said tool.

Free pop quizzes

I always thought that if you really want to become good at something - become an expert, you must have spent time in the trenches, knees deep in shit. Experiences like this force you to broaden your understanding of a technology.

Next to problems you encounter producing things, you can also simulate this experience by following Stackoverflow questions and commit to help solving them. The less ambitious can also wait a while, and just skim over the questions and their answers. The same goes for mailing lists obviously.

I’m very curious to hear about the techniques you use to unravel all the information out there.