Errata in Programming Books?

WgT2 asks: "I recently have set my mind to learning to code PHP. Not being a programmer, yet, I went out and got myself a book on the subject from a very trusted, at least in my eyes, publisher (and they still still are). So far so good. However once I got down to trying the code out myself I have found too much errata for someone who has just scratched the surface in learning the ins and outs of programming. I was wondering just how common place Slashdot readers have found errata in the code examples of programming books they have purchased?"

Comments

Frequently...

[stefanlasiewski]

Tough subjects, tight deadlines, and the profit-first additude lead to bad books.

I recently purchased Learning Java from Oreilly. Usually I've had a good experience with Oreilly books, but this one was horrible. Several of the examples in the first chapter of the book didn't work because they had typos!

Few things are more frustrating then debugging a "Hello World" program that doesn't work. I went over every character, bit by bit, and my program matched their text exactly. I couldn't find the damn bug. Was I so stupid that I couldn't see the obvious? No! I viewed the Online Errata, and found that a zillion other people were having similar problems with examples throughout the book! Typos galore!

If there are too many mistakes in the book, then let the publisher note. Return the book, get your money back, send a note to the publishers, and buy an alternative book.

obligatory

[Satai]

Someone has to make a Knuth joke. I tried, couldn't come up with anything. Come on people!

Here's his errata.

My favorite is the Random Number error. It took a while, but someone discovered that apparantly one of the portable random number generators behaves poorly during the first 2000 or so of each seed number. So, naturally, Dr. Knuth corrected it almost immediately.

Never have I seen a man so humble that so amply deserved to be arrogant...

Thoughts from an O'Reilly Author

[Anonymous Coward]

The book I wrote had quite a bit of errata with some simple topics, and not much on the hard topics. I simply didn't spend enough time on the first half of the book, and I regret it.

What really killed my time was adding more content to the book than initially planned. I should have left it all out, but at the time I thought I had the rest of the book nailed down. I should have spent more time reviewing, and getting more feedback from the reviewers.

If any of you write a book, be sure to stick to the initial plan, and do no more. You might even want to cut out some of the content... don't just write to add more pages to the book. That is one thing I hate about Wrox books, imho, and I did a little bit of that myself :-(

Of course, there are always second printings, and second editions to incorporate the fixes, but that doesn't fix the disappointment of finding the errors in your own book the first time around.

Look to the publisher's site

[babbage]

Most (all?) of the publishers today will have a web site dedicated to each title, and the better ones (all again?) will have an errata page somewhere in there. Look for it. Consider basing purchasing decisions on the presence & quality of that errata page:

• If it has such a page, and it's short (all books will have at least some typos -- that's life), then you're in good shape.
• If it looks like the errata page is updated often, that's also a good sign -- it means the publisher is paying attention. That may be even better.
• If it has an errata page, and it's really long, then maybe the book is just sub-par: be careful here.
• If it has no errata page, the publisher is lying, or hasn't gotten around to it yet: be careful here, too.

I don't know which book you got, but O'Reilly's Programming PHP has its own confirmed and unconfirmed errata pages. If this is the book you've got, feel free to go over the corrections noted on these pages and jot them down in your copy -- I've done that with a couple of my books, and would have missed many of the glitches without that hint. If you see an error that isn't on this page, O'Reilly offers a error submission form that you can use for that book (and others of course) -- so use it! If the publisher doesn't find out about these mistakes, they aren't going to get fixed. A good publisher will offer revised printings -- not that that helps you once you've got a copy, but it will prevent other learners from having to hit the same obstacles you did. :-)

You can't, unfortunately, expect books to be perfect & pristine. (Well, maybe Knuth's books, but everyone else has to deal with typos & thinkos :-). You can, however, and should expect the publisher to own up to their little mistakes and offer you corrections on their site. Go find that info and get the fixes into your copy and you'll be a happier camper.

Errata Schmerrata

[tres]

Errors in examples give you the responsibility of thinking about the code. You've got to understand what it is doing, rather than just mimicking the examples.

Believe me, I've spent my fair share of time and frustration trying to debug bad examples. It took a long time to learn, but when I don't trust the author, I find that the errors are more challenging than frustrating.

A couple of O'reilly books in particular, Steve Oualline's Practical C Programming and his Practical C++ Programming purposely have errors in the examples for just this reason.
The difference is, Steve tells you that the errors are there. It's a good learning technique, and forces you to pay attention to the concepts rather than the examples.