I always enjoy when I get a book recommendation by someone who knows what type of books I like. This happened a couple of months ago when my local librarian showed me a new book that the library just purchased. The book was not yet cataloged nor was itÂ ready to lend, but she said that if I stopped by later that afternoon she would have itÂ prepared for me.
TheÂ book was The Internet of Things by Donald Norris. Though I hadn’tÂ read much about IoT, nor anything by Donald Norris, I was still excited about getting the book. The subtitle of the book got me even more excited since I am a fan of the Raspberry Pi and becoming an Arduino aficionado:Â Do-It-Yourself at Home Projects for Arduino, Raspberry Pi and BeagleBone Black.
Knowing quite a bit of what would be in the front several pages of the book, I decided to skip aheadÂ and start reading at the first thing that might catch my eye. Unfortunately, the first thing that jumped out at me was a poorly formed portion of PHP code on page 25.
I tried running the code and was surprised to findÂ that it worked even though it wasn’t written correctly. Since PHP isn’t a language I know well, I decided to get some help in figuring this out. I sent off a message to my PHP friend and he confirmed that the codeÂ was not correct, but explained that the reason it still worked was because there was only one error of that type in the code. The serverÂ was smart enough to compensate for the mistake but would have failed had there been another one like that.
I then continued to scan through the book not thinking that one error was that big of a deal. But I noticed—just 4 pages later—the text gave 2 different names for the same table when talking about setting up a database for a project. That particular section of the book asked the reader to manually create database tables from the command line in MySQL. If that last sentence didn’t make sense to you then you probably understand that this was harder than normal people usuallyÂ deal with. Yet the book seemed to be written for normal people.
Because there were two different names for the same table, there was no way for the reader to accomplish the task of setting up a working database the way the text expected. This was on page 29 of a 352 page book. If the book had manyÂ more errors like this then itÂ would be unusable…
At this point I started looking for errors. Since it was a library book, I used sticky notes to mark my findings. From page 25 to 201 (a little more than half the book), I ended up with 46 sticky notes pointing out mistakes that I found. The vast majority of them were editing and formatting errors. Because it is a technical book, many of the errors were not the kind that could be easily caught by a proofreader, but there were a good handful of those too.
It seems like this book skipped a couple of steps before it got sent to the printing press.
Back to the Library
This book is published by TAB, an imprint of McGraw-Hill. A month or so previous to this incidentÂ I hadÂ pointed out a couple of minor mistakes in another McGraw-Hill/TAB book (Hacking Electronics) to my librarian. Though nothing was too egregious with Hacking Electronics, I told her when I returned the bookÂ that I had previouslyÂ noticed a few mistakes in other TAB books. When I brought The Internet of Things book to show her my findingsÂ I also grabbed Hacking Electronics from the shelf.
My librarian was eagerÂ to know what I thought about the new book. That is, until she saw that I was also carrying Hacking Electronics. She remembered my complaint about that book and knew immediately that the new book probably had mistakes in it too.
She began flipping through the book to look at my colorful sticky notes. On the first page of the first chapter she sawÂ a style error that I had not even seen. With anÂ average of one mistake every 3.8 pages that I found, it did not surprise me that she caught one immediately.
Contacting the Publisher
I contacted McGraw-Hill and asked if there were any corrections submitted for the book. I was put in touch with a senior editor for the division. HeÂ said that nothing had been submitted for the book. Unfortunately, McGraw-Hill does not have a system in place for the public to submit corrections like O’Reilly does.
I told the editor that I had found some mistakes in the material and said I was disappointed in the quality of the book. He was kind (or at least diplomatic), and asked me for some examples of the problems so that he could ask the author about them. My level of disappointment reached a new low at that comment. In my mind, not a single one of the errors I found were author errors.
The way traditional publishing companies work, at least as I understand them, is that the author submits the material andÂ an editor works with them to make the material better. The few frustrations that I had with the author were because of comments like, “I showed you the right way to do this inÂ chapter 2, but I already have this example written this way, so you modify my code to do it the right way that I showed you.” That came from page 150Â of the book. (Not a direct quote but the same sentiment). While I don’t like that the author said that, an editor is the one who should have slapped the author and said, “Don’t be lazy! Fix it yourself!”
It is an editor’s job to find problems like that and tell the author to do better. Therefore, I still don’t see that as anything that the author should have to fix. He doesn’t know the problem exists. He is too close to the work. An editor is the one who is supposed to catchÂ problems like that.
In response to the editor who said that he would take some examples and pass them along to the author, I told him I didn’t think that the problem were author problems. I was glad to provide some examples, but the examples were more formatting, editing and proofreading errors. I did not give him the example from page 59 where the author told the reader to write their code properly. I wanted to emphasize that, in my opinion, the problem was a McGraw-Hill / TAB problem, not an author problem.
Here are a few examples.
- flowing line instead of following line (page 125)
- missing space between sudo and the following word (pages 156 (twice), 166 (5 times), 170, etc.)
- preceding table instead of following table (page 173)
- missing colon (page 170)
- Rasbian instead of Raspbian (pages 155 and 163)
- MAC address not properly capitalized (page 182)
- EEPROM not properly capitalized (page 201)
Then there are the many places where formatting is not consistent in the book. The book uses mono spaced text for code examples, but several places there is normal text within the code that will break the code if put into a program. Those lines should be normal text or set off from the code as comments.
In the whole time I communicated with their editor, I felt like I had a listening ear. However, he kept insisting he would talk to the author about the things I found. Without trying to be too unkind I told the editor that I didn’t think the author was responsible for the majority of the errors, “unless McGraw-Hill/TAB is a self-publishing platform and the author is responsible for doing his own editing and layout work.” After that comment I didn’t hear from the editor for another month until after I sent 2 more emails asking if the line of communication was still open.
Though I only sent the editor about 1/3 of my findings, he didn’t seem to want any more. Of course, I also didn’t want to spend much time doing, for free, the work that McGraw-Hill is already paying their staff to do.
At this point I think I have reached the end of what I can do with my contact at McGraw-Hill. I really want them to continue to put out books on subjects likeÂ this. This is the kind of book that gets me excited to go to my library. But, if technical books, from a publishing house that is a major player in textbooks, have so many errors in them that the information is not usable, then I am not sure I want to read them.
I know it sounds like I am being nit-picky about the book, but I really never even fully read it and I found all these mistakes. I only skimmed through looking for things that caught my eye or sounded interesting to read. There were huge sections of code that I completely overlooked because they were in languages that I didn’t know. So unless I was actually trying to do the project, I didn’t need to try to understand how it worked.
The thingÂ that bothers me most about all of this is that my library has been given no assurance that they can confidently buy a McGraw-Hill / TAB book that will be better edited in the future (an assurance I asked the editor to give me on several occasions). I also don’t feel like I got anywhere with the publisher. As I said, the editor I talked to was kind, but his responses were very political. There was no commitment to assuring me that this was a one-time case.
My hope is that there will be an improvement in their process and that I can confidently enjoy books by publishers like McGraw-Hill. But when traditional publishers begin to act like the self-publishing companies they seem to detest, they lose their authoritative position in the market through laziness.