How to Become a Book Technical Reviewer

How to Become a Book Technical Reviewer

Just got in my hands a very special book. Special because it is the very first book I was involved as a Technical Reviewer. About six months ago, during my first involvement with this project, I tried searching for information about the role and responsibilities of a Technical Reviewer. Unfortunately, my research was not successful since the available information online is limited and I didn’t have someone in my circle to guide me.

So this is why, I’m writing everything I wish I had known before starting on this journey.

Understanding the Role

The duty of the Technical Reviewer is to ensure the technical accuracy of the content, identify its strengths and areas for improvement, and offer suggestions. In essence, the role is that of an expert providing insightful feedback on the content. It’s up to you to ensure that the content is technically accurate and up to date and that the code snippets make sense, enhance the reading experience, and actually work as expected.

You also serve as a proxy-reader, representing the perspective of the intended audience. Your expertise and feedback play a vital role in shaping the final form of the book.

The Review Process

The process is quite simple and straightforward. Once the author has written a chapter, the Project Manager shares the chapter with you. You would have a couple of days (usually 3 days per chapter) to share your feedback on the chapter, which would then be shared with the author. It is basically an on-going review process during the development of the book.

The chapter drafts were shared in the form of a Word doc, where you can mark comments on the chapters. A Questionnaire would also be shared with you where you can mention your overall feedback for each chapter.

Providing Constructive Feedback

As an expert, constructive and quality feedback is expected for every chapter. Here are some tips to make the process easier for you

1. Be specific and clear: When offering feedback, be specific about what worked well and what could be improved. Use simple and clear language to express your suggestions, making it easier for the author to implement changes.
2. Offer actionable suggestions: Instead of just pointing out flaws, provide actionable suggestions for improvement. Offer alternative approaches, examples, or additional resources that can enhance the chapter’s content or make it more engaging for readers.
3. Maintain a constructive and supportive tone: Remember to deliver feedback in a constructive and supportive manner. Focus on helping the author improve rather than criticizing their work. By providing encouragement alongside constructive suggestions, you can create a positive working relationship.
4. Review the code and verify that it functions as expected, paying attention to details, such as accuracy, efficiency, and following coding standards. A bug on production can be reverted, a printed bug will be there forever!

Some examples from my reviews are the following. The suggestion mode of Word documents can help to keep track of the changes and add comments when needed.

Of course, adding a link to the documentation to back up your claim is always a good idea.

In total, I was usually writing 2 to 10 comments per page. In some theoretical chapters, I had little to contribute but for some heavy code ones, a more throughout review was needed and the three days were not enough.

Chapter questionnaire

In addition to reviewing each chapter, you will be required to complete a questionnaire consisting of the following 10 questions:

1. What were the highlights of this chapter? Will it give the reader practical skills?
2. Will the reader find it easy to follow the chapter?
3. What would you like to see less of in the chapter?
4. What could the author do to make the chapter more interesting?
5. What important topics does the author leave uncovered, if any? Does the chapter leave you asking nagging questions?
6. Does the reader learn to do enough in the chapter? What else should the chapter teach readers to do?
7. Where do you think readers will struggle in this chapter? What can the author do to address this issue?
8. Does the author explain the main important concepts clearly? Are there other important concepts and facts about the topic that should be covered in the chapter?
9. Are all of the code and the instructions given in the chapter accurate and functional? If not, please provide the solution in your feedback.
10. Give an overall rating to the chapter out of 10.

This questionnaire provides an opportunity to provide additional feedback, ensuring that the strengths are acknowledged and the weaknesses are appropriately addressed.

Compensation 💵

Apparently, you can make good money as a book technical reviewer. But this was not the case for me. I was not motivated by money and that’s why I did this almost for free. That being said I did get invaluable insights into the book development process that I hope I can use someday to become a book author myself. The process was hard but I still want to go through with it.

To be fair I did get some actual rewards at the end of the process.

• An eBook and a print copy of the book
• 12 Months packt subscription ($129.99)
• My name and a short biography were added to the credits page of the book and all relevant published materials

Conclusion

Becoming a Book Technical Reviewer is a great opportunity to gain valuable insights into the book authoring process. Your role is to ensure technical accuracy, identify strengths and areas for improvement, and offer actionable suggestions that will shape the final version of the book. Although the review process requires time and commitment, it is a unique experience that I highly recommend.

If you are into Vue.js the book is called Vue.js 3 Design Patterns and Best Practices. Let me know in the comments if you liked it.