Software development entails using several different tools together in harmony to create the end goal. No one ever really knows how all available tools work, that’s why they come with manuals, commonly known as documentation.

I have come to the realization that the difficulty level of a developer’s job depends on how they read the documentation of what they are using.

The Glancer

This reader carelessly goes through the pages of the docs (documentation)  just to get a slight gist and hopefully pick out a few things that may be of help. Getting an idea is more of the goal than understanding. Usually they keep going back to the documentation when they encounter an error in their program. In the end, there will be some pages that never get to see the light of day.

The Dr. Who-Needs-Docs

Now this reader sometimes is not even aware documentation exists. They work with trial-and-error and loads of googling which is probably the worst way to develop programs. This reader turns his/ her job into a frustrating nightmare. They try to make their way blindly through a room filled with furniture that they keep knocking into, and all that can be helped by taking off the blindfold. This way of doing things stretches the timeline of a project because of unnecessary and avoidable bumps on the road. Also, it just makes the developer utterly miserable.

The Peruser

This reader goes through a tool’s documentation from cover to cover before they begin to even use it. I find that these readers research a lot more about what they would need before they begin developing anything. They prepare, weigh pros and cons, and make decisions on the tools they will need then begin to study their respective docs. It may sound like it takes more time, but it actually makes the development process faster because unnecessary errors don’t occur often and debugging (finding and resolving defects in a computer program) is made easier.

The Tab-Switcher

This reader reads the documentation and programs all at the same time. They find the topic in the docs that will help them with their current task and read along as they code away. It may sound efficient on paper but practically, not the best way to do things. Sometimes bugs (errors in a program) may occur and the programmer won’t know what caused them because they are only focused on one part of the docs. Think of it like setting up a TV and the sound doesn’t work but you’re bent on solving the problem by reading the section of the manual that explains the display.

I’d love to know in the comments what kind of reader you are, doesn’t have to be in software documentation, also in normal manuals we encounter everyday.

P.S I used to think ‘peruse’ means to read carelessly until today.