I might have a different version of the book then. I recall no issues with the code that were not listed in Errata- But I have more development books than I care to admit-- so I might be mistaken or mis-remembering.

Having been a technical reviewer for Peer, I know what the process was. The compensation for the reviewers was not very good- as a result they were not inspired to do the work they really needed to.

We were paid per page of text we reviewed. That was no matter how long that page took to review or correct. As a result many of the reviewers "phoned it in" (in my opinion) because taking the time required to really review the book properly took more time than they were paying for.

Wiley, I understand, has in=house reviewers. This is probably a better way to do it from the standpoint of time being dedicated. Of course, that means the reviewer isn't out in the trenches and may not know some of the "gotchas" that we do out here in the field.

Optimally I'd say that the best reviewing team would be made up of both professional reviewers as well as a rotating group of people doing the work every day- and they should be paid a rate that makes it worth the time to do the quality review.

There was one book I was working on that I felt was so bad I stopped working on it after 2 chapters. It took me way too long to review for the pay.



Hal Levy
Web Developer, PDI Inc.

NOT a Wiley/Wrox Employee