One of the best ways to access new knowledge is by buying and reading books on a certain technology. But sometimes documentation can be more difficult to understand than the technology itself.
How do you read a technical book, documentation, manuals? Do you select a few chapters? Do you try to implement examples? Do you use a book only as reference for background information? Do you download code and modify it?
The only practice that worked for me was "learning by doing". Just reading isn't enough. Trying to implement the same examples could be boring, so I usually try to think of new ones. That stimulates me to fully understand whatever it is I'm working with.
I usually read the introductory chapters that describe the technology and the book/manual in general terms, and then decide how to proceed. I almost always work with an example by either downloading one and modifying it as I read, or creating a sample project from scratch.
I find the best way is to buy a book to gain knowledge in the area in which you are solving a particular problem.
For example I recently had to implement a build sever using cruisecontrol and nant so I bought a book on deploying software using cc and Nant and then read the chapters as I came across problems which needed solving so I could make educated decision on where to head with the project.
I make sure to have a few questions in mind I want to get answered, preferably from real-life situations. I find knowledge sticks much better if I am actively looking for answers, rather than attempting to dump the contents into my brain...
If I'm actually trying to resolve a problem with the help of reference literature, I skim over the contents and introductory chapters, attempting to zero in on the relevant chapters.
Personally, I'm not much for hands-on testing out example code, but tastes differ. One somewhat useful categorization of learning styles is the visual-auditory-kinestethic dimensions: since I'm mostly visual I'm comfortable with abstractions and diagrams; if you are auditory you would get more mileage from talking to someone; whereas the kinestethic approach always starts with the examples. (Note: few people are purely one or the other, but we tend to prefer one of the learning styles.)
Trick number 1: Adjust your reading speed based on your comprehension; skip through stuff that makes sense / seems obvious (but don't skip it entirely, it may be leading to something interesting). Slow way down and focus I stuff that doesn't make sense to you.
Trick number 2: Make notes of things that seem wrong / off to you, and keep them with the book. They either indicate errors in the book or in your understanding.
Trick number 3: If you get really lost, go back to the last part that you skipped and read through slowly. Repeat as necessary.
It rather depends on the style and genre of the book. Something like TAoCP I'll read the first couple of chapters, then it will sit on my shelf unread for months, but every now and then I'll look something up in it as and when I need a reliable reference for a problem it covers. On the other hand, I read TDD in one evening.
I usually read them cover to cover. I rarely skip chapters on the first read-through, but while reading I will highlight paragraphs and sections that interest me, so they are easier to find when I want to look them up for reference later.
I skim them. The desire is to delve deep into every page and highlight the important stuff, but at some point you're highlighting the same thing in different books. I'll go from page to page reading a few lines in a paragraph and moving on if I think I won't learn anything there. If I see something interesting or that I don't know I'll slow down, maybe back up and start that section again. And I almost never read code samples. Hate technical books with entire programs in them. They're always so abstract or so trivial as to be hard to apply IRL.
What I tend to do is read a book cover to cover building up an index in my mind about what the technology is good for/what it can do. It really helps to do this because you can get a handle on the domain-specific jargon for talking to others about it. I gloss over nitty-gritty technical details until I'm ready to solve an actual problem. Then when I need something specific I return and dig in.
If I go straight to a book, I often find that there are very few technical writers that are good enough to make it easy to understand and/or keep my interest.
Usually I'll play with the technology a bit, maybe read a tutorial or something, and then go straight to hacking at it. After a bit -- when I am not making rapid progress anymore -- I'll go back and read any "good" relevant books. By then I know enough to not get lost or bored with the writing.
If it's a really good technology then often all I'll need later is a little philosophical explanation and a good reference book.
My favorite "how to use technology" book has always been The AWK Programming Language . Short and sweet; it starts easy enough but quickly gets into really complex problems. It's actually great to read even if you're not interested in learning AWK.
My reading patterns depend on the type of book, as well as my reasons for reading it. In a manual, I usually search for some specific point that I want to look up. If the concepts in a technical book are mostly new to me, I tend to read it from front to back, if I am only interested in specific parts I read only those.
What is very important to me is browsing through a book before I buy it. That lets me discard those books that have a low signal to noise ratio (i.e. lots of pages with little new stuff for me).
Skim through it for 5 minutes.
Lay it down on the table.
(Two months pass)
Flick the dust off of it and put it in the cupboard with the rest of them.