One of the most important roles in the writing of a technical book is the technical reviewer. It’s also a really hard role because of the balance you need to strike. The first book I wrote, many years ago, was a Linux security title, aptly named Hardening Linux.1 The publisher found a technical reviewer for the book, another author, and sent them the first chapter. Which incidentally was the first chapter I’d ever written. They shredded it. They picked on my style, my content, nitpicked every grammatical error and basically crucified me. At the end of reading their comments I was basically ready to give up.2 I told the editor I was going to throw the towel in. He explained that the tech reviewer had massively over-stepped their bounds and described what a good tech reviewer should provide:
- Validate the technical content is correct and up-to-date.
- Validate that any code or examples or instructions work
- Make sure the technical coverage makes sense. Have you covered the technology well? Are there edge cases or things you should add? Is there some feature you should cover or cover in more detail?
So what shouldn’t they do?
- Their job is not to editorialize on your style, grammar or voice.
- They shouldn’t spend hours fixing grammatical errors or spelling mistakes.3
- They shouldn’t critique the structure or narrative of your book. That’s a role for your editor.
So if you get asked or want to be a tech reviewer please consider these as some simple rules to help make the experience awesome for you and the author.