Interview with Paul Hallett, technical editor of Raspberry Pi For Dummies
Paul Hallett was the technical editor of Raspberry Pi For Dummies. In this interview, he reveals what the role involved, and the best things about it.
Paul, tell us about your experience with the Raspberry Pi
I was one of the first people to get a Raspberry Pi - I remember spending all day trying to order one whilst the websites kept crashing due to the huge amount of interest in the little device. I am completing a degree in Computer Science, so I wanted one to tinker with and run a few little projects on. I ended up coming up with the idea to help teach programming on the device by building and running a website on one. My project became the first ever successfully crowd-funded Raspberry Pi project. Right now I'm building another Raspberry Pi application for my university dissertation, I am teaching in schools around the South West of England and attending Raspberry Pi conferences.
How did you get involved with Raspberry Pi For Dummies as technical reviewer?
I was contacted by Craig Smith from Wiley who initially wanted me to author a book about programming Python on the Raspberry Pi but I had to turn it down due to time constraints (I am completing a degree after all!). So instead he contacted me asking if I'd like to help be a technical reviewer on Raspberry Pi for Dummies. I immediately said yes!
What did the role involve?
On the surface - technical reviewing seems like you're just reading through the book checking for errors, but there is much more involved.
I personally write and run all the programming code that is written in a technical book to make sure it works. I also offer code optimizations where possible. Python especially likes code to be 'pythonic', something a few people often forget.
You have to have a keen eye to spot small technical errors (I remember reading through the first draft of Raspberry Pi for Dummies and it suggesting a mini USB for the power supply, when actually a micro USB is needed). Small things like that can go amiss quite easily when you're reviewing hundreds of pages and they can cause problems.
You also have to be confident enough to correct the author on technical issues - after all you are considered the technical 'expert', so if it seems wrong don't be afraid to research it and change it.
What were the best things about being a technical reviewer?
For someone my age with my experience, the best thing so far has been saying 'I helped to write that book!' to my peers. I also enjoy the hunt for errors, finding things that aren't quite right or re-writing code so that it looks better for the reader.
What advice would you give to others taking on their first project as technical reviewer?
Make sure you know the field - a bad technical editor is one who has no idea what they're reviewing. That said, be prepared to spend some time learning whilst technical reviewing - you want to make sure what you're saying is correct!
What did you learn about book publishing from the process?
The entire process was completely new to me, so I learned a lot! I learned that we use Dropbox a lot and things are pretty messy but still well organised. I always imagined we'd use special software - I was completely surprised when I was given a bunch of word documents to edit!