Ask HN: How to RTFM?

I think you have to change your attitude and get used to reading that language, and learn how to write it, too.

It is the language of engineering specifications.

I recommend reading at least one standard (e.g. programming language) in its entirety.

Things refer to other things; at some point, you need the transitive closure of the whole darn thing in your head to properly understand any part.

Clearly, the most common use case for a manual is when a user has encountered a situation where they don't know how to use a product as it should be used. Here are two examples of different scenarios where RTFM as ended in different ways:

* Keras: I'm currently optimizing the architecture of an artificial neural network at work, and I needed a little more detail on how quickly the network was training. The Keras documentation quickly guided me to the Callback section, where I quickly learned what callbacks were, and then found the CSVLogger callback. Not only did the documentation link directly to the source, but I thought the documentation gave a good high level overview of what the function did so I could see that clearly this was the function that was going to solve my problem.

* Vim: I use vim quite frequently at work as my main editor, and some of my co-workers also use it. Recently, I had asked a coworker how he configures vim for his projects, and he told me about Vim sessions. I asked him for more details about how vim sessions and tabs worked, and he referred me to the vim documentation. While the explanations were clear, I've always held the opinion that the vim documentation is a bit of pain to navigate, and suffers greatly due to the lack of example vimrc snippets. Maybe others think differently than I, but I've learned much more vim through blogs and vim-tutor than I have through vim's own documentation.

The biggest piece of advice I can offer is that regardless of the quality of the documentation there is always some guarantee that the official documentation is not the only documentation out there. It is quite rare that I ever truly grasp an answer or new piece of information on the first read; I often need examples or further reading for me to incorporate that information into my everyday life.

All that being said, start with official documentation. I can't say for certain, but in my experience it has always been the most authoritative and the highest quality writing on the software itself. Seek out blog posts and unofficial technical writing for further examples or different writing styles that might be easier to grasp.

I'm not sure how it compares to those works of the past (perhaps less detailed?), but I found it much more approachable than most languages' documentation and more in-depth than most languages' tutorials.

The old ways may not be entirely lost.