TippingPoint Digital Vaccine Laboratories
DID YOU KNOW... Most phishing sites are hosted on compromised Apache + PHP + MySQL servers located in the US. Our Digital Vaccine service includes filters specifically designed to prevent potential victims from reaching many of these malicious sites.

Authoring a Technical Book

In July of 2007 two former colleagues and myself had our book "Fuzzing: Brute Force Vulnerability Discovery" published through Addison-Wesley. The book is under 600 pages and took well over a year to complete, during which the bulk of my free time and weekends were dedicated to completing the project. I learned a lot throughout the ordeal, especially with regards to the process of publishing. From conception to final press, here are some basic notes that should help reduce frustrations for anyone looking to author a technical book.

Consider not doing it.

I've always wanted to walk into a book store and see a self-authored book. In the same sense that some strive to complete a marathon in their life, I've always considered authorship one of my life goals. Unfortunately, I vastly underestimated the amount and work it would take to do so. Technical books, on average, take a year to write. During that time you and your co-authors are essentially rearing a child together. I can say with very high confidence that I will likely never write another book, simply because of this time drain.

If you're considering writing a technical book for the money, forget about it. Unless you are the sole author and are writing to a large high level audience, you'll make more in far less time babysitting for your neighbors kids.

The publisher is more flexible than you think.

Depending on your publisher there may be a variety of rules you are supposed to follow. What word processor to use, special formatting tags, what file format your screen shots have to be in, etc... We easily spent 10 to 15 percent of our time formatting and reformatting for the publisher. If I had to do the process again, I'd forget all rules and regulations and focus on writing. At the end of the day, the author is responsible for the content and the publisher for everything else. Give the publisher a complete work organized in some simple logical fashion and let them do the rest. Period.

Agree on stock language with your co-authors up front.

Basic terminology, definitions, we versus I, he versus she, etc... You'll save a lot of time and frustration if you and your co-authors decide what to homogeneously use up front. Researchers tend to use different voices and different terms which can cause great confusion for the reader.


Meet with your co-authors as often as possible.

Hands down the most work we got done is when the three of us were sitting in a coffee shop together. If you can't meet physically, at least have regular phone meetings to ensure that milestones are being met. To ensure a single voice and instill pressure on meeting deadlines all three of us would complete chapters on set dates and review one anothers work prior to moving on to the next set of chapters.

Find your own technical editors.

Though you may get lucky, chances are the technical editors your publisher is going to find are not going to be as good as those you can cherry pick yourself. Pick your technical editors early and give them open access to your manuscript throughout the process. Treat your technical editors with great respect as they are an invaluable resource especially in adding interesting anecdotal notes and letting you know what areas need further explanation.

Lock in your forward and book quote contacts early.

Because all the cool people are busy!

Flip flop between writing and coding.

Most technical books contain a mix of words and code, be it custom or annotations on someone elses work. Between the two, I imagine writing will be considered the more boring option. Though it is tempting to do all your coding and technical research up front, I think it's a mistake to do so. The way I approached it is to write as much as I could bear then switch to coding when I got burned out. It's also nice when you're stuck in a frustrating debugging session to switch to writing.

Research your publisher.

Ask your published friends for their honest opinion on their author-publisher relationship. I was overall happy with Addison-Wesley and impressed with the amount of marketing effort they put into our book. I've heard good things and enjoyed many books published by both Wiley, McGraw-Hill and No Starch. One publisher I constantly hear negative things about is Syngress, which isn't shocking considering the quality of most of their books.

If anyone cares to share their authoring tips or experiences with publishers, please feel free to comment.

Tags:
Published On: 2009-06-03 16:20:57

Comments post a comment

  1. Chris commented on 2009-06-04 @ 06:39

    Good info. Thank you.

  2. A commented on 2009-06-05 @ 17:20

    I wrote a couple of bookx and currently working on a new one (and I work full time as well, includng OTs as well); as much as I love to write, and the process of research associated with writing (basically, you realize that you knew nothing about the topic you want to write :), I do agree that writing is one of the hardest projects I have ever worked on;

    I fully agree on Syngress quality (lack of) and share the good words about other publishers...

    good that you tried; you will be temptied to come back... I told myself a few times I will never write again, but I still do...


Links To This Post

  1. Security Briefing - June 4th : Liquidmatrix Security Digest
    linked on 2009-06-04 @ 08:20 Show Comment

    Authoring a Technical Book - DV Labs

  2. Andrew Hay » Blog Archive » links for 2009-06-04
    linked on 2009-06-04 @ 16:08 Show Comment

    TippingPoint DVLabs Authoring a Technical Book A lot of sound advice in this article. One thing I often tell people is if they're not ready to commit all of their free time for 3+ months…writing a book isn't for them. (tags: book writing)


Trackback