As some of you know, in the early years of the 21st century, I wrote a book on C#.

Since then, I've had a number of people who are interested in writing a book themselves ask me about my experience, so I thought I'd spend some time to write something down.

So, you want to write a computer book...

There are many reasons that you might want to write a computer book - or some other kind of book, for that matter. Unfortunately, some of those reasons may not pan out the way you expected.

Money

Here's a quick lesson on the economics of book publishing, in the computer world. I believe that this also applies generally to the rest of the technical world. I know little about writing non-technical books - even less than I know about writing technical books - but I know enough to know that what I'm about to write doesn't apply there at all.

Book royalties are calculated as a percentage of the wholesale price of a book, which is generally 50% of the cover price. In my understanding, royalties generally range between 10% and 15%, with the higher ones going to more established authors.

Let's say that you write a \$40 book with 10% royalties, and it sells 10,000 copies (a pretty decent sales figure, from what I'm told). That means that your royalties are:

\$40 / 2 * 0.1 * 10000 = \$20,000

That's pre-tax, of course - you'll need to pay income tax on your royalties, and you may also have to pay social security tax on it. I allocate about 40% to that, leaving you with \$12000.

Is that a good deal? Well, it's nothing to sneeze at, but you need to figure how much time you spent on it. On the first verson of my book, I estimated that I spent at least 400 hours. If that figure is accurate (I have some reason to suspect I underestimated...), that means that I made about \$30 per hour (\$50 per hour pre tax). That may or may not be a good deal for you.

Books are a good example of non-linear return for the effort. If you sell only 3000 books, you get about \$10/hour for the work. If you write a classic like Code Complete and sell a lot of copies, the return could be much better.

Easy Money

Even if you're a bestseller, writing a book is not easy, so you won't get easy money out of it.

Fame/Glory

If your book is successful, you may get some fame out of it (perhaps "notorioty" is a better term). While it's an interesting experience to be "famous" for your work, fame doesn't feed the iguana, with one specific exception (see respect).

"Chicks dig computer book authors..."

You may rest assured that your author status is likely to have no noticeable effect in this area.

Respect

If you write a good book that is well-received, you will get the thanks and respect of others in the industry. While you can't spend this directly, being a "noted author" can open up opportunities on the employment side of things. Some consultants write books primarily to drive name recognition and respect so they can be more successful consulting.

Enjoyment

Today at lunch I had one of my friends ask whether I had fun writing my book. It's a hard question to answer.

I do derive considerable enjoyment from writing something that explains a particular topic well, and there were a fair number of those, but there is a considerable amount of hard work. To the extent that hard work is enjoyable (sometimes it is and sometimes it isn't), it was overall a pleasureable experience.

Learning

It is a reasonable expectation that you should be well-versed in your topic before you write a book, but no matter what your level, you will learn lots of new things. Not only are there 1001 details that you need to understand thoroughly before you write a book, there's nothing like having to commit your thoughts to paper to make you realize that you either don't know the details or are unsure of the details. I had to do a lot of research, and that meant I came out the other end with a lot more deep knowledge than I had before.

Qualifications

So, despite having read the earlier part of this article, you still think you want to write a book. The question now becomes "are you qualified". There are two aspects of this that I think are important.

Can you write?

Or, to put it more succinctly, can you write well in a reasonable amount of time without driving yourself and the people around you crazy.

Before you can get a signed contract, you need to be able to demonstrate this to your publisher (unless you're a big name draw, and the publisher is willing to pay for editing and/or a ghostwriter).

To find out whether this is feasible for you, you need to do some writing, and then you need to have an audience read the writing and give you constructive feedback. Writing is a skill, and over time you should be able to develop techniques that work will with your target audience.

Good ways to practice:

• Write a blog. Book writing is not like blog writing, but it's a good, cheap way to practice, and a great way to get quick and easy feedback.
• Write articles for an online programer's site - something like CodeProject.
• Write an article for MSDN
• Answer questions on newsgroups or message boards

Strangely, the most important of these - the last one - has the least to do with formal writing. But it's the most important, because to write a good book you need to have a deep understanding around what is hard (ie what is hard to understand, what is poorly documented, what is confusing, etc.) *and* you need to be able to explain things in ways that people understand.

Both of those are cheap and easy to accomplish in a newsgroup. There's also an important side benefit to be had with community involvement, which I'll touch on later.

Are you uniquely qualified?

I know nothing about building and configuring Beowolf clusters. While with a huge amount of effort, I'm confident I could learn enough to write a book about them, getting to that point is far more effort than I want to, and I can't even know if there are good books already out there until I invest a fair amount of effort.

So, you need to be uniquely qualified. That means one or more of the following:

• You invented/popularized/standardized a technology. If you're Anders or Don Box, you have a position that others don't.
• You know a lot about a technology and about how people use it, what problems they have with it, etc. This is a typical MVP advantage.
• You have the first-mover advantage. You've been involved deeply early, and there are currently few people who have your level of knowledge.

That last one is really important. When C# first was released, all the publishers wanted to have C# books, and there were a number of "me too" books that weren't distinctive and didn't sell very well. But in most cases, their authors worked just as hard as the authors of the more successful books. You don't want to find yourself in that situation.

I should note that if your in the first group, you can safely ignore the first-mover consideration. You likely have enough unique insight - and likely, name recognition - that your book will sell even if it isn't first.

Do you have the time and the desire?

Deciding

So, you've done all this, but perhaps you aren't really sure whether you want to do it or not. If you're in this situation, the best thing to do is to pick a chapter of the book, and just write it. That won't take a huge amount of time, and if it's a successful experience, you'll have something you can shop around to various publishers.

Finding a Publisher

Do some research of the various publishers. Who has a line where your book would fit well? Is there a book from another publisher that you could compete against? Are there authors you can talk to about their experiences?

Narrow your choices, go to the publisher websites, and find their materials for new authors. And then contact somebody, and try to spend some time (on the phone or in person, ideally) talking about your book idea. If you go to conferences, publishers are often available to talk to there, and they may even buy you lunch.

You should expect your publisher to do a reasonable amount of marketing around your book, but you can have a large effect on sales yourself. First, if you were already involved in the appropriate community, you may be able to get others to help you do a technical review of the book. This is great both for techical quality and to have somebody else make recommendations for you.

If it doesn't seem like a conflict of interest, add a line that says "Author, "413 ways to write dangerous code" (Sams)" to the end of your signature. If people like your responses in the group, you're more likely to get a sale. Just make sure never to point people to your book instead of answering their question - that's a sure way not to get a sale.

Co-Authors

If you're going to co-author a book, you need to find somebody with a compatible writing style, compatible writing habits, and a compatible personality. You also need to decide how you will divide the royalties - is it 50/50, or is it pro-rated based on the number of pages or chapters. I haven't done this myself, but I do know of cases where there were a lot of bad feelings at the end.

Oh, and #1, you must have a compatible vision and viewpoint on how books should be structured.

For me, I find it really hard to write with somebody.

Conclusion

I hope this was useful. If there are areas you don't like, are unclear, or you still have questions, please let me know.