Write the Docs: Swizec Teller – What I learned writing a lousy tech book

I’m at Write the Docs today in Budapest and will be post­ing notes from ses­sions through­out the day. These are all posted right after a talk fin­ishes so they’re rough around the edges.

Swizec wrapped up the second day of talks. He writes code and books. The latter is the story he told.

The publisher found him after Swizec wrote a short blog post about displaying dots through d3.js. About a month after the blog post he got a book proposal via India. That was October of 2012. He quickly read the spec for d3.js and faked his way through an outline. The “good” news was that the publisher liked the outline and signed a contract for the book.

Then came the writing of a book. He outlined this as a 4 step process

  1. Think about it. Decide what you can cover in Chapter 1 that doesn’t require you to say, “This will be explained later.”
  2. Learn about it. Read the API spec, figure it out.
  3. Code it. Prove that you’ve actually learned something; it’s a means of testing your writing.
  4. Write about it. Pull it all together and synthesize the experience.

The nice thing is that writing about something you’ve already learned how to code can be extremely easy. Finishing the book becomes about repeating that cycle for each and every chapter.

After 66 days and 171 hours of writing Swizec had a 179 page book. He was sick of the book by that time but was happy that it was done. Then came the editing. While he was happy with the book the publisher came back with, “We love it!…but not really.” They wanted him to shorten the book by 60 pages. Swizec then rewrote everything. While he didn’t have to make new examples he essentially rewrote every piece. He killed the beautiful turns of phrase, jokes, and other pieces that made writing fun. Throughout the editing process he relied heavily upon On Writing Well.

That was the major rewrite. He then did another minor rewrite of additional typos and fixes. Unfortunately then the technical editors got back with their feedback and suggested even further rewrites to the technical examples in the book. Luckily by this point publication was so soon he refused to do deep structural changes. The book was published in October of 2013, one year after starting. After 12 months and 333 hours it somehow ended up being 194 pages long. It shipped on his birthday.

After publication he didn’t get much information, just a quarterly report of sales and royalties. It’s sold about 1,000 copies so far.

Overall Swizec learned that publishers are difficult to work with and that books can be the best way to learn a piece of software. Writing a book is a hard, humbling slog and is truly a fight.