Catching up post-JavaOne, I was glad to have gone a bit outside my usual core Java SE track sessions on Thursday evening by attending "Writing the Next Great Java™ Technology Book." Moderated by book editor Greg Doench, the panel of distinguished authors, Brian Goetz, Josh Bloch, Kathy Sierra, and Bert Bates, gave advice ranging from why to start writing a book to how to complete one. Below are my recollections of the bof.
Brian advised to treat writing a book like running a software release, including version control over the text and code samples, as well as automated building and testing of any code. Brian's quote from Churchill,
Writing a book is an adventure. To begin with, it is a toy and an amusement; then it becomes a mistress, and then it becomes a master, and then a tyrant. The last phase is that just as you are about to be reconciled to your servitude, you kill the monster, and fling him out to the public.
certainly rang true for me in scaled down ways for some of the writing and other projects I've done. (I have many partially written blog entries, some over a year old; the toy stage doesn't last very long!) Brian also gave a warning on the scope writing a book: it will take twice as long as you think it will; there is a substantial amount of editing and revising even when the book is seemingly near completion.
Josh spoke of the importance of passion for the subject matter and knowing what you want to say. Additionally, he thought it was essential to have a diverse slate of reviewers who were representative of the book's audience; for example, one of the early readers of "Effective Java" was the teenaged son of the Java series editor. Good reviewers need a willingness to let the author know when the book is incorrect or needs improvement. To Josh, Strunk and White remains a model of clarity. He also explained how threats from family members can be a helpful motivation to finish a book!
I've read books by Brian and Josh, but I haven't read Kathy and Bert's "Head First Java," which takes a less traditional, more graphical, approach to technical writing. Bert listed a number of books, including
What the Best College Teachers Do and Efficiency in Learning, as having important insights to help manage the cognitive load of readers.
Kathy only used one slide, but had the audience do several interactive exercises, including staring down our nearest neighbor. (With our forward facing eyes, people are predators; facing down a full room of predators tickles the innate "fight or flight" response :-) She described most technical books as providing an "I suck." experience for the reader, an experience they didn't want to encourage in "Head First." Part of reducing the likelihood of suckage comes from skillfully leaving things out.
However, books should strive for a high-resolution experience; in a California-sensitive analogy, many don't regard wine as merely a binary red/white beverage.
For Kathy, a goal of a technical books is for the reader's reaction to not be about the author or the book itself, but rather the difference made to the reader.
Besides books, I think the panel's advice is useful for other forms of writing too, having strong reviewers and keeping a concern for your reader are broadly applicable, and I'll keep their suggestions in mind for my future blogging.