Publishing a Technical Book (Part 3): The Writing Process

An inside look into how to find the time to write a book and what it’s like to work with a co-author and publisher.
Career
Publishing
Author

Emily Robinson

Published

April 5, 2021

[This is my third post on publishing a technical book. Check out the previous posts on why you should (and shouldn’t) write a book and how to find a publisher.]

Finding the time

Overall I’d estimate writing the book, including the proposal process, took us each around 400 hours over a year and a half. This doesn’t count the work promoting the book after it was out, which I’ll talk about in part 4. Jacqueline and I split the 16 chapters equally between us. Generally we would take 3-4 weeks to write the first draft of our chapter, 2 weeks to review the other person’s chapter, and 2 weeks to incorporate their edits and suggestions into a final draft, which meant we were finishing about a chapter a month. We’d send our chapters to Manning as they were finished to be reviewed by our editor, and then Manning would send out 5 chapter chunks to external reviewers, which usually took about a month. In a very meta blog post, Jacqueline actually analyzed our GitHub commit history, so you can see the entire timeline of our book writing there.

Some people find it very important to write some every day, possibly at a specific time. We definitely did not do that. That might be more important if you’re trying to write in a short period of time - for example, Susan Fowler wrote her first technical book in three months by writing at least a thousand words every day.

Writing a book is a big time commitment. We both had full-time jobs completely separate from the book and in Jacqueline’s case she was also raising a toddler. If you are in a relationship, I think it’s really important to have a supportive partner. If you have children, maybe they agree to be “solo parent” for two nights each week so you can go to a coffee shop to write. Even if you don’t have children, you’ll need to spend a lot of time on the book, which means less time for spending with them either alone or with friends.

If your struggle is not so much with having time available as motivating yourself to use it to write, I highly recommend adopting the “shitty first draft” method advocated by Anne Lammot in Bird by Bird (an excellent book on writing). “Shitty first drafts” means that you should just focus on getting words on the page and not worry about having it be perfect. In my case, I often started by writing my thoughts in bullet points and then converting it to paragraphs. A few times when I was really struggling I even gave those bullet points to my husband (who is not a data scientist or even in tech) and asked him to write a first draft, since I found editing easier than writing.

Having the outline we wrote for our book proposal also really helped, since it broke the chapters down into chunks. Instead of starting from “I need to write some career advice,” I would start from “I need to write about tailoring your resume.” One of our core needs as humans is having a sense of progress, and by thinking in subsections I was able to get that progress vs. if I was thinking about getting an entire 350-page book written.

[Serial procrastinators, skip this next section!]

While you will have a timeline established with your publisher when you begin writing your book, it’s pretty common for those to get extended, even though there might be language in the contract like “if the draft is delayed by more than 60 days we reserve the right to bring on another author.” Knowing that, I didn’t find those especially motivating. As long as you’re being responsive and getting some progress done, your publisher is unlikely to drop you. They are often particularly understanding if there’s a life event slowing you down. The exception here might be if the technology you’re writing about will soon become outdated (e.g. if you were writing a book 2 years ago about Python 2) or a competing book will be released soon.

[Procrastinators can come back now]

Working with a co-author

In the “about the author” section, I wrote about Jacqueline:

“Whenever someone asks me whether I would recommend writing a book, I always say, ‘Only if you do it with a co-author.’ But that’s not actually the full picture. It should be, ‘Only if you do it with a co-author who is as fun, warm, generous, smart, experienced, and caring as Jacqueline.’”

Having a co-author was extremely helpful for me. Jacqueline had experience that I didn’t have, including being a hiring manager, a principal data scientist, and a director, along with working at many different types of companies as a consultant. It also helped that I can be very motivated by guilt, so when I saw Jacqueline writing or sending me a chapter, it prompted me to get mine done so I wouldn’t slow us down. Finally, her feedback on my chapters was immensely valuable, especially because we have somewhat different writing styles. Mine is more to the point, trying to convey as much information as possible, while Jacqueline’s includes more stories and color. Together, I think we found a really good balance in the book.

All that said, I could imagine working with a bad co-author would be a nightmare. Fortunately, writing the book proposal and reading anything they’ve written before should help you learn whether you like their writing style and if they’re good to work with.

Writing tools

We just used Microsoft Word with GitHub for version control and collaboration, but that’s because we had almost no code and we already owned the software. Manning also offers templates TextMaker (part of SoftMaker offer, which is less expensive than Word), Google Docs, and AsciiDoc. If you’re writing an R book you can use Bookdown, and books written in bookdown have been published by O’Reilly and CRC Press, but according to the package author it will be tough going if your publisher doesn’t support LaTeX.

[Added 4/6] Catherine Nelson shared that for the book she wrote for O’Reilly, she used O’Reilly’s flavor of Markdown using her favorite code editor and managed it using Git.

Working with the publisher

It’s really important to remember that the publisher wants your book to succeed. You should be open to their criticism and feedback, even if it might send you into an “I’m not good enough” spiral. Remember that they already decided you were good enough when they signed you.

Our editor didn’t usually have a lot of feedback - I’m not sure if that’s standard or we’re just amazing writers. She did help us synthesize feedback from the draft reviewers, which was good as some reviews contradicted each other and some she said Manning just straight up disagreed with.

One area that their experience showed was when Manning encouraged us to write an appendix with interview questions, which we hadn’t initially considered. We were very glad they pushed us to do this as it was fairly quick and I have heard a few people say they bought the book mainly for the appendix. Other than that, I don’t think the content and tone changed that much from feedback from Manning.

Check out part 4 if you’re interested in what it was like after the book was published!