Writing a Programming Book: FAQs after Writing Learning React Native

6 min readFeb 11, 2016

In 2015, I wrote my first book, Learning React Native, and published it with O’Reilly Media. The book has been out in print for about a month now, and I’m really happy with the reception thus far.

I’ve received a lot of questions from friends, acquaintances, and random strangers about the process. Here are some answers to the questions I hear most often.

Why did you write a book?

Because I wanted to, and the opportunity arose. I enjoy teaching technical topics. And frankly, being an author just sounded cool. These aren’t great reasons, but I’m really glad I did it! More specifics in the “payoffs” section below.

I did not write a technical book because of the expected profits. (Don’t do that.)

How did you get a book deal?

I had already been speaking and writing about React when the opportunity arose to write a book. While there were already books about React in general in the publishing pipeline, to my knowledge, nobody was working on a React Native book yet. When I pitched to O’Reilly, React Native wasn’t even publicly available: it was still in private beta after React Conf 2015, accessible to conference attendees via Github. So, the timing worked in my favor.

The proposal process is pretty interesting. You fill out a document with basic information such as your proposed table of contents, your vision for the book, some basic market research, etc. My proposal was about 10 pages long.

Why not self-publish?

There’s a lot to be said for the credibility boost of working with an established publisher. It’s also convenient. My publisher took care of pesky things such as: writing the index; page layout; printing; etc…there’s a lot of moving parts in producing a book, and I just wanted to write one.

O’Reilly was generally great to work with, and the book is much stronger because of their involvement, especially in the editing process.

Bonus: now I know that my patronus is a ringtail possum!

What format did you use for writing?

I used a markdown-ish format, Asciidoc, for writing Learning React Native. My main book lived in a git repository, and I wrote myself a small script to push & compile my book into a PDF so I could preview it as I wrote. (The sentence “I’m compiling my book!” still makes me smile.) I kept my example code in a separate Github repo. This worked reasonably well.

O’Reilly provides some basic tools that “compiled” my Asciidoc files into various formats. This was great, because I didn’t have to worry about layout or typesetting. It did, however, require that I push my book up to their servers, then download the PDF (or other eBook) version to preview it.

TLDR; Asciidoc worked fine, no complaints.

What’s the process like?

I wrote Learning React Native while also holding a full-time job at Codecademy. The entire process took about eight months, start to finish. It began when I pitched to O’Reilly. That included writing a fairly lengthy proposal, including a fleshed-out table of contents. After my proposal was accepted, my editor, Meg, worked with me throughout the rest of the project.

That table of contents was an invaluable guide and benchmark during my writing process. Writing an entire book is difficult. Writing a sentence, or a paragraph, is easier. Writing Learning React Native consisted of writing many sentences, and paragraphs, and in the end I had a book. I don’t mean to be flippant — the honest answer to “how did I write a book” is, bit by bit, in the mornings before work, every day, for months.

For each chapter, I planned out what topics I wanted to cover; brainstormed what sample apps I could build to demonstrate them; wrote the example code; then wrote the chapter. This pattern worked reasonably well. If I encountered issues while writing the example code, I’d go back and rework my plans for the chapter.

There were some alarming unknowns. React Native was so new, and immature, that things kept changing as I worked. Android support, for instance, came out a month before my first draft was due — surprise! I decided to go back and weave Android examples and compatibility into the existing manuscript. (If you bought the “Early Access” edition, you may have noticed that the first few chapters were re-written entirely, several times.) By the time I was finishing my first draft, though, the framework had mostly stabilized.

I wanted to be done with the first draft by September. Due to the vagaries of fate, that didn’t happen. But! I finished my first draft in mid-October, so, not too shabby. After submitting the first draft, it was time for revisions and edits.

I should have taken a more active role in finding technical reviewers, and I should have sought them out sooner. That being said, my tech reviewers were great, and provided solid feedback that helped sharpen the book’s message and focus.

My copyeditor, Jasmine Kwityn, did a really thorough job and the text is much stronger thanks to her work. The downside of this, of course, was that I had to spend a large chunk of time working through all the edits! Editing was draining. Also, we hit the limit for how many comments Adobe Reader could comfortably render, so we had to split the PDF in two. Fun!

What was the payoff?

So. I finished the manuscript. It went through review, again. I made some last minute changes, again. Then…that was it. I sat on my hands for a few weeks and…waited. By the time it showed up on Amazon, and the print copies arrived at my door, I was giddy. (I was also confused. I had free time again. I could…sleep?)

So, at the end of it, I had a real! solid! book! to hold in my hands, which was awesome. There were other payoffs, too. Most notably:

The satisfaction of having spent lots of time learning and thinking about a topic.
The credibility of being a published O’Reilly author, and the bizarre thrill of getting to say “I wrote the book on it.”
More invitations to speak and teach workshops, which sometimes come with honorariums or tuition fees.
Splendid, kind comments about the book from Internet strangers. (Seriously, to everyone who has reached out with feedback and thoughts about the book: THANK YOU for being rad.)
A small royalty check in my mail, monthly.

I’m going to repeat this again: don’t write a programming book for the royalties. While there are lots of hard-to-quantify benefits, the royalties themselves won’t justify the project. (Because of the lag between sales and royalty calculations, I don’t have enough data yet to be more specific here, but I doubt that it’ll equal, say, what I could have made freelancing during that time.)

Also: I get the satisfaction of saying, yes, I went from zero real-world JavaScript experience to having published an O’Reilly book on it in…roughly 18 months. (This is perhaps the best shorthand I’ve developed for explaining how I prefer to learn things. Deep dives, etc.)

For me, personally, this project was 110% worthwhile, in terms of both tangible and intangible benefits. I’m proud of the end result.

Should I write a book?

This is a really personal decision! Do you have a year of your life to devote to it? Can you handle long, self-guided projects? Do you honestly enjoy writing and teaching? What do you think you’re going to get out of it?

TLDR;

Writing a book was really cool! It was a lot of work. I am very grateful for the experience and extremely happy to see the book out in the real world. Don’t do it for the money. Oh, and maybe buy my book?

New Year’s resolution for 2016: take a year off from giant projects.