Marco Mastropaolo

Jeff Atwood mad some explicit about technology books here: http://www.codinghorror.com/blog/2007/10/do-not-buy-this-book.html. At first I was astonished and strongly disagreed with him. Later I thought about it, digested its meaning and must admit, I agree.

So this is a how I will choose which books I will buy or not:

Buy

• Books about architecture, design and techniques – design patterns, dependency injection, test driven development. Interestingly also useful are books of these topics applied to a specific language. Even more interestingly, also useful are books of these topics applied to a specific language you broadly know but don’t use. In particular, you can mix and match books on these topics between Java, C# and ActionScript whether you are a Java, C# or ActionScript programmer. Doing the “translation” (adapting examples to missing language features, etc.) might even help.
• Books about the fundamentals of a technology you know nothing about. This means that if you have to learn say Silverlight and you are a Java programmer, buy a book about C# and XAML. Do not waste time in buying books containing practical examples like “form validation” or “how to create modal windows” and so on. There’s Google for that.
• Books about organization and (self-)management practices. From The mythical man month to I.M. Wright’s Hard Code, you can’t go wrong with this kind of books. With “you can’t go wrong” I mean that even if you pick up an obsolete, wrong and heretical book about soft topics you’ll find more food for thought than by buying a “recipe” book with solution for specific problems. An unexciting book on Waterfall planning gives you more to think about than “how to make round corners in CSS”, which takes a whole 5 seconds to find out and other 5 seconds to forget (there is also no reason you should remember this, unless you do front end formatting every day, in which case you’ll remember it anyway).

Think twice before buying

• Books about examples which teach you the questions instead of the answers. These are difficult to tell from plain examples books. The difference is in the details: instead of telling you how to do something, these tell you how to fish, but they still do it through examples. You can usually tell them apart because the examples are thoroughly explained in detail, and become food for further thought instead of pre-cooked solutions of your problems.
• Books about examples for some (but not all) DSLs (domain specific language). Things like regular expressions, XSD schemas, XSLT transformations and GLSL/Cg/HLSL shaders are best learned through examples. The complexity of a shading language – for example – does not lie in understanding the concepts (which are rather basic) but in finding a way to apply them to real problems (lighting, mapping, etc.); examples provide real ways to overcome this difficulty. I wonder if the same approach could be used for parallel assembly language (MMX, SSE, AVX) since it shares the same problem (easy instructions of which the purpose is almost impenetrable). More complex DSLs (like SQL) require a more conventional approach.
• The “complete reference” of <anything>. You already have the “complete reference” of <anything> book. It’s on your keyboard, top-left,  and is called “F1”. Books named “the complete reference” really are divided in two parts: a first part, teaching you the basics and which may or not fall in the “buy” category, and a second one which is “the useless reference” which is little more than the online help dumped on paper. You are actually paying (in money, weight, etc.) for 1000 pages while only 200 are worth. Consider buying this if the price is low or you just discovered you’ll spend the rest of the next ten years on a given technology AND you deem memorizing the whole standard library an useful experience.

Do not buy

• Books with “recipes” for solving specific problems. In real life you will have your own problems to solve. Even if they are problems solved by other people out there (I want to embed an image on a tooltip while hovering a list) you’ll find your own version of the problem has some important detail that will mess everything up (I want my tooltip to fade in, be always aligned on the left of the list and have a small arrow pointing to the list item). Besides, if you are not an UI developer these books are more and more useless. Make exceptions for DSLs like shading languages, regular expressions etc. as said above.
• Books excessively pragmatic. You want to learn the inside out of things and a “getting started in 24h for dummies” book is not worth the paper it’s written on.  You want to know that in curly brace languages a for(…) is equivalent to a while with some syntactical sugar and not just a way to count from 0 to 100.
• Books requiring to be read from start to end. You want to skim read it and then go back and forth as you wish.

Requirements

• As a must, you want the book to tackle the topics your brain isn’t able to tackle within 5 minutes of internet access. Unbelievably there are many books about C#, for example, which spend chapters and chapters about conditionals and loops and have a single chapter dedicated to iterators, anonymous delegates, lambdas and closures together; just to bring you to 4 chapters dedicated to LINQ. This is because they are “pragmatic” books. For pragmatic content, please insert an RJ-45 cable in your Ethernet socket and type www.google.com.
• It must have “gotchas” of the technology clearly highlighted so that you can catch them during your skim read. You are going to forget them in 5 minutes, but they really reside in some distant corner of your brain. When you’ll be stuck diagnosing strange behaviour in the system or debugging some code which just seem to be a compiler bug, you can remember it in a flash and solve the issue. I’m thinking about things like “this” in JavaScript closures, for example – either you read about it, or you are going to bang your head against the wall for a whole day (until some helpful colleague will enlighten you).

Photo: a book from Christopher Columbus travels, found in Porto Santo museums.