I’m currently reading two .NET books: Accelerated C# 2008 (Trey Nash) and Concurrent Programming on Windows (Joe Duffy). I will, in due course, post reviews here. However, the very act of thinking about the reviews has made me consider the inevitable inadequacies.

There tend to be two kinds of people reviewing technical books: those who’ve bought the book as a "regular punter" – who are aiming to learn something new. Then there are those who already know about the subject matter, but are reading the book mostly to review it. I realise there are people in-between (for whom the problems below aren’t such an issue) but these are the two camps this post addresses.

The purpose of a technical book is usually to impart information and wisdom. I would have left it at just information, but things like best practices don’t really count as "facts" as such – they are opinions and should be treated as such. So, there are two qualities that I look for in a book:

• Is it accurate? Are the facts correct, and is the wisdom genuinely wise?
• Is it a good teaching tool? How well is the information/wisdom transferred from author to reader?

I think it’s worth breaking these up, although there is significant overlap.

Accuracy

As I’ve noted before, I’m a stickler for accuracy. If I can spot a significant number of inaccuracies in the text, I find it hard to trust the rest. Now I generally don’t include grammatical errors, printing mistakes etc in this. While they make the book harder to read, they don’t typically leave me with a mistaken impression about the technology I’m trying to learn. There’s a blurring of the medium and the message when a book may be technically just about accurate, but still leaves an incorrect impression.

Now, the reader who has bought a book primarily to learn something new has little hope of judging accuracy. They can spot typos, and if the book is inconsistent or simply implausible that can become obvious – but subtle errors are likely to elude them. Just because an error is subtle doesn’t mean it’s unimportant, however. I know a reasonable amount about threading in .NET, but there’s a lot of Joe Duffy’s book which is new to me. He could have made dozens of mistakes in the text around Win32 threading, and I’d never know until it bit me. (For what it’s worth, I very much doubt that there are dozens of mistakes in the book.)

A reader who already knows the subject matter thoroughly is much more likely to spot the mistakes. However, they’re unlikely to be much good at judging the other major criterion…

Teaching efficacy

I can’t really remember much about how I learned to program, other than that it was over the course of several years. I started off with Basic on the ZX Spectrum, then moved on to C, then Java, then C#. Each experience built on the previous one. The way in which I learned C# wouldn’t have suited a non-Java programmer nearly as well as it suited me.

How can I possibly judge how well a book will teach a subject I already know? I can make some educated guesses about particularly confusing passages, and potentially critique the ordering of material (and indeed its inclusion/exclusion) but fundamentally it’s impossible to gauge it properly.

The people who don’t know the topic beforehand are likely to have a better idea, but it will still be flawed. In particular, you won’t know how well the material has sunk in until you’ve given yourself enough time to forget it. You won’t know how suitable the advice (wisdom) was until you’ve tried to follow it. You won’t know how complete the coverage is until you’ve used the technology in anger, preferably over the course of several projects. Even then it’s easy to miss stuff: if no-one on your team knew about iterator blocks and the C# book you were reading didn’t mention them, how would you know what you were missing?

Who should you trust?

This post has had a pretty depressing mood so far. That reflects my irritation with the whole topic – which isn’t to say I don’t enjoy reviewing books. I just have doubts as to their use. I do, however, have a few positive notes to end on, as well as some fairly self-evident advice:

• If everyone likes a book, it’s probably good. Likewise unanimous disapproval is rarely a good sign.
• When judging reviews, see if you can work out the context. Is the reviewer reading from a perspective of knowledge, or learning? If they’re criticising accuracy, they probably know what they’re talking about – but may not be a good judge of the style and teaching technique. If the review is mostly saying, "I learned C# from scratch in 20 minutes with the help of this fabulous book!" then you can guess that they at least believe they had a positive learning experience, but you should treat anything they say about accuracy and completeness with care.
• Blogs tend to have more "expert" reviewers than ecommerce sites – although often bloggers will be encouraged to post reviews to Amazon as well.
• Look for reviews which give specific praise/criticism. In particular if they give examples of teaching techniques, you will have more of an idea as to whether it’ll suit you. Reviews which basically say "I loved it!" or "That’s rubbish!" aren’t terribly informative.

On that note, I should probably stop. That’s another train journey gone that I should probably have spent actually reading… ah well. Please comment if you have other suggestions with regards to reviewing – particularly if it could help me to review books in a more useful way in the future.