Back when five bucks' worth of dinosaur squeezings bought you a misspent weekend, working in technology required desks, and the reason for desks was to have a place to lay out your manuals. Massive hole-punched tomes ending in "Guide" and "Reference" were techies' bread and butter. It was so taken for granted that you had manuals that RTM (we'll go F-less now that we know what we're talking about) became shorthand for "go look it up; you might learn something by accident."
Sounds haughty, doesn't it? It often was. RTM was a blow-off when uttered by wizards and gurus who had no penchant for teaching. These snobs missed out, because nothing tops the feeling of accomplishment shared with someone you've mentored, and that road has to start in a book. I'd loan them the book and tell them where to start. I knew that anyone who borrowed the book would show up shortly with their own copy and a fire in their eyes.
Glancing over at my bookshelf now brings to mind the delivery of a System V UNIX from a company called SCO. The box was bigger than the company, and infinitely more durable. Hauling an x86 operating system (not a system, mind you) indoors on a dolly is a notion foreign to most readers. But I owe those cheap cardboard three ring binders, and many more like them, a hefty hunk of my lifetime earnings, and the stirring of passions that keep me in this field even now. Something about having a sagging shelf full of books stare you down every time you sit at your desk tasks you to learn. No matter how smart you get, there's always a page in there you haven't read, and on each page of consequence, there is a detail or source of inspiration that you've missed.
You can go into a manual looking for an answer, and come out with knowledge. These days we so easily confuse the two, and it shows. Using software for illustration, we can all agree that they don't write it like they used to. The reason is that developers don't allow themselves the time to look things up before they use them. Statement completion, context-sensitive help, generated code, unit testing, and automated analysis came about expressly to eliminate research and experimentation from the development cycle. The result, I think, speaks for itself. How many rookie coding blunders that lead to security vulnerabilities grow out of inadequately understood usage of a method or resource?
My affection for paper manuals is not rooted in eco-insensitivity, although I do believe that a felled tree is a fair trade for a filled brain, and probably the path to that end with the smallest carbon footprint. However, a MacBook Air can carry the equivalent of several Banker's Boxes full of manuals. Is there something magical about paper?
It dates me to say so, but there is magic in paper. The simplest example I can think of is the difference between leafing through a book and scrolling through a PDF file. When you're aimlessly flipping through the pages of a printed manual, your eye captures information faster than your brain processes it. You end up going back to material that you flipped past and saw only for a fraction of a second, but which your brain registered as a subject of interest. I don't get that from PDFs except where the flow is disrupted by a chapter title or illustration. Even with framing and shadows to simulate dimension, it takes a lot of practice to train your mind into seeing a GUI window as an object that it should snapshot and analyze as a unit. You've got an advantage if a computer was the most common vehicle for visual communication when you learned to read.
Here's where you expect me to say that I print the manual. No. MacBook Air is the right home for my manuals. These days, when I go looking in a PDF manual for an answer, I read the whole thing. By doing this, I am training myself to snapshot and scan scrolling PDF pages as they fly past. It isn't the medium that makes RTM good advice. It's the approach. Don't go to documentation looking for answers. Go looking for knowledge, and the answers will come along for the ride.