Reflections on writing a book

March 24, 2025

I wrote a book! It’s called WebAssembly from the Ground Up — it’s an online book where you learn Wasm by writing a simpler compiler in JavaScript. You can read a free sample if it tickles your fancy.

Together with my friend Mariano, I’ve been working on the book for just over two and half years. And (big surprise) it was a huge learning experience! While everything is still fresh in my mind, I wanted to capture some of the things we learned here.

The clichés

Let’s start with the obvious stuff — the advice you’ll find everywhere, the things everyone wants to tell you when they hear you’re writing a book.

You won’t get rich

Don’t do it for the money. Or the fame. Or any kind of immediate payoff, really.

I don’t think I could have pulled of a project like this if I didn’t find it intrinsically rewarding. The book was something we wanted to exist in the world. Early on, I decided that even if nobody cared about it, I wouldn’t regret doing it.

It’s a marathon

It will take longer than you expect, and then some. As with running, picking the right pace is important. This is especially true if the book is not a full-time project (as it wasn’t for us).

It ended up being very seasonal for me. There were times (maybe ~6 months in total) where the book was my main focus; the rest of the time, it was second or third on my priority list.

When it was my main focus, I tried to put in four or five hours of deep work on most weekdays. In the other periods, I tried to keep a regular schedule: sometimes a day a week, or — when I really need the momentum to get a new chapter out — an hour a day.

Some of the techniques I wrote about in Getting things done (in small increments) came in handy.

The surprises

This would be a very long post if I tried to capture everything that we learned while writing the book, but a few things stuck out as being a bit more surprising than the others.

Feedback is…complicated

We had both read Write Useful Books and were determined to take its advice to heart. We had early reader conversations and built up a list of interested beta readers. This was definitely helpful — it confirmed that there are people out there who would be interested in the book. And it definitely gave us a better idea of who our potential readers might be.

But, while we’re very thankful for the feedback that we got, it wasn’t quite as clarifying as we’d imagined. Maybe it’s because of the subject matter, or maybe we should have done something differently. But I think Write Useful Books underplays how much you still need to rely on your own taste and intuition to guide you.

Explorable < explanation

Our original idea was to make the book quite interactive, and include explorable explanations. We did include some interactive elements, but they’re not really essential to the book. Honestly, we didn’t put in the time that would have been required to make them really great.

The thing is, we found a much bigger payoff in focusing on the explanation. What’s the point of this chapter? What is the right order to introduce the concepts? What should we move to another chapter, and what should we cut altogether?

The time we spent improving the core content of the book felt so valuable, and compared to that, it spending time tweaking the interactive parts just didn’t seem worth it.

Constraints are helpful

From the beginning, the book was planned to be (a) self-published, and (b) online-first. This meant that we could do almost anything we wanted — but in retrospect it was maybe too much freedom.

We spent a lot of time thinking about some basic things, like:

We ultimately came up with a structure we like, and we might use a similar structure if we write another book. But we spent a lot of time thinking about things that had nothing to do with WebAssembly.

When I compared this to previous writing experiences — my master’s thesis and a handful of academic papers — I realized how much value there is in having a fixed structure. Academic papers have a template and a page limit, along with many conventions that reviewers and readers expect. Within those boundaries, there’s a bit flexibility, but the overall structure is pretty fixed.

If you’re thinking of writing a self-published book, my advice would be: pick a book that you like, and use its structure as a template. Focus on the core material that you’re writing about, and worry about the other stuff later (if at all).

I could write another thousand words on things that we learned from writing this book. But would it help anyone? I suspect that — like being a parent — you won’t really understand until you’ve made the mistakes yourself.

Are you thinking about writing a book? My advice: go for it! You won’t regret it.