This book is not terribly accurately named. I worked out that the Joel of the title was Joel Spolsky, but I failed to guess that the 'on Software' in question was 'on Software Project Management'. Still, if I'd looked a bit harder I might have worked this out, or indeed read a lot more of his website.
So, Joel's famous for his blog, where de discuesses software development, and his take on the process, and this book is basically a 'best of' of several years writing. Joel's fame seems to come from being actually fairly good as a programmers, and as a manager. When he manages, he thinks about what's being done, and what's good, and doesn't just blindly follow a methodolody. Much of his work is based around the idea of getting good people and making them think, rather than following a recipe. Another main idea is to just develop with good business sense - a lot of his work is focussed on shrinkwrap software and isn't applicable to developing in-house apps at large companies, and he admits as such. The critical approach, however, works everywhere.
Joel's opinionated and smug. This isn't a particularly bad thing. His opinions generally make sense, and even if you disagree with what he's saying you might have to think a little. He's smug because he's bright and experienced and his approach has been successful. However, there is a bit of a 'if you do it my way, it'll come out good'. Well, it's not quite that bad. He does give lots of concrete advice on things, but mostly in the sense of 'if you don't do this you'll come a cropper' rather than 'if you do this, it'll turn out ok'.
So his advice on project management his given me some new insights into the kinds of approaches that can be taken, but he's actually surprisingly weak on the technical side. It could be that he knows his stuff but dumbs it down for the web, or it could be that he's actually rather weaker at his technology than at his management. Either way, I don't like the fact that I can spot errors in the bits I know about, since I have no idea about the error rate in the fields I don't know about, and am trying to learn about from the book.
To give you a feel for the errors he's making, here's a few I spotted (by the way, the reason my complaints get more spread out as the book goes along is because the book gets less technical, and more managery, as you read it):
char* str="*Hello!"; str = strlen(str)-1;He says 'Notice in this case you've got a string that is null terminated (the compiler did that) as well as a Pascal string'. Very true. As you have in the first case. And it's less error-prone. Apart from the fact he's written a piece of code that overwrites an element of a string constant. Nice. And you can get the length at compile-time using sizeof to reduce the overhead. Oh, and who on earth uses octal? When complaining about subtle screw-ups, make sure you at least understand subtle screw-ups.