Charles Petzold

Congratulations to Jeff Atwood on the publication of his first book. Jeff seems to have found the book-writing process to be hard work with few rewards. (And this is a "tips" book with three co-authors!) What he says about book-writing is mostly true, but I'd like to add a few clarifications.

Declining Book Readership

People are probably reading and writing more than ever, but a lot of this reading and writing is online. Consequently, book reading has suffered.

Is book reading too circumscribed for the modern sensibility? Once your finish one page, you have to start in on the next. Otherwise, you're no longer reading the book. What fascist made up these rules? Reading online is much more flexible. Hyperlinking actually encourages bouncing around from page to page, from topic to topic, from site to site. You're not done until you stagger bleary-eyed from the screen.

Distractions can be deadly for book reading, yet the modern world is a monument to distractions! You can't multitask while reading a book. (Except for walking — I sometimes like walking around when I'm reading a book.) Reading requires Patience and Fortitude, not coincidently the names of the two lions who sit outside the New York Public Library. Many people are out of practice in reading books, and sometimes it's helpful refamiliarizing oneself with some of the required discipline.

Declining books sales have led some publishers into thinking that the way to revive books is to make them more like an online experience. That is truly a mistake! It's like trying to get people to exercise by making it more like napping.

The Death of Programming Books

Some types of books have been harder hit by the Internet than others. At a library fundraiser in Sullivan County over the weekend I saw a complete immaculate recent edition of the Encyclopedia Britannica marked down from $45 to $40 to $30 as the day went on. Surely noone these days needs an encyclopedia that doesn't even describe plots of Doctor Who episodes!

Programming books — particularly tutorials (such as I write) and "tips" books (such as Jeff's first book) — have also been hard hit. So much information is available online that books seem superfluous. To many developers these days, if it doesn't show up in a Google search, it doesn't exist.

The other problem is the introduction of too many APIs and languages. Programmers need to know a lot of different stuff these days, and no time is available to learn anything systematically. These days programmers often learn a new topic by starting with some sample code, messing around with it, searching out stuff as they need it, and basically floundering around.

I can't denigrate the floundering-around approach because that's the way I learn a new API myself! (Of course, I have the excuse that when I learn the API there aren't any books available, and I'm learning the material with the intention of shaping it into a coherent tutorial.)

Plenty of evidence is available in the MSDN Forums that programmers these days often don't learn a new API systematically, which is what a well-structured tutorial offers. In the long term, this might be a problem, but exactly what "long term" are we talking about when APIs are replaced every few years?

Feeding the Author

Authors of books are paid a royalty for each copy sold. The royalty is based on publisher's receipts, which requires a little explanation:

A book has a cover price printed right on the book. For computer books this is generally between $30 and $70.

About half that cover price is consumed in the distribution and retail chain. That's why bookstores are able to offer bestsellers at up to 40% off and still take in 10% of the cover price on each copy.

The other half of the cover price goes to the publisher. From this amount, the publisher pays a royalty to the author, generally in the region of 10% to 15%. (The royalty rate is usually lower for the English-language book sold outside the U.S., or outside the U.S. and Canada. For translation rights, the foreign publisher pays the U.S. publisher a flat amount, which the publisher splits with the author.)

For a $50 book, the royalty might be $2.50 to $3.75 a copy. As Norman Mailer used to say, you buy an author's book, you buy the author a drink. (Let's hope not literally!)

A programming book might require 6 months to a year of full-time work. (That's my experience, anyway). These days, sales of 10,000 copies over the first year is considered cause for rejoicing. A few years from now, the rejoicing benchmark might be much less. You can do the math yourself. It's pretty bleak.

Those of us still writing programming books often feel increasingly foolish for doing so. The money has dropped so low that the act has become financially irresponsible. Most programming books these days are written by people who have real jobs, either working for someone else or owning their own consulting firm.

I was one of the few exceptions to this rule. Since the summer of 1985, I was able to call myself a "full-time freelance writer." But that's no longer the case. For the first time in 22 years I've been doing some consulting to supplement my ever-dwindling royalty income.

If you'd like some help with your WinForms or WPF app, you can hire me through Wintellect.

What About the Advance?

In his blog entry, Jeff says "less than 30% of computer books sell enough to generate any royalties whatsoever," but that's not entirely accurate.

Publishers usually pay an "advance" on the royalties. This is generally paid in installments: some of it when the contract is signed, then more as chapters of the book are progressively completed. If the author doesn't finish the book, generally the advance must be returned.

In theory, the advance is intended to help the author eat while the book is being written. Everybody hears about big-shot authors getting six-figure or even seven-figure advances. In the computer-book industry, this is not the case. The advances (including the ones I get) are usually in the low 5 figures, and sometimes barely 5 figures at all. (Publishers tend to calculate advances as royalties on projected sales over the first year.)

You don't hear much about the advances paid to authors of programming books, because it's downright embarassing. Publishers would be embarassed to disclose the advances they offer authors, and authors would be embarassed to admit that they accept them.

After the advance, the author doesn't get paid any additional money until the royalties surpass the advance. (There are other complications involved, including reserves, but I'm trying to keep this simple.) I think what Jeff was referring to was royalties beyond the advance. I don't know the statistics, but if fewer than 30% of computer books sell enough to make back the advance, I'd believe it.

Why Books? Why Not Blogs?

Once you've restricted yourself to information that turns up in Google searches, you begin having a very distorted view of the world.

On the Internet, everything is in tiny pieces. The typical online article or blog entry is 500, 1000, maybe 1500 words long. Sometimes somebody will write an extended "tutorial" on a topic, possibly 3,000 words in length, maybe even 5,000.

It's easy to convince oneself that these bite-sized chunks of prose represent the optimum level of information granularity. It is part of the utopian vision of the web that this plethora of loosely-linked pages synergistically becomes all the information we need.

This illusion is affecting the way we learn, and I fear that we're not getting the broader, more comprehensive overview that only a book can provide. A good author will encounter an unwieldy jungle of information and cut a coherent path through it, primarily by imposing a kind of narrative over the material. This is certainly true of works of history, biography, science, mathematics, philosophy, and so forth, and it is true of programming tutorials as well.

Sometimes you see somebody attempting to construct a tutorial narrative by providing a series a successive links to different web pages, but it never really works well because it lacks an author who has spent many months (or a year or more) primarily structuring the material into a narrative form.

For example, suppose you wanted to learn about the American Civil War. You certainly have plenty of online access to Wikipedia articles, blog entries, even scholarly articles. But I suggest that assembling all the pieces into a coherent whole is something best handled by a trained professional, and that's why reading a book such as James McPherson's Battle Cry of Freedom will give you a much better grasp of the American Civil War than hundreds of disparate articles.

If I sound elitist, it's only because the time and difficulty required for wrapping a complex topic into a coherent narrative is often underestimated by those who have never done it. A book is not 150 successive blog entries, just like a novel isn't 150 character sketches, descriptions, and scraps of dialog.

Reaching the Programmer Audience

It doesn't take a genius to figure out that if programmers aren't reading paper-and-ink programming books, there ain't no sense in writing them.

It doesn't take a genius to figure out that if programmers are getting most of their information from Google searches, then writers like me should be spending their days generating online content.

It doesn't take a genius to realize that this online content can be chopped up into 500 to1500 word chunks for location and consumption through Google searches.

It doesn't take a genius to realize that these pieces can also be assembled into a tutorial narrative for people who prefer to learn a topic less haphazardly, or who come upon a topic through a search and want to know what came before, and what comes after.

It doesn't take a genius to make a lot of — oh, actually that's the problem. The writer needs to eat but the content must be free.

(For the record, if you are a publisher, and you have an idea how to make this online "granulated tutorial" approach work, I would be more than willing to write as much code and prose for it as I write for a typical book. The only catch is that I would have to be paid less like a book author and more like a consultant.)

Of Course Writing Books is Hard!

But that's what makes it fun and rewarding!

When I say "book" I don't necessarily mean something with ink-stained paper pasted into a cardboard binding, although I have certainly expressed my fondness for these marvelous objects. Even if printed books disappear, we definitely must find some way to retain "prose narratives of 100,000+ words" and to persuade people to read them, and hope that people write them.

You really shouldn't try to write a book unless you have a fire in your belly. If you have that fire, then nothing that Jeff Atword or I can say will discourage you.

To me, writing blog entries is like tapping out a tune on a piano, or drawing a little sketch on newsprint. Writing a book is closer to painting a mural or composing an opera. It's not just longer; it has to hold together with internal structure and coherence. It has to go somewhere. It has to tell a story. That's the part that's really challenging.

I am extremely fortunate for having the opportunity to write books for a living, and I hope to be correcting page proofs on my deathbed. I have 5 books in various degrees of progress (ranging from barely more than a title to 75% completed) and none of them concern .NET. These are technological-historical-philosophical narratives all dealing with automated computing.

One of these books is scheduled to be published in the spring of 2008. I've been working on it sporadically since 1999. It is the hardest book I've ever written, and it has to read like the easiest.

I am very happy writing this book, but I would be much happier if people actually buy it and read it.