Pet Peeve: Typos in printed code examples

I swear, this has got to be one of my biggest fur-generating peeves… I just came across yet another typo in a Wrox book on PHP. I am astounded. I think that the plethora of ridiculous errors that exist in most technology books has held back the advance of modern technology by years. I remember a few years ago when I was first learning PHP and it seemed like every book I picked up presented the first example or two with code that didn’t work. I would just close the book and give up right there, because I figured it was either my server configuration being off, or else I was just too dense to get it. But no it was the friggin’ code that was wrong. Now that I understand this stuff much better by learning the hard way through trial and error, I can see the errors in the books right away. Newbies shouldn’t have to suffer through typos in code this much. It is really aggrivating, and they’re not going to go searching through errata to find out if and where any typos exist. No, more often than not they’re going to push the eject button.

Here’s a tip to those that write geek books: Write the code. Test it on your server. Copy and paste the working code into your draft. Have two technical reviewers read the draft and try each patch of code. Don’t commit mistakes to print.

So far, I’ve been fairly impressed with New Riders. The books I’ve picked up by them have for the most part been fairly clean. O’Reilly is fair, but really could be better considering the popularity of their books. The Wrox volumes have proven to be riddled with errors, as have most of the other publishers I’ve picked up. Won’t somebody please think of the children?

2 thoughts on “Pet Peeve: Typos in printed code examples”

  1. Hi there. I’m an editor with Wrox. I don’t work on the PHP books but if you let me know which book this was and pass along the error, I’ll be happy to pass it on to the editor.
    I do promise you that the editors and authors are making an effort to reduce the number of errors, code and otherwise. All the code really does get run at least a couple of times (usually more like 4-5 times) by at least a couple of different people. I think the 2 things that contribute to the majority of the remaining code errors I see now are:
    1. In languages that run on different platforms in different environments, minor differences between them that go undetected because the author or editor can’t test in every possible combination.
    2. The author gets a comment on draft 1 of the code and makes a minor change and forgets to retest that change.
    I’ve also seen changes after the code is checked from just an accidental unnoticed keystroke while editing another part of the chapter. And Word’s “autocorrect” and “autoformat” features which we beg people to turn off while writing and editing still mysteriously make some “corrections” for us resulting in errors.

    None of these are excuses. I hate code errors, they embarrass me.

    Kathy Sierra (an author for another publisher) recently gave us some great tips on improving our technical editing process that I hope we can experiment with here at Wrox.

  2. Hey Jim I sincerely appreciate the response and I’m glad to hear that you all are making an effort to improve this. I’ll be happy to send you the errors.

    To Wrox’s credit, I actually am getting a lot out of the current book I’m reading (Beginning PHP 5, 859 pagesok that’s a lot of typo checking…). The content itself is helpful, and I know what I’m doing enough that I can catch those items now and try to make my own solution. But a few years ago when I was new to it all, it was a real stumbling block. I have to teach this stuff now, and am reviewing books for assignment material, so I like to know what to expect before inflicting a book on my poor, unjaded, unsuspecting students. I know they’re already going to go through moments of frustration just trying to grasp certain things, so at least I can recommend the book and point out the errata ahead of time.

    Which brings up a good point. It is good practice, when picking up a tech book, to go straight for the online errata pages and just have a quick glance at what is there ahead of time. You can come back to it when necessary. Newbies who just pick up a book on whatever topic they’re confronted with aren’t going to often be privy to this practice, but certainly a quick trip to the corrections pages is beneficial to those that have had to digest this kind of material.

Comments are closed.