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.
Jon Skeet's coding blog 
I have reservations about an author who reviews other books on the same subject. So does this mean your book doesn’t suffer from any of the negative points you mentioned?
Now I want to see reviews from these authors on your book. (Might never happen)
LikeLike
No, it certainly doesn’t mean that my book doesn’t suffer from the negative points! Obviously I’d like to *think* that my book is pretty accurate, and most of the errata I’ve collected so far (http://csharpindepth.com/Errata.aspx) have been non-technical, but I’d be very foolish to think that there aren’t more issues lurking.
Likewise it’s even harder for an author to know how effectively they’re teaching than it is for an “expert reader”. More opinions are always very welcome!
I’d love to see more authors review my book – Joe Albahari has already done so (https://codeblog.jonskeet.uk/2008/06/06/guest-post-joe-albahari-reviews-c-in-depth) and so has Patrick Smacchia (http://codebetter.com/blogs/patricksmacchia/archive/2008/05/25/book-review-c-in-depth.aspx) but I’d welcome more.
Some authors certainly don’t want to publish reviews on related books for fear of either displaying bias or being perceived to do so. I respect that opinion, but my personal view is that so long as the review declares the relevant interest to start with, it’s okay.
One advantage that an author of a related book has is that they’re very likely to be experts on the subject matter – chances are they’ve been poring over the language specification (or whatever) more than they would have done otherwise. That’s one area where I can add value to a review – I’m certainly a better judge of accuracy than I would have been a year or so ago. I hope that makes up for losing a certain amount of impartiality.
One interesting question is: would you like to see me review my own book? It would have to be brutally honest, of course, otherwise it would be pointless. I’m not yet sure whether I could actually bring enough objectivity to it to make it worthwhile, but if people are interested I might have a go.
LikeLike
Hi, Jon,
We would love to read your own opinions on your in-my-opinion very accurate and holding-those-greasy-c#nerds-hand-pretty-well book.
And as for reviews, the more, the merrier, especially with books about applying technologies. I would put most of software books I read into this category, the books that help people to digest a challenging technology or understanding a solution to a challenging problem. For these books, as you put it, accuracy and teaching styles rules. But both can be hard to define for these books, as they are not spec or scientific papers. The two actually intermingled. For some audience, it may be an engaging teaching and good enough accuracy, but for some other demographic, it can be too wordy yet too loose on accuracy. I guess at the end of the day, best way to judge is to have more reviews from all spectrum of the audience to get a good feel of it.
So everyone writes up and everyone benefits.
Ying
LikeLike
I’m looking forward to the Concurrent Programming on Windows review. I’ve read the book (rough cuts), and would like to hear your take on it.
LikeLike
@Ying: I’ll look at reviewing my own book when I’ve done the others – i.e. not for a while. I’ll need to actually reread it though…
@Kevin: The review of Joe’s book will probably be after I’ve got hold of the real thing in hard copy. I think I’ll find that much easier to read in full. At the moment I’ve only got a soft copy, which isn’t letting me read quite as comfortably.
LikeLike
I’d add one point to your list of things to watch for when reading reviews. And it’s particularly relevant to Amazon reviews:
Watch out for reviews from people who haven’t actually read the book.
This phenomenon occurs because Amazon appear to offer some sort of reward system for people who post reviews. This encourages people to post as many reviews as possible, which is of course a lot easier if you skip the whole ‘reading the book’ part of the review process.
For example, if you go to the US Amazon site and look at the reviews for .NET Windows Forms in a Nutshell (my first book), you’ll see a review from Phil Lee. If you’re familiar with both Windows Forms and ASP.NET and you read what he has to say, it will be apparent that he doesn’t realise these are two different technologies – he thinks that there’s just “DotNet Forms”.
So he dings us for spending only 6 pages on the data grid, while Dino Esposito spends almost half a book on the subject. Well yes, that’s because the DataGrid that shipped in v1 of Windows Forms was a tiny, and almost useless thing (so much so that Microsoft felt the need to replace it entirely in v2), and there really isn’t much more than 6 page’s worth of stuff to say about it. Dino’s book is about ASP.NET, which had a much more fully featured data grid right from v1.
It’s clear from his review that the guy thinks my book was about ASP.NET. And since the title alone indicates that this is not the case, it obviously doesn’t even have the first clue what Windows Forms is.
And I’m pretty sure my book wasn’t *so* bad that you could possibly read it without realising that it has nothing whatsoever to do with the web…
So it’s always worth checking how many reviews the reviewer has posted. This Phil Lee guy has written some 70 reviews, but I wouldn’t trust any of them. And while it’s plausible that he could have read that many books in the time he’s been reviewing (it’s only about 10 a year), he evidently did nothing more than read the ToC (and apparently not even the title…) of my book.
I also found the claim that the reference section “probably duplicates what’s available on a MSDN subscription CD somewhere” pretty offensive too. He doesn’t even pretend to have bothered reading that. I didn’t write that half, but I read all of it, and my co-author’s philosophy was specifically to provide hints and tips that are not in the MSDN library. The whole point of that section is it provides information you don’t get in the standard reference material – otherwise what would be the point?
Grr!
LikeLike
Jon,
I buy books, but don’t read them till the end :)
Could you advise me on how to read stuff & practice code examples (I know, I am acting like a baby).
I have found that it is better to buy books based on reviews by expert in the field. For r.g. I have seen several postings on csharp newsgroup & learnt a lot from it. So, it becomes my personal idea that book from you will have some solid content. Also, it is enforced by other good people in c# (Patrick, Ben as you said)
Blogs are more interactive, where author can correct mistakes, take feedback, improve stuff.
Books have been 1 way communication so far. I don’t know how many people go & look at Errata (Errata will be really helpful for technical inaccuracy)
On a side note, I am a developer for quite sometime & have ignored threading for long. I am kind of a newbie on that end. Could you suggest me a book to start with on that topic (c#/.net flavour would be helpful)?
BTW, I have bought your book & have yet to start reading it. What makes people like you read a lot of stuff?
You can write to me at my personal email address, when you post back (shahkalpesh at gmail d0tc0m).
Thanks :)
LikeLike
(cc’d by email)
What makes me read a lot of stuff? Well, at the moment reviewing other books – I don’t actually read many technical books usually (and sadly).
There’s also the fact that I spend about 3 hours travelling into and out of London every day. That makes it easier to find time to read :)
For threading, I’d recommend Joe Duffy’s upcoming book “Concurrent Programming on Windows”.
You might want a more gentle introduction as well though. I’ve got an article at http://pobox.com/~skeet/csharp/threads and Ben Albahari has one at http://www.albahari.com/threading/
Not sure about advising how to read stuff and practise code examples, other than just to do it. When it comes to trying something new though, I do find it useful to only try one thing at a time. For instance, experimenting with WCF, WPF and LINQ to SQL all at the same time wouldn’t be a good idea – if something didn’t work, you may not know where to look, or be able to easily tweak other aspects to make debugging easier. I personally like console apps for experimentation with anything other than GUI toolkits.
Hope some of this is useful…
LikeLike