How do i write books? I was asked this via email a couple of days ago, and rather than just post the reply via email, I thought i'd reply to my weblog instead.
Writing a book is a lot like writing a computer program.
I start by creating a big list of all the information nuggets I want to include in the book. These nuggets can be low level like "what does SOAP stand for?" or high level like "include an example of .NET to J2EE interoperability". This list is usually several pages long.
Then I figure out the most natural presentation order for these nuggets, with companion examples, anecdotes, analogies and exercises to keep the reader entertained. I prefer presenting information in the way that it would normally and naturally be encountered. For example, although I might present a high-level overview of UDDI at the start of a book on web services, I would defer presenting UDDI code samples until towards the end of the book, since most developers rarely encounter the need for UDDI these days.
The chapter sequence for the book usually falls our fairly easily from the nugget sequence. In addition, I like to open a book with a personal anecdote, and end with a chapter with advanced/visionary material, because it ends the book on a thought-provoking note.
I really like small, focused examples instead of multi-page code listings. I personally find long examples that introduce more than one new concept embedded within a morass of irrelevant other code really confusing. For example, some web services books show web services being invoked from inside an applet, and the example code is 95% applet code and 5% related to web services.
My writing style is "relaxed first person", as if I was just chatting with the reader over a cup of coffee.
Before starting to type a chapter, I spend several hours in a coffee shop designing the chapter, figuring out its high level structure, sequencing its information nuggets, and sketching out the examples. This way I know how the chapter will flow and that it covers the right material. Then I write the code for the examples and make sure they include all the necessary points. Finally, I sit down at my computer and start typing.
I find the first few paragraphs are the hardest, because they set the scene for the rest of the chapter and tend to require more careful wording. The rest of the chapter tends to be more mechanical, presenting bits of information with accompanying code samples and dialog. Of course, I always find bugs in the chapter design as I'm typing, and correct them on the fly.
Every hour or so, I print out the current state of the chapter and mark it up with a pen. This is also how I write software - I am very dependent on printers and marking up software listings to accomplish a high quality end result. For some reason, I can't see the big picture efficiently on a computer screen.
I always start with chapter one of a book, which is the toughest. Once the first chapter is under way, the others come easier. I don't write the rest of the chapters in sequence. Many times I write them based on what happens to keep my interest on a particular day.
A typical chapter takes me 3 or 4 days to write, including the source code for the examples, which I think is pretty fast. In addition, the high level book structure takes about a day.
I send volunteers drafts every week or so to get feedback. Don't expect to keep everyone happy, because each person has their own preferred way of receiving technical information!
My first book attempts took much longer than my most recent. I rewrote my UNIX book three times before I was happy with it, and almost gave up in the process due to burn-out. In the end, it got good reviews, was adopted by lots of universities, and made me around $250K, so it was well worth it. My current book on web services has helped to spread our GLUE product into loads of companies, which is also very valuable to me.
I hope this information was useful to someone!
12:49:51 AM 
|
