Publishing a Technical Book (Part 3): The Writing Process
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]
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!