Calling Trey Nash…

Okay, this is a slightly odd post, but with any luck it’ll prove successful. As I’ve mentioned before, I’m currently reading through Trey Nash’s “Accelerated C# 2008″. I’m writing down errata as I go, but so far the only place I’ve found to leave them is on the Apress web site – which may well be a black hole as far as I know.

So, if anyone knows how to get in touch with Mr Nash, could they either let me know or give him my email address (skeet@pobox.com) and ask him to mail me? The normal means of finding him (blogs, forums, personal web sites etc) are failing me at the moment… I’ve left a comment on his blog, but as it’s rarely updated I don’t know whether he’s actively watching it.

Update: Trey has now mailed me, so all is well.

Judging a book by its cover (or title)

I’ve ranted about versioning before (and indeed in C# in Depth). I still believe that Microsoft didn’t do the world any favours when they introduced a relatively minor set of changes (just libraries, albeit important ones) with .NET 3.0 and a more major set of changes (languages, LINQ, core library improvements) with .NET 3.5. Using 2.5 and 3.0 would have made more sense, IMO. But never mind.

The fact is, people are confused about what version number applies to what. A number of people claim to be using C# 3.5 when they mean either C# 3.0 or .NET 3.5. (For a quick reference of what’s actually what, see my article on the issue.)

Okay, so far it’s the fault of Microsoft for being confusing and the fault of developers for not keeping up. Both of these are far more forgiveable in my view than being flat out wrong as many books are at the moment. I don’t believe this is any indication on the quality of the book itself (Accelerated C# 2008 is pretty good so far, for example) but I still think it’s pretty awful to make a title so confusing. So, here are some bad titles and others which use version numbers appropriately. (I’ve left out titles like Head First C# and C# in Depth which don’t specify version numbers.)

Bad

  • Professional C# 2008 (Wrox)
  • Pro C# 2008 and the .NET 3.5 Platform (Apress) (only partly incorrect, of course)
  • Murach’s C# 2008 (Mike Murach and Associates)
  • Accelerated C# 2008 (Apress)
  • Illustrated C# 2008 (Apress)
  • Pro LINQ: Language Integrated Query in C# 2008 (APress)
  • Pro ASP.NET 3.5 in C# 2008 (Apress) (again, only partially incorrect)
  • Beginning C# 2008 (Apress)
  • Beginning C# 2008 Databases (Apress)

Good

  • C# 3.0 in a Nutshell (O’Reilly)
  • Programming C# 3.0 (O’Reilly)
  • C# 3.0 Cookbook (O’Reilly)
  • C# 3.0 Design Patterns (O’Reilly)
  • C# 3.0 Pocket Reference (O’Reilly)
  • Pro C# with .NET 3.0 (Apress)
  • Beginning C# 3.0 (Wrox)
  • C# 3.0 Unleashed: With the .NET Framework 3.5 (Sams)

Okay

This is the “well, just about” list – because they’re referring to “Microsoft Visual C# 2008″ instead of C# 2008, it’s referring to the IDE instead of the language. I think it’s better to name a book after the language instead of the tool you use to write in the language, personally…

  • Beginning Microsoft Visual C# 2008 (Wrox)
  • Microsoft Visual C# 2008 Step By Step (Microsoft)
  • Programming Microsoft Visual C# 2008 (Microsoft)
  • Microsoft Visual C# 2008 Express Edition: Build a Program Now! (Microsoft)

Notice a pattern? If anyone at Apress is reading this (unlikely, I know) – there’s no such thing as C# 2008“.

Rant over for the moment. With any luck I might be able to finish reading Accelerated C# 2008 fairly soon, and give a proper book review.

Google release protocol buffers as an open source project

Yesterday the Google open source blog announced a new open source project, to release one of the core pieces of Google infrastructure: protocol buffers. Basically protocol buffers are a way of encoding structured data in a language-neutral and versioning-friendly fashion. Yes, there are a lot of similar ways of doing similar things, but this happens to be the one we use.

Currently the protocol buffer compiler (which takes .proto files and converts them into source for various languages) supports C++, Java and Python. I’m hoping to add C# to that list reasonably quickly. To start with this will just be in my spare time rather than as a 20% project, but who knows…

It’s really nice to work in an environment where the question of “is there any reason we can’t open source this?” crops up quite frequently. I’m looking forward to the day when a piece of code I’ve developed at Google ends up as part of an open source project.

The trouble with book reviews

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.