I was involved in production as a technical reviewer. I can now say what I think about the book in as honest a way as possible. This information might be useful for people tempted to become technical reviewers for other books.

It also helps that the final cheque is winging its way to the bank as I write.

Technical reviewer

So what’s technical reviewing all about? Technical publishers employ a few technically minded editors, but these editors cannot possibly be experts in every field. So the publishers employ experts to fact-check the books during production.

The technical reviewer’s responsibilities include the basic fact-checking (like does the code run and is what he’s saying true?), but they also point out parts of the text which are unclear, and concepts which need to be covered but aren’t. It’s important to note that the job is to bring the author’s and editors’ attention to these unclear and missing sections, not to actually write them.

A technical reviewer for Apress gets to write what are described as “candid midterm assessments” about the book’s marketability.

In case you’re thinking this sounds like fun, well I guess it can be if you were the expert in charge of a classic like Programming Perl. More realistically though you’ll be ploughing through first, second and third drafts of a book you have no creative control over, pulling out the code snippets and running them, recreating the author’s development environment, fact checking every sentence, and trying to follow the reasoning from the point of view of a language beginner.

Doing the maths

For this job you will be paid $3 per page. That is, as it turns out, $3 per page published, not $3 for every draft of every page you review.

To save you rushing off to Amazon to find out what I got, I’ll tell you that the final money earned was just over $1,300. After taking into account the ruinous $-£ exchange rate and UK bank charges I’ll probably end up with £650, and after tax that will translate into about £450 spending money.

How long did it all take? In the end I reviewed 53 chapters (that is to say I reviewed some chapters more than once – there aren’t 53 chapters in the book). It takes as a rule of thumb about one hour to review each chapter, some take longer, some are quicker. Let’s say I did somewhere around 50 hours of work.

This works out at around £13/hour before tax.

That’s a snip over the average hourly wage for a UK worker (£12.50/hour according to the GMB union). It’s quite a lot less than Merjis charges out.

Early signs are discouraging

Books, though, are about love, not money. Did I love this book? Not much.

It was evident quite early that the author did not have a very natural writing style and was having trouble explaining himself on a level which would work in front of a classroom of, say, students or professional programmers.

I sent a first draft to my colleague for his assessment. He used to be a university lecturer, so he knows a thing or two about teaching new concepts to students. This was a fragment of what he wrote back:

Marred by repetitious sentence structure, poor examples and leaps in logic and category. Not the worst I’ve seen, but makes a confusing topic even more confusing. [...]
I think the judgement should be that [the author is] prevented from publication until they read The Elements of Style, some [university] teaching material, and have actually tried to teach from the material.

(My emphasis). Teaching from the material is important as I found out recently when I taught a student some basic OCaml. Students find some unexpected things hard, and other things you thought would be difficult to pick up prove easy. My student had no problem whatsoever understanding the difference between [1; 2] and [1, 2] which are both valid OCaml expressions with quite different meanings. At that point half an hour or so of my teaching materials suddenly became irrelevant.

The other problem was that I am seemingly by nature very fussy when it comes to correct layout of code and code that actually works. A lot of this code was laid out very poorly, not indented correctly, and in some cases unfortunately did not work. I had the thankless task of trying to format the code to be reasonable, then track down and comment on the problems.

This was not helped by having to do all this in Microsoft Word XP, a tool that is manifestly unsuitable for this type of collaborative, precise technical work.

The candid midterm assessment

I only wrote one candid assessment, and decency and privacy prevent me from disclosing what was in it. I will just say that it was not positive.

Apress wanted to go ahead and publish. They said they would “try to make sure that the awkwardness is taken care with a heavy copy edit/dev edit”. I haven’t received a final copy of the book yet, so I cannot say whether this heavy editing was done and if it corrected the problems.

Final lessons

I suspect that I won’t be asked to do any more technical reviews for Apress books after they read this. Obviously this was a bad experience, and I’m sure some technical reviewers have a lot of fun in their work. If you are asked to do a technical review, make sure you understand that it is not an easy way to make money, and if you have doubts about the book, raise them as early as possible (I waited for much too long).

I ought to have insisted that my name didn’t appear on the book — that was a mistake.

Finally, should you buy the book? I will leave you to make up your own mind on this. Read a variety of reviews. There are several free OCaml tutorials around which you might like to look at first.