Why Write Books?

I want to caution you, though. The path to writing programming books is not a get rich quick scheme. There are no shortcuts, but if you approach it seriously, it can generate a fair income. As was mentioned before, I’ve met dozens of technical authors online and in person who’ve made anywhere from $10,000 to $130,000 on a single book, usually in a span of just a few months, by working on it part-time in addition to their full-time jobs or freelance projects.

The best part is that after a relatively intense and active period of writing and publishing, you can enjoy the income passively! This beats even Software as a Service (SaaS) products because they require ongoing support and maintenance. Aside from fixing bugs and typos once in a while in new releases, books are pretty much an upload and forget thing. In other words, you have the potential to make money without putting in hours of labor. You can make money in your sleep! It was fascinating to wake up in the morning and check my inbox: one, two, or three sales of Rapid Prototyping with JS via Leanpub. Whoo-hoo! The magic of passive recurring income is obvious. But I noticed that other aspects of the process were more important to me in the beginning when I had zero sales: improving my understanding (sometimes learning something from scratch) and my thinking and writing skills and helping others.

Writing a book is not easy, unless you enjoy writing (on a blog for example) like I do. You must have good reasons to write a book in order to successfully finish it and make it a hit.

Not-so-good reasons to write a book:

• To make tons of money and live the author’s lifestyle—whatever that means (probably living on an island).

• To become famous: only in narrow circles of nerds and geeks (my pinnacle is shown in Figure 2-1).

• For prestige and reputation, or because it’s trendy and everybody has a book: this is the worst reason to write a book. But without a doubt, having a book listed on a résumé is a good way to hack your way into a job.

Why Write a Programming Book?

Why write programming books and not novels? Because anybody can write a novel, and the fiction market is super saturated. The demand is also higher (anyone who can read versus only people who program or want to start programming, as shown in Figure 2-2). However, because programming books help people to make more money and they are not just entertainment, they are priced two to three times higher, that is, $20-$50 per technical book vs. $3-$10 for a novel.

Traditional vs. Self-Publishing

There is definitely more money in self-publishing. The traditional publishing model is dying, or (depending on how you look at it) changing to adapt to the rapidly growing market.

Typically, royalties can range from 6 to 10%, depending on the volume. This seems to be on par with the majority of the tech/programming publishing industry.

However, one publisher has a different model. In it, the company splits profits with authors, but my calculations showed that it ends up the same as ∼10% of the listing price. It is, however, more confusing due to discrepancies in normal, promotional, and distribution pricing .

Remember, advances are not free money. They count toward your future sales. So if someone gets $3,000 in advance upon publication (a typical range for new authors is somewhere between $1,000 and $5,000), that means it will be the last money that author will see in a long time. This is because with 10% royalties on, let’s say, a $29.99 listing price, it will take 1,000+ copies to break even and re-coup the advance. Sadly, 70% of technical books never sell more than 1,000 copies due to the narrow market and traditional publishers’ poor marketing. Therefore, the advance is the only money the majority of traditionally published technical authors will ever see. Maybe that’s the reason that more and more authors make their books available for free online in the hope of generating more buzz and attracting more attention.

Most traditional publishers do close to no marketing for your books.

As always, there are trade-offs and benefits . Traditional publishing gives a higher-quality product for beginner authors and the brand recognition, with the cons being lower royalties and less marketing flexibility.

There’s no cookie-cutter answer here. Knowledge (such as reading this book) is a key component of success. While writing books is hard work, the rewards far outweigh any drawbacks. The benefits are there, but only if you’re willing to put in the effort! In the following sections, I’ll share how I produced and marketed my books. I hope my experiences help you on your own path to becoming a successful progwriter.

The Time Spent Writing

An average book consists of about 300-400 pages or 30,000-40,000 words. At a speed of 1,000 words per day, that’s at least a month of full-time work (that’s 20 days multiplied by 8 hours = 160 hours). This calculation brings us an average hourly rate of $18.75 ($3,000 divided by 160 hours). In most areas of the United States, that’s below an average programmer’s hourly rate.

However, if an author needs to perform extensive research, which is usually the case, and/or creates a few sample applications, the pace slows down, bringing the monetary benefit even lower. Sometimes I wonder if I can make more money by working at a coffee shop rather than writing in the coffee shop.

But there are outliers who make $50,000-$100,000 on their books. That’s what you should aim for if you want to make big bucks in publishing (and I’ll show you how to increase your chances).

For me, the realization that writing programming books generates serious side income came when I started making $300-$500 each month. I thought to myself: “Hey, if I can produce five or ten more books like this, it’ll be a piece of cake to make a few grand per month!”

Before you get too excited about the process, let’s dive deeper into what constitutes an author-publisher-entrepreneur process, using both self-publishing and traditional publishing.

The ProgWriter Creative Process

Step 4 is rather unpredictable and might take a few proposals to get a deal.

My personal observation is that lean publishing is better suited for established authors (or people with existing followings through blogs, newsletters, or social media) and for hot topics that serve a huge demand in the market. In other words, sell painkillers, not vitamins. Sublime Produc tivity  ⁶ is a good example of such an approach.

In any case, make sure your book really shines! Don’t permit any bugs or typos. I made this mistake with Rapid Prototyping with JS and got a lot of hate e-mails. Books are not like SaaS apps, which we might use quite often over the course of a week. Books are quite the opposite, because readers will, most of the time, pick up a book once only (or not at all), and if they don’t like what they see in the beginning or TOC, readers rarely come back. Even if someone read a book, liked it, and found some minor issue, they rarely come back to its new revisions. Books don’t produce as many feedback loops as software does. Also, the communication channel with books is not as clear as having a UserVoice⁷ form on your SaaS application. I found an anecdotal support that forms work better than e-mail does, because people tend to perceive forms as less humane and less personal, and therefore are more likely to submit the feedback that way.

No matter what, make sure your book is well edited (steps 7-10). In this sense, books are like software: it’s better to have fewer features with no bugs than lots of features with bugs. Again, I learned this the hard way when I released half-baked portions of Rapid Prototyping with JS ⁸—typos distracted readers from my message.

In Chapter 3 we’ll look at the research phase of your future book project and a few other topics.