I would like to start by declaring that very, very few software manuals are can be read cover-to-cover and offer great benefit. There are some exceptions to thi

I would like to start by declaring that very, very few software manuals are can be read cover-to-cover and offer great benefit. There are some exceptions to this--the one that comes to mind the most is Ableton Live's manual. 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.