Reading many books is hard. There are so many great books to choose from, and there's too little time to read them all. And with so much literature available, you run the risk of not reading the stuff that is most relevant to your current situation.
So here's what I do.
Though I love reading blogs and wikis, I prefer to read books when I need some serious learning. It's because information on the web is usually fragmented, and doesn't tell you a complete story about a topic from start to finish. The high level of programming experience required on blogs like Scott Hanselman's Computer Zen almost makes me nauseous ("Using Boo for Scripting Banshee", WTF is that?), and wikis, SDK's and on-line tutorials never seem to be written with a human reader in mind ("Now let's switch from dynamic typing to transactional web services, with a bit of cryptography in between, and you can figure out for yourself how those topics are related…").
With books I am able to learn about a topic from the barest basics ("In the beginning there was the Start button…") to the most advanced levels ("And finally, with this undocumented option, you can re-engineer the whole Internet."), consuming a continuous flow of knowledge that is often well thought-out (both logical and understandable). And I can do that at my own pace, which is not too fast, thank-you-very-much.
But, there are problems:
I need to learn about several interesting topics at the same time. I need knowledge about C# 3.0, and about Entity Framework, and about RESTful services, and about SQL Server 2008, and about ASP.NET MVC, and about writing Clean Code…
The order in which I need that knowledge doesn't coincide with reading first one book, and then the next. Because the first chapters of the next book probably give me a higher return-on-investment than the last chapters of the book I'm reading now.
Using physical bookmarks to remember where I am in each book doesn't work well, as I sometimes need to jump ahead in a book, skipping less-valuable chapters that might be more valuable later. This is clearly an agile principle: defer reading things you don't really need to know right now.
Conclusion: I need to read my books in a parallel and non-sequential way.
So, here's what I started doing this week:
I create a sticky note listing all chapters of a book, and I stick it on the first page. On this note I circle every chapter that I've already read. You can see that I skipped chapters 6 and 8 of Programming Entity Framework, because they are about using Entity Framework with stored procedures and Windows Forms. And I'm not using either at this time, so they're not that valuable to me right now. But I think I will read those chapters some time later, so I'm keeping the options open.
I'm also halfway through the book Essential C# 3.0. In this case I've already seen that I don't want to read chapter 20, which is about platform interoperability, which I find completely uninteresting. (Let's face it: wanting to be platform-independent so that you can easily switch platforms, is just as useful as wanting to be bisexual, because it easily enables you to switch genders. Not many people think that's very important.)
My simple new system enabled me to add more books to my "in-progress" stack. I noticed my generic programming skills are in serious need of being polished. So I've added Clean Code to the stack. Every time when I want to do a bit of reading (which, as with every professional software engineer, is almostevery night), I now can select which book and which chapter should have the highest return on investment for the work I will be doing the very next day. While in the meantime, unlike with blogs, wikis, and SDK's, I am steadily gaining a complete picture of some topic. Plus, it gives me not code coverage but knowledge coverage. I know how much I know. And I know how much I don't know.