I am big on books (in fact since Amazon introduced one-click ordering I have to be careful when I go there).
I generally read the first third or half of a book in great detail to
get the basics. When I get to the detailed stuff, I generally
skim it.
My philosophy: No can know everything. It's better to get a
broad, shallow knowledge of the technologies. Then, when you have
a problem to solve, you'll know which technologies or techniques to
investigate to find a good solution.
For example; I know what XSLT is capable of, but I don't know the
syntax. This is because I have only used it twice, so it's not
worth the investment to learn it. If you need the syntax details you
can look in a book or on the web.
On the down side, this approach doesn't go down well in job interviews
(in my experience, at least). I had one interview (for a senior
C# position) where I was asked to write (on paper) a complete XSLT
transformation from the top of my head. They didn't actually ask
me about C# which was a bit weird.
Many interviewers expect you to have detailed knowledge of the specific
technologies they want. They want people who have memorised the
details. They don't generally seem interested in recruiting smart
people who can cope with any technology by using their brains to figure
thing out and learn on the job.
It's kind of a similar problem with Microsoft certification: the exams
seem to expect you to know all the details for all the
technologies. This is fine if you are writing all your code in
notepad, but VS has Intellisense so I never bother memorising details
because I'll recognise the object/method/property name when I see it in
the dropdown list. I spend my time learning about higher level
techniques like architecture and design patterns because by the time
I've learned all the ASP.NET details, ASP.NET v2 changes them.
Rant over.
Herbie