Avoiding Thick Technical Books

I picked up and poignant tidbit from <a href=”http://joelonsoftware.com>Joel Spolsky</a> after listening to a recent podcast on IT Conversations. Joel was talking about the big technical book boom of the dotcom era and that publishers noticed a trend that often the bestsellers in a topic area were determined by book with the thickest spine. Thus publishers began delivering more and more books that were breaking the 1000+ page barrier. Readers apparently having no better criteria to judge by were apparently buying the thickest book assuming it covered the material in more depth.

From a personal standard, this is almost the opposite of my approach. From my standpoint I have a limited time as a manager to delve into new areas. Thus I want to be able to dive into a topic quickly and get a good understanding without being buried in example code which often doesn’t even compile. I detest most of the 2″+ stuff with 8 authors most of which is a waste of bandwidth. And I do appreciate these days that every web technology book doesn’t begin with two chapters on the history of CGI to today anymore or explain the great issues with the stateless web or even better the huge difference between HTTP Post and Get.

So lately I find myself really enjoying the Pragmatic Programmer Series or some of the O’Reilly’s Developer Notebooks, and I actually read all the way through them. I still buy plenty of thick books, but they’re almost always more reference types like JUnit Recipes or J2EE Web Services. I never read all the way through them.

The only recent contradiction of this recently is that I picked up Holub on Patterns after attending a talk of his at SD West 2005. I read straight through the first hundred pages or so of his critiques of Java versus true OO, and then blew off the rest of the book which was basically some elaborate code examples of many of the GoF Patterns.