![[dickens PIC]](dickens.jpg)
(not a) Eight Step Plan to Publishing Greatness7th July 2005, Draft no.1
I'm a first-time author, having just unleashed my wildly overweight baby, Killer Game Programming in Java, into the world. I now feel a compulsive urge to share my hard-earned nuggets of wisdom with you. In other words, I've slightly more idea about how to write a computer book than I did 3 years ago.
If you're going to write a book about X, then believe in it, really believe. Believe that it's earth-shattering, ground-breaking, urgent, and true. Don't saunter into the next few years of purgatory with the idea that X is kinda okay, or X is damn boring but will sell a ton of books. Belief will help you sell your idea to a publisher, it'll help you write, and it'll make that writing interesting.
Motivation based on making money or becoming famous just like er, er, what's his name, the BOF guy with hair, is a recipe for dark days ahead. Even a so-called best-seller will make virtually nothing when you factor in all the years it took you to write it. Making money is important; that's one of the key (perhaps the key) indicator for the publisher, but it shouldn't be so high on your list.
I said believe in the material rather than know the material. Of course, you need to know something about it, in order to write, but there's some advantages to being not-quite an expert. For example, lack of knowledge is a natural brake to stop you droning on for page after page about esoteric rubbish. The less-is-more principle should be applied to writing, unless you want to send people off to sleep. Having to learn as you write, means the material is fresh to you, and comes over that way in your writing. Problems you had understanding stuff will inform what you write.
I imagined my audience to be mostly like a geek programmer who use to bother me at work a few years ago. He'd roller-blade into my office (a hard job since I was on the second floor), and ask Java questions. He wanted to write some kind of Java game (I was never too sure what). He wanted to learn 2D and 3D graphics right now, and was prepared to spend months programming.
You need a plan of work, otherwise the mountain will turn into an avalanche. I'd like to say my plan was sophisticated, but it wasn't. A couple of sheets of chapter headings, scrawled notes on the main concepts, with estimates for how long I'd take to code and write. The headings sort of fit together into a coherent theme. This plan, suitably cleaned up, became my book proposal.
As I finished the code, I wrote a draft chapter, put it online, and told the relevant mailing lists. As a consequence, I got lots of positive feedback (which helped me keep going), some great bug fixes, and suggestions about other topics to cover. People liked the material, and an editor at O'Reilly heard about it.
The drawback, that everyone points out, is why would anyone buy a book if it's online already? There's a few answers. First, the online book contains the current code, but the draft chapters are old, in some cases over a year old. Second, most people can't be bothered printing out 1000+ pages on their laser printer, and the cost in toner and paper would probably be nearly the same as buying the book. Thirdly, the book is nicely packaged as a book, which means you can read it in bed, on the sofa, at the beach.
One of my reasons for putting the chapters online was as a public service. There's a lot of people, including most students in Thailand where I work, who can't afford to buy textbooks, especially ones on frivolous topics like gaming.
I was greatly influenced, and reassured, by the success of Thinking in Java (TIJ) by Bruce Eckel. He has an informative page about why he put TIJ online.
I contacted a few publishers before I started exposing myself (see step 4). I carefully followed their book proposal guidelines, and eagerly waited for their offers to flood in. Silence ensued.
I thought the proposal were pretty good: I'd identified a gap in the market (gaming with Java 3D), I'd included figures culled from Amazon.com about the sales for Java gaming books in the past, and I'd written a detailed book outline.
I decided the silence was due to my lack of a track record. Yes, I'd written articles about C and network programming in the 1990's for magazines like DDJ and Web Techniques, but nothing on Java. I've an academic background, but that means zilch when writing a book on gaming. Releasing the draft chapter to the world was a way of giving myself a suitable history.
Choose your publisher wisely because if you're granted the rare privilege of a contract, then you'll be hitched to these guys for some considerable time. I asked myself which publishers made books that I liked. I looked at the books they published in my book's general area (i.e. Java, graphics, gaming) to see if they had a gap that needed filling. Finally, I searched with Google to find authors' (negative) comments about their publishers.
Read any acknowledgements page, and the author will thank their families for the sacrifice they made. While you spend every evening, every weekend, every holiday, and as many working hours as you can sneak in, grinding out the book, your wife/husband will be doing those mundane chores like looking after your kids, making meals, and placing cups of tea and chocolate bars in front of you.
This commitment reminded me of my student days, but this time round it was much harder. When I was a student, I didn't have niggling little commitments like a job and family to think about.
Your masterplan for writing must include free time, or your head will turn red-hot and explode. And your spouse and kids will be none too happy either.
You get better at writing with practice: write computer magazine articles, put stuff online, and (perhaps) blog. Read some books that explain how to write, or follow the format of a book that you admire. Two great, well-written, programming books that influenced me are: The C Programming Language, by Brian Kernighan and Dennis Ritchie, and Software Tools in Pascal by Brian Kernighan and P.J. Plauger.
My own writing style (ha, ha) is to list the main ideas at the start of a chapter, include plenty of (relevant) pictures and diagrams, and keep the boooooriiiingg code to a minimum. If there's one sure sign of a stinky programming book, it's page after page after page of code listings, in an excessively large and inappropriate font.
Another aspect of writing hell is the editorial process. To paraphrase a little, my editor said on numerous occasions that a chapter was fine, except that the beginning, middle, and end needed major changes. How dare this whippersnapper have the impudence to question the sacred tablets of lore that I, an academic of white-haired authority, had kindly bestowed upon him!
Most chapters went through five or more rewrites, many of them major. And the truth is, they got better. I usually waited a day before I started on the rewrites, to allow his comments to sink in, and for the white-hot blinding rage to subside. His suggestions were right almost all the time.
The passion (i.e. arrogance, dogma) that you conjured up to write the book can work against you when the book gets seen/reviewed by others. I avoided some of these problems by putting the draft chapters online from the beginning. Technical issues and unclear writing got peer reviewed before the ideas and words became too familiar to be changed.
Your contract will probably make your editor the final arbiter of how things are explained in the book. The technical reviewers opinions should be followed as well, unless you have a iron-clad argument against them. These sorts of contractual rules can be hard to stomach.
One approach is to ask someone you trust for a second opinion. For example, I didn't like the final name of the book, Killer Game Programming in Java. But I'm not the intended audience -- the name should appeal to my roller-blading student. Since he'd long since graduated, I tried the 'killer' name, and my preferred one, Java Gaming and Graphics, out on some current student programmers. Surprise, surprise, they all liked 'killer' more.
You may want to look at some other views on this topic. I've found these articles/blogs informative, especially Scott Meyer's:
Navigation:
Dr. Andrew Davison
E-mail: ad@coe.psu.ac.th
Back to my home page