How I wrote a technical book in under 200 hours

A behind-the-scenes look at how I self-published “Level up with WebAssembly” as a side-project in 4 months.

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 (click here to learn more). 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.

Show me the data

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.

Bird’s eye view

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:

Number of hours spent on the book every week from start to launch.

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!

Breaking it down

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

Breakdown of time spent on the book 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:

Landing page for the book

The commute factor

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!

The tools

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

Why self-publish?

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.

Lessons learned

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

Focus on writing

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.

Make writing a habit

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.

200 hours is just the beginning

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.