Writing a Book

Greg is the very famous software engineer and he wrote a article regarding wrting a book. Must read it if you are interested in writing a book, anyway.

http://pyre.third-bit.com/blog/archives/744.html

------------------------------------------

I have written three books (two on programming, one for children), and edited two others, with a third under way. I clearly need professional help must enjoy it, so here’s some advice for those of you who want to give it a whirl.

Step 1: read, and pay attention to what you’re reading. Musicians listen to their idols obsessively, and spend hours figuring out how they achieve particular effects. When I started writing popular science in the late 1980s, I tried to sound like Brian Kernighan; doing so helped me figure out how to sound more like me.

A side note: you can actually earn a little bit of money, or at least start building a professional reputation, by doing this. I review 12-15 books a year for Doctor Dobb’s Journal; the ACM and IEEE journals, developer-oriented magazines, and just about everyone else is always looking for content too. Writing down what made a book good or bad is a great aid to clarifying your thinking…

Steps 2&3: pick a topic and an audience. I don’t think you can separate these: who you’re writing for determines what you can write about, and every subject appeals to different people. You have to know your audience well in order to hit the right tone and level. Surprisingly, you don’t have to know the topic inside and out—you can pick stuff up along the way—but it had better be something you care about a lot.

Step 4: market research. People are still writing new “Java 101″ books, and each one does sell a few copies, but it’s always better to be a leader than a straggler. (Of course, the danger with trying to be a leader is that nobody follows…) Publishers always ask what books yours will be competing against, and why people would buy yours rather than those others; you should figure this out before you even block out a table of contents.

A side note: in case you hadn’t heard, the market for technical books has been in freefall for several years. People don’t buy reference books any more, they google; an increasing number don’t buy tutorials either. When you’re researching your market, make sure there’s a compelling reason for people to buy your book. Note that this doesn’t mean you can’t put it on the web for free: Joel Spolsky, Karl Fogel, and many others have done the double and made it work.

Step 5: creating the prototype. In order to take your idea to publishers, you need a two- or three-sentence pitch, that market research I was talking about a moment ago, a table of contents, and a draft chapter (not the introduction). You don’t have to worry about formatting at this stage: one-inch margins, 11-point font, space and a half, page numbers, code set in fixed width font, and all tables and figures captioned and numbered is enough to show that you’re taking it seriously.

Once you have this, give it to a few friends. Offer them wine, cookies, or babysitting in exchange for feedback. Tell them that your feelings won’t be hurt by the truth; they’ll know it’s a lie, but it’ll assuage the guilt of telling you that you’re using terms before you define them and that your examples are hard to follow.

Yet another side note: putting the chapter up on the web to get feedback is very hit and miss. If it’s the first book on a new tool whose authors want to evangelize, they’ll pile in, but they’re probably not representative of your intended audience. The best thing is probably to get feedback before you write, e.g., to teach a course on the topic, then turn your notes into a book (which is what I did with Data Crunching). This also helps when it’s time to sell the idea to publishers, and oh yeah, it means you’re getting paid for refining and improving your ideas.

Step 6: pitch it and sell it. Remember, you’re not trying to sell it to your intended readers, but to the publishers. (Self-publication is a game for fools, and not just because of the marketing and distribution headaches. Publishers have a lot more experience than you do; if they don’t think your book can make a profit, you should listen.) This step involves updating your resumé, filling in forms, and lots of waiting; use the latter to write another chapter or two, just in case.

Step 7: write the rest of the book. A printed page holds 300-500 words, depending on formatting, the amount of code, and so on. A typical book is 300-400 pages, so you have 90-200,000 words to write. On a good day, I can write 1000 words in 90 minutes, but I’m lucky to get one session that productive per day, three days a week. On average, I figure three to four hours per finished (edited, diagrammed, proof-read, etc.) page, which means a small book is 30-40 weeks of full-time work.

Step 8: production. Sending the manuscript to the publisher is like handing software off to QA—it’s a big step toward release, but not the release itself. You’ll have to read page proofs, make last-minute corrections, check the index, and a bunch of other things. Remember:

Writing is easy. All you do is stare at a blank sheet of paper until drops of blood form on your forehead.
— Gene Fowler

Step 9: marketing. You can’t just throw a book over the wall and hope for the best; if you want it to succeed, you have to follow it up with magazine articles and online interviews. Get someone to review it for Slashdot (or better yet, somewhere reputable like DDJ or Better Software), and send copies to famous bloggers (but only ones who might actually be interested—no review is better than a bad review). You want it to sell? Sell it.

Step 10: wait a year, then ask yourself what you did well, and what you should have done differently. I spent wasted almost a year writing code that no one ever used when I was working on Practical Parallel Programming; by the time I did Data Crunching, coding only took about a month, and at least half of what I wrote survived into the final book. I made other improvements along the way too, though I still have a tendency to over-parenthesize, and can’t resist ending every third paragraph with an ellipsis…

Is it worth doing? Not financially—no matter how well you write, the odds are long against you being the next Hennessy & Patterson or Eric Sink. But just like contributing to open source, it’s an effective way to build a “personal brand”, and an even better way to gauge how far you’ve come, and how much you know.