When I started to write Java I/O back in September, 1997, I thought it would take me about two months and 200 pages. In fact it took me over year and a half and 600 pages, but in that year and a half I did manage to do my best work ever. A lot of the credit for that belongs to O'Reilly & Associates for letting me and other authors do good work instead of just cranking out day and date books as quickly as possible. Most computer book readers know that O'Reilly books are reliably of higher quality than the broad mass of Special Edition Teach Yourself Java in 21 Minutes for Dummies Master Reference Frankenbooks that crowd bookstore shelves, but it may not be obvious why they're better. I'd like to pull back the curtain a little and let you see how O'Reilly creates the books it does.
The most obvious reason one might guess that O'Reilly books are better is that O'Reilly works with better authors. The problem with that theory is that most of O'Reilly's authors also write for other publishers. I've written books for IDG and Prentice Hall as well as O'Reilly, but I'm much happier with the O'Reilly books. They're more complete and they've got a lot fewer mistakes. And probably because of this they sell better too. My first O'Reilly book, Java Network Programming, has outsold my other four books combined. No, I think there are two main reasons O'Reilly books stand out from the crowd:
A fine computer book, like a fine wine, requires time. It's simply not possible to write a 300 to 1200 page tome in three months and expect that it will be reasonably complete and error free. At best you can hope that the mistakes aren't too obvious or too annoying. And yet, a normal schedule for most computer books specifies that the first draft will be written in somewhere between two and four months. On that tight a schedule, there simply isn't time to get everything right. Most of the time authors simply write as fast as they possibly can with little error checking or review. If an author isn't certain about something, they have to make their best guess, write a sentence or paragraph, and move on. If an author really doesn't understand something they're supposed to write about, they'll often drop it out of the book completely rather than take the time to research it. Authors don't like to do this, but we often have no other choice.
When I was writing Java I/O, I had the time to carefully think about each sentence I wrote. If I wasn't sure about something, I could go to the library and research it. I could send email to the author of a specification or API, and ask them what they meant. And I could actually wait till they wrote me back, before I went on with the chapter. When writing Java I/O, it was not uncommon to spend an entire day doing background research just to make sure one sentence was exactly correct. If I wasn't sure if a method behaved exactly like I said it did, or if there was even the slightest bit of doubt in my head, I could spend an afternoon writing test code. Before I wrote Chapter 10, Cryptographic Streams, I took a week to do nothing but read Bruce Schneier's Applied Cryptography to make sure the fundamentals were clear in my head. I did similar amounts of preliminary research for Chapter 9, Compressing Streams, and Chapter 17, The Java Communications API. And then I took probably a month apiece to write each of those three chapters, after the background research was complete. At any other publisher, those three chapters alone would have exhausted my deadline. When you write an O'Reilly book, you get the time to do it right.
To add even more time pressure, many publishers try to perform editing simultaneously with writing. Unfortunately, the author can be so distracted trying desperately to generate the 10-20 pages of new material needed every day to meet the deadline that they can't properly review and revise what's come before. Consequently actual author review of the material is quite limited.
Author review is especially important for computer books because the editors are often English Lit majors with few to no technical credentials. These editors know how to change a sentence from passive to active voice or eliminate use of the first person, but they frequently introduce technical mistakes while doing so. And their first exposure to the topic of the book is often reading the rough manuscript, so they rarely notice the author's own technical mistakes. Most publishers hire an outside technical editor, but few are willing to pay them enough to justify a large investment of time from a highly trained professional. The result is like the old Soviet worker saying, "They pretend to pay us and we pretend to work." Though there have been a few notable exceptions, most of the technical editors on my books have offered few to no comments or corrections on the chapters they've reviewed. I wish I could say this was because the chapters were near perfect, but I'm afraid that's not the case.
O'Reilly not only provides a reasonable amount of time for author review. It also provides more technically savvy editors. Mike Loukides, the primary editor for both Java I/O and Java Network Programming, has himself written books on Fortran and other high-level-geek topics. Mike's probably found more errors in my writing than all my other editors combined. And since Mike himself well represents my target audience, when he tells me he doesn't understand something I've written, I know that I need to go back and rewrite it. When my non-O'Reilly editors tell me they don't understand something, I have to decide for myself whether they don't understand because they don't have the necessary prerequisites for the book (in which case extra explanation would only annoy my real audience) or whether they don't understand because I really haven't made myself as clear as I should.
But it's not just that O'Reilly has one particularly competent editor, and I've been lucky enough to work with him. The rest of the crew at O'Reilly is equally exceptional. Where other publishers use one technical reviewer (or perhaps two, if you can find two people who are willing to split the already small fee) O'Reilly typically uses five, who are often well-known experts in the field. When an O'Reilly copy editor finds a mistake, it's almost certainly a real mistake. While they can insert commas, and fix run-on sentences with the best of them, they can also handle details that escape most editors more accustomed to novels and non-technical works; for instance what words in a sentence like "InputStream and OutputStream are the most important classes in the java.io package." should be placed in a monospaced font. There are a lot of other people who are involved in the production of a computer book, the production department that lays out the pages, the marketing department that sells the book, the Web team, the cover designer, and more. And at O'Reilly these individuals all stand out not only for their extreme competence doing their jobs, but for their deeper understanding of the technology they're publishing books about. It may not seem like much, but working with people who really understand what you're trying to do and why you're trying to do it, makes the whole process of book production about 1000% smoother.
For authors what this all means is that O'Reilly is a hell of a lot more fun to write for, and that we can write books that we can really be proud of. Some of the biggest name authors in the IDG and Macmillan Computer Publishing stables have recently started writing books for O'Reilly instead. For readers, what this means is that you get solid books written for geeks by geeks. You get books that provide the information you really need, instead of simply whatever could be thrown together quickly enough to meet the release date of the latest Microsoft product. You get a book that has some lasting value, instead of being obsoleted by the next minor maintenance update. O'Reilly books may have a certain "geek chic" to them, but the reason they have that cachet isn't the animals on the cover. It's because they really are better books.