Slashdot Mirror
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?"
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.
"Can of worms? The can is open... the worms are everywhere."
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...
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.
More often than not, it is the editors who are at blame rather than the authors. First off, my bride was a technical writer. I'm still not quite sure what that means, but as an English / Math double major without any coding experience, some of the results were quite comical. A while back she was fixing the Engrish descriptions, code fragments, sql scripts, and a mix of other stuff. She went back to the developer because they possibly misspelled pseudo as sudo. She had the sense to not 'spell check' the scripts, but another friend who wrote a Perl book said his editors were not quite as thoughtful.
+++ UGUCAUCGUAUUUCU
I have two kinds of programming books on my shelves. One kind is an introductory book, the other is a reference. My reference books I use all the time. But the introductory books are darn near disposable. After reading them, they become paperweights. Don't get me wrong, they are a necessary part of learning, but after I've learned what they have to give, it's a rare case that I might pick them up again.
The reference books I have are always a source of new information. These always seem to be much more accurate than the introductory books in the code examples that are given.
The point I'm trying to make is not that the student has done something wrong, but that the student should not trust the author of an introductory book. Interpreting the information with a sceptical eye means that the student, rather than being frustrated by mistakes, can look at the mistakes in code as a challenge.
It may make someone feel good to have made something that works, but in the end, feel-good programs don't really teach you that much. It's the concepts behind the program that are important.
I agree that experimenting really does a good job of teaching, but experimentation is going above and beyond what the book has to offer.
Notes From Under *nix: blas.phemo.us