On Being A Technical Reviewer
While I don’t read as much fiction as I’d like, often favouring audio books from Amazon’s Audible while on the bus, I’m a bit of a sponge for non-fiction (number theory; the history of mathematics; quantum mechanics; web development; cloud computing and DevOps) and hoovering up everything interesting in my RSS reader. One day I’ll get around to writing my own book (perhaps on Amazon Web Services or something development/operations related), but until I manage to make more time and stop procrastinating, being a technical reviewer is a pretty good compromise.
In the last quarter of 2014 I was approached by a representative of Packt Publishing and asked if I’d like to be a technical reviewer for one of their latest titles; the second edition of
[Continuous Delivery and DevOps - A Quickstart Guide] (https://www.packtpub.com/application-development/continuous-delivery-and-devops-quickstart-guide-second-edition).
It was a great opportunity for a number of reasons, and I didn’t want to miss out. The subject matter is close to my heart: I’m a big proponent of the DevOps movement, and particularly the message that DevOps can convey to people within different areas of an organisation, with varying technical backgrounds. As I mentioned before, I’d also love to be in a position to write a book myself one day, and being able to contribute technically to something that has clearly been a labour of love for Paul Swartout was immensely rewarding.
Being a technical reviewer was quite liberating; I typically obsess over technical writing, carefully debating each sentence in the hope it’ll be pitched appropriately for the intended audience. Some might call this epic yak shaving. Worrying about the syntactic and grammatical flow of the narrative is something to be managed by the book’s editor and the author, often after the technical reviewers have shared their input. This meant I was free to gloss over typos, spelling mistakes etc. This is Paul’s book, and he ultimately wrote it the way he wanted to write it, which is after all his prerogative. I could concentrate on the technical content of the book, how accurate it was, whether it flowed in a logical and consistent manner.
Each chapter would be delivered with typically a two to three day turnaround time. It would be my job to objectively read what Paul had written, and add any comments or opinions regarding the technical accuracy of what had been written. I’d be asked to provide general feedback about each chapter, both in isolation, and in the wider context of the book as a whole. After reviewing each chapter, I’d answer questions as part of a survey: has anything important been left out of the chapter?; is the order of the material logical?; is there consistency from chapter to chapter?; have the key concepts of the chapter been explained clearly enough for the intended audience? etc.
After the book had been reviewed in its entirety, I was asked to submit my bio for inclusion in the front matter. It really was quite exciting when the publishers sent that section over for review and approval! The book has now been published, and I’m hoping to get my copy any day now! Being a technical reviewer may not be a paying gig, but it’s definitely worth doing - it’s rewarding, and I feel like it gave me the opportunity to contribute something back to the community that has been so giving over the years, helping me to get where I am today.
Thanks Paul for writing a great book, and thanks to everyone who reads it!