Sun 07 April 2019 | tags: learning, reading, documentation, -- (permalink)

It is a well known fact within our circles that one of the quickest ways to get started with any piece of technology is to get started using it. This has been proven time and again to be an effective method for kicking off with programming tools.

The downside to the above approach is that, if the learner fails to follow up their early success with some studying of the documentation that was created to enrich the knowledge gained, they would have very limited understanding and would likely abuse the technology, not mentioning the myriad of times they would be needlessly stuck with making progress with the technology.

Reading documentation has a lot of advantages, some of which are immediately apparent. These include versatility with that technology the documentation is about, clarity of areas that might have seemed hazy to the learner, best practice information as well as something else like it: knowing the right (recommended) way to do a thing with the technology.

There are more benefits that await one when the effort is made to peruse the documentation backing some technology. One can better teach a technology or even make a public presentation on it, for instance.

Most times, the documentation is written by the author of the project. Based on this, it is safe to say that the author pours out their heart into the writing, often better communicating their design decisions. I have previously quoted Armin Ronacher on the importance of gleaning design decision here.

The book knowledge cannot be overemphasized.

Programmers need to have this factful statement ingrained as they go on in their creative journey.