Writing Tech Books? Stock up on Ramen

Back in the mid 1990s, when I began writing books, you could write a book on Windows or Microsoft Word or HTML and be able to command an advance upwards of $18,000 to $20,000, and 18% royalties on gross and sell potentially tens of thousands of books.

Many prominent names in the tech industry got their start financially this way. By the early 2000s, there was a big pressure to produce books by getting five or six authors together to write books; one defunct publisher in particular was known for the Brady Bunch style of headshots that would touch on the latest semi-hot topic of the day.

However, by 2004, the bottom had dropped out of the technical book publishing market. The number of people going into the tech field had been far exceeded by those who were running as far away from it as possible, and throughout that period, readership of these 750 page doorstoppers kept plunging, along with both advances on royalties and the royalties themselves. This also led a lot of authors to throw in the towel and either go back into tech or take their experience and apply it to other sectors.

I write technical books, white papers, articles, blog posts and documentation, along with consulting on technology and writing novels. Given my druthers, I'd much rather write blog posts and novels. There's a clear reason for this, and its one that many technical authors should be able to relate to: most technical books do not pay for themselves. There are caveats to that, which I'll cover below, but the reality is very simple: you write a book to help establish yourself as an authority in the field, to gain expertise, to serve as a cool greeting card in job interviews, and something that will get you invited to conferences. All of these are great reasons, but they all depend upon a central tenet - you must really, really, really like the subject that you're writing about.

A contemporary novel is usually about 125,000 words (and with e-books, that figure now may be closer to 75,000 words), and will be around three hundred or so pages. It usually takes about six months to write a first manuscript, and a year to finally see it in print. Most of that time is spent on revisions, on edits, on prepwork and formatting. Again, with eBooks that's dropped, but the idea is that you can generally get two to three such books done in a year unless you're some kind of demonic fiend. A good day is writing twenty pages, most days are closer to ten, and some days you can't get past "She was a dark and stormy knight."

This is important, because technical books are much longer, much denser, and much slower to write. Why? First, you are dealing with a technology that in all likelihood has not been fully documented. If it was, then why are you writing it in the first place? Sometimes you're dealing with beta versions of things, so you can't even trust that what you are writing is going to be accurate when published (which happened on my first book).

Moreover, you as the author need to understand the material. That's not a trivial undertaking. Being a technical writer means that you not only have to be a self-teaching (autodydactic) learner, but you have to be able to write this information in ways that makes sense to a potentially less familiar person than you.

You spend a lot of time writing examples. Those examples need to be conceived, written, tested, and then documented as well. This becomes even more problematic when what you are writing is destined for electronic publication, because you need to also manage that code and figure out a way to host it. One suggestion - as a writer, set up a subversion or github account before you write word one. It will save you much anguish, and you're less likely to overwrite your own examples, which otherwise happens with alarming regularity.

So, figure five pages a day as a good ballpark, or about a chapter a week. A two hundred and fifty page book will then take you about 26 weeks, or six months, of full time writing. In 1995, I got an advance of just shy of $18,000 for that. This translates into $36,000 a year, or about $18 an hour. Beats working at McDonalds, but not by much.

Now - royalties. This is where the big money comes in, right? Weeelllll, maybe. The contract that I had was staggered, but worked out to about 16% of net sales. Now, a $40 book, would have net sales of about $6.40, so selling 50,000 books should net you around $320K, right. Man, sign me up. But hold on a second. This is net sales that we're talking about, which is usually about 60% of gross, so that same book is now only netting you about $4 a book, or maybe $200K.

Still, a nice income, except for that huge assumption about those fifty thousand books. If you're writing the first edition of a Word for Windows book, you could easily sell 100,000 or perhaps even several hundred thousand books. If, on the other hand, you're writing about Secret Tricks of the RDF Data Modeling Masters, your whole audience is likely maybe two or three thousand people. So assuming that maybe one in three (and this is really generous) actually buy your book, you're going to make gross sales of $4,000. Not forty thousand dollars, four thousand.

Now, you begin to get the picture. If you get an advance of $18K, you may very well end up in the whole $14,000. But wait, it gets better. Keep in mind that those sales don't happen all at once. You get an initial burst from pre-orders and then there's a decay that sets in, to the point where you're selling a book or two a season. That window is about three years tops, with most sales in the first six months.

I had a publishing company come up to me recently trying to sell me on writing a secondary technical book on a reasonably well known analytics platform. They offered a $1500 advance for a two hundred page book and supporting electronic material, and a 12% net royalty rate. with a 6% net rate for electronic sales. I politely declined.

I could have used the money, but $1500 is about four technical articles to various online magazines, at perhaps four hours per article (and most of that is coding and testing). A two hundred page book would have required massive research in getting familiar with the platform, then that same five pages a day rule kicks in - it comes to about four months of serious work. The electronic content would need to be both accurate and work, and generally required some serious technical chops to know how to create it in detail.

Similarly about that royalty rate - this is a secondary book focused on one aspect of a fairly complex application. There may be 10,000 users of the software, but you're already dealing with an application that is well documented internally. Moreover, fare more would end up likely buying it as an ebook in this day and age, where you have to factor in Amazon and its various discounts. You would make back the advance, but chances are pretty good you're not likely to see more than three to four thousand dollars out of it, well below minimum wage for the time you put in.

Given all this, why write technical books? There are actually some very good reasons. First, writing a book is a good way to not only learn about a topic, but to gain expertise in it. This is especially true when the industry goes through those inevitable economic slowdowns, though writing articles and "short books", under a hundred pages is likely better. You can also more readily get those into print by yourself through Amazon, Safari or similar outlets.

They are also better when you want to influence the industry. I've been quietly working on a book on Data Modeling for Semantic Data Hubs. pulling together a lot of my own thoughts and research about data modeling, semantics, and data driven architectures that has appeared in articles in various fora. I don't expect it will make me a millionaire, or necessarily even give me more than coffee money, but I do expect it will make it easier for me to make the case to my clients better than I can elsewhere. A big part of that also comes back to recycling what you write in one form for use in another, which tends to be a problem when dealing with existing publishing deals.

There is also a certain degree of playing the lottery here. One book by itself may not necessarily net you a lot, but there's always the possibility that you might also end out with the breakout book of the year, especially if you're dealing with a cutting edge technology. Blockchain is interesting because it's novel, Internet of Things, Machine Intelligence. Cognitive Computing, Quantum Computing for Dumm(-er, sorry, that one may be trademarked). Books on R and Data Science with Python are becoming passe (indeed, most computer languages have pretty much become niche). I might write a book on Social and Computational Semiotics next year - or, to put it into more mundane terms - Truth vs. Alt Facts.

The key, though is not to let an editor dictate to you the choice of a book. Far better to sit down and work an idea up, because it is important to you - it is something that you are willing to spend four months eating ramen noodles or mac and cheese to achieve. Because you will be eating a lot of ramen.Writing is an endeavor that takes lots of time. Your enemy in this case is not the editor or the publisher, but the relevance and novelty of your subject. Your goal is to tell an interesting story, to teach a concept or idea, not to write a comprehensive encyclopedia. Write what's germane to you.