I read Baron Schwartz’s recounting of his experience authoring O’Reilly’s High Performance MySQL with interest, and no little fascination. Having authored 17 computer books (or so, I begin to lose count), I can both empathize with some of the challenges he’s faced, while also wondering if I shouldn’t have been more demanding, at times. Wait a sec: I have been demanding, at times.
I worked with DocBook with one book, and didn’t really care for it. Now, I use NeoOffice, which is the Mac OS front-end to OpenOffice, but I don’t seem to have quite the same number of problems that Baron had. However, since I write only one author books now, cross-referencing issues are not as critical as they are with multiple authors.
I also have had the same editor, Simon St. Laurent, for my last several books. Having the same editor can make your job immeasurably easier. Simon knows my weaknesses and strengths and can help me minimize the first, while maximizing the second.
Tech reviewing can be a challenge, at times. Tech reviewers doing copy editing isn’t unusual, and can help, but can also hurt because what you need from tech reviewers is not for them to correct the writing— O’Reilly has copy editors to do the grammar editing—but to focus on the technology and look for errors, omissions, and problems. It’s hard, though, for people to separate the two in their mind when they tech review. They want to help.
Baron also mentions about the writing quirks like the use of passive voice. It’s almost impossible to avoid writing with passive voice when you’re writing about technology. I have this theory that tech is a left brain activity, as is the use of words, but it is the right brain that takes the medium, the words, and creatively puts them together in a pleasing, flowing whole. Since tech books force us to focus on left brain activity, our right brains are starved out of the process, and the writing becomes more an act of efficiency rather than creativity.
Well, I said it was just a theory. I use a variation of Baron’s regular expressions in order to find my own uses of passive voice, but again, I’m also dependent on both my main editor and my copy editor.
Last but not least in the writing process is the schedule. I’ve had books run the gamut from being a fast-track three months (first edition of Learning JavaScript) to almost two years (Practical RDF). I’ve found that I don’t do well with an intense, short schedule, especially with a new book series. At the same time, anything over a year is too long. Not only do you miss your publication slot, you also run the risk of book burn out. Adding Ajax and Painting the Web had optimum schedules for the book sizes and topic, and I think the less stressful schedule shows with both books.
I digress, though. Baron has provided an interesting perspective on writing a tech book, and has covered many of the issues, not to mention tasks. His recounting is invaluable, and should be required reading for every dewy-eyed author wannabe. However, I think that Baron also brought on some of the problems, himself, first by focusing too strongly on the technology used, and perhaps not having enough faith in the process, as well as other people associated with the book. Writing is work, true, but writing is also a leap of faith.
Regardless, it sounds like a good book and I look forward to reading it.
(Andy Oram, Baron’s editor, has posted a response, which is also good reading.)
(Thanks to Simon for pointing to initial story.)