How I wrote a technical book in under 200 hours

Earlier this month, I published the book Level up with WebAssembly. 🎉 It aims to be a practical guide to using WebAssembly, a new programming language that helps you port existing C/C++/Rust code to the web. I wrote the book because I found that while WebAssembly had a lot of potential, the learning curve was quite steep.

The last time I wrote a book (Adventures in Data Science with Bash), the most common question I got was: “How long did it take you?”. While I didn’t have a clear answer then, I do this time!

From the moment I decided to write a book about WebAssembly — 6:22pm on November 11 2018, to be precise — I kept track of how long I spent on every aspect of the book, including research, writing, editing and marketing.

From idea to publishing, this book took a little over 185 hours to complete. The book features 85 pages organized into 11 chapters, and the top package includes cheat sheets, screencasts, a capstone project, and a case study, for a total of ~125 pages worth of content. Of course the clock didn’t stop once I published the book! There is always more marketing to be done, blog posts to write, and reader comments to respond to.

The following chart shows how many hours I spent working on the book every week from start to launch, between November 2018 and March 2019:

Although I spent an average of 12 hours a week on the book, there is quite a bit of fluctuation since this is a side-project that I tackled outside my regular 40hr work week.

Surprisingly, my three most productive weeks all capped (unintentionally) at 21 hours, with a standard deviation of only 10 minutes! I only have an n of 3, so this could be a coincidence, or… it suggests that there’s only so much WebAssembly my brain can handle in a week 😉.

And in case you’re wondering about the December 3 outlier, I was packing and moving that week!

To get some more insight into what exactly I spent my time on, let’s break down the 185 hours into categories:

Interestingly, I spent only about half my time on activities directly related to the book’s content. This includes writing and editing the book (33%), but also the time I spent coding to generate the material to write (23%). The coding portion involved things like figuring out how to compile UNIX tools to WebAssembly, building sample applications such as jqkungfu.com, and porting C++ games such as Pong and Pacman to the web. The remaining time was split between marketing (19%), research and planning (11%), packaging the book into different tiers (12%), and designing the cover (3%).

Looking back, one thing that surprised me was that I spent 17 hours crafting the landing page! This is about 15 hours more than I thought it would take, but I’m quite happy with how it turned out:

Next, let’s look at when and where I got most of my book written. Since I commute to work by train for ~1.5 to 2 hours for 3 days a week, I’ve made it a habit to pull out my computer and write whenever I’m on the train.

Wrangling the data some more however, it seems I only wrote for 55 hours total on the train, or roughly a third of the time. Although I clearly spent many more hours working on the book at home after work and on weekends, this book would not have materialized if I wasn’t writing during my commute. This is because the momentum generated by writing on the train kept me motivated to work on the book after hours. Heck, I’m even writing this article on the train!

Self-publishing a book is a project that involves a lot more than just writing; here are the tools I used to make that process smoother:

Google Docs: writing and versioning; works offline

Code Blocks: a Google Docs add-on for code highlighting

Trello: project/todo list management

Gumroad: payment processing and distribution

Canva: designing the cover

Asciinema: command-line screencasts

Toggl: tracking time

You may be wondering why anyone would self-publish in the first place. For me, it comes down to being able to craft the book exactly as I want it. When you self-publish, you get to explore different pricing schemes, design the book’s “user experience”, and include the kinds of material I haven’t seen in traditional books, such as command-line screencasts, capstone projects, and case studies. There’s also the **possibility** of making more money if your book is useful and your marketing conveys that to potential readers.

On the other hand, the downsides are: less prestige, no money advance, fewer external motivators, and no editors. Also, there are aspects of book publishing that I was excited to work on that others might prefer to avoid, such as crafting the landing page, formulating pricing schemes, and designing the cover.

I’ll leave you with a few takeaways from my experience so far writing technical books:

When starting any side project, I have to fight the urge to work on things that make me feel productive, but that don’t actually matter at that stage: finding a name, registering a domain, choosing a template, designing the cover, crafting pricing schemes, and so on. I found that when starting out, what works best is to forget all that and focus on what matters: writing content that helps the reader achieve results. The rest is best tackled once the book nears completion.

One common suggestion I’ve heard is to commit to writing X words every day. While this works for some, I find the minimum to be daunting; instead, my goal was just to write something every week. As mentioned above, the habit of writing every time I rode the train was an important catalyst to keep me going.

While I did write the book in under 200 hours, that number doesn’t include the time it took me to learn WebAssembly in the first place, and work on projects to get my feet wet (e.g. fastq.bio). I haven’t tracked that time but it’s certainly in the hundreds of hours. Also, the 200 hours don’t include the time I spent after the launch on marketing, writing blog posts, answering questions from customers, and updating the book.