A recent remark in a LinkedIn.com forum stated “Please do not use Microsoft Press and “Technical Editing” in the same sentence. Have you ever seen the 1st editions of the Technical books?”
I believe that the general thrust of the statement was that the technical editing done for first editions of Microsoft Press technical books did not do the job in terms of eliminating errors in the text before publication. Further comment then ensued that books from other publishers were better able to explain Microsoft’s own products, offered better coverage of topics, and were more up to date with the technology. All of this may be true and it’s certain that the quality of books can suffer due to many factors. It is also true that different publishers and different authors can combine at times to generate the best possible book on a specific technology.
I responded that my experience with Microsoft Press has been good. In my view, Microsoft Press has certainly dedicated sufficient editing resources to my Microsoft Exchange Server 2010 Inside Out book to allow the team that has worked on the book to drive to a high quality output. Of course, I would say that and we’ll see the result over time, but I hold to the view that Microsoft Press has assigned the right amount of resources in terms of technical editing, copy editing, indexing, and overall publication direction to do a good job. I hope that this first edition does not suffer from the problems reportedly seen in other books!
Thinking about the question a little more, I conclude that the overall quality of any technical book is influenced by many different factors, including:
- The level of knowledge of the author (obviously!) and the technical editor about the topic covered in the book. Clearly any errors in the text are more likely to be caught if both the author and technical editor work together well and share a common understanding of the technology. Mutual respect is important here because a good technical editor will pose questions for the author based on what they find in the text and often these questions expose issues that deserve to be covered. An author who becomes exasperated by the feedback of their technical editor isn’t taking advantage of this most valuable resource.
- The speed that the book appears after the product being covered. Books that appear very soon after software is released are far more likely to contain errors than those that appear months afterwards, simply because it is the nature of software that bugs are fixed and functionality might be removed or added very late in the development cycle. For example, Exchange 2010 SP1 changed late on to remove a new feature aimed to make management of cross-site connections easier; it also changed to retain moved mailboxes in source databases instead of the RTM behaviour of deleting the source after successful moves. If an author had committed text to a book just before the software was released they would have zero chance of catching changes like this and so their text is likely to be inaccurate and could be misleading. Is that the fault of the author, the technical editor, the copy editor, or the development group – or just the way that things work?
- The access that the author enjoys to the product development group. If he or she has good access so that questions can be posed and answered by an authoritative source, the resulting text is usually better and more insightful than if the author has to rely on product documentation, development group blogs, and other resources – good as though these might be.
- The maturity of the software product being described. If software is in a V1.0 state, the books that describe the software are more likely to be a V1.0 state too because the author, the technical editor, and probably the development group don’t have the same level of understanding as exists when a product has been in the market for a while, has been tested and deployed by many installations, and has been well analyzed by IT professionals.
- The knowledge that the copy editor possesses about the topic. A good copy editor is able to spot mistakes based on their knowledge and experience and that’s very helpful to an author. It may just be a mistake where a word is missing, or it may be something critical like “I don’t understand this text and it doesn’t make sense when compared to what you wrote in the last chapter…” A bad copy editor misses stuff like this and concentrates on the pedantic side of the job, such as chastising authors for not using correct product names (how many times have I been told that it’s “Windows PowerShell” and not just “PowerShell”) or that I have to spell out acronyms ad nausem ( I think most people who read my Exchange books understand that EMC means the Exchange Management Console, but some copy editors like me to define this term in every chapter).
- The ability of the publishing team to handle last minute changes. Personally speaking, I love to be able to make late changes in a book because it reflects reality. We live in an ever-changing world with so many sources of information that new and interesting items are bound to come to our attention all the time. It’s frustrating for an author when you’re told that a late change can’t be made even if it seems to you that it’s pretty important because it adds value to the text or addresses a concern raised in a chapter. Bad publishing teams stay focused on questions like page count, page layout, indexes, and all the important stuff that surrounds the publication of a book and forget that people buy and read books for the content.
- Access to different computing environments. The best description of how a technology works in a particular environment comes from observation of how it actually works in that environment. It therefore follows that if an author has access to a variety of computing platforms and situations, they will better understand how a product works in those environments. I don’t have the resources to create a sixteen-member Database Availability Group that supports four hundred database copies and 64,000 real live mailboxes, so my knowledge on the daily operational concerns raised in such an environment is weak; my lifetime experience of large computing installations gives me some data to fall back on but nothing makes up for the real thing.
- Time pressure to get the book out. A publisher can either let an author get on with the job of writing the best possible book they can create on a topic or they can hold to a schedule that is often arbitrary and sometimes impossible. The publishers that like schedules are often focused on selling seasons (do geeks buy technical books to give to each other for Christmas?) or on beating other publishers to the market with the first book on a product (in which case they run into the problem described in my second bullet). A publisher has to keep a certain amount of pressure on an author else the job would never get done, but the best publishers do it with subtlety and wisdom and protect authors from the tyranny of the calendar as best they can.
So there you are – the complete guide to understanding how a good technical book gets to be published in eight bullets.
Getting back to the topic in hand, I’m impressed at how Microsoft Press go about their business and I know that the same level of investment does not exist in other publishing houses and you can see it in the quality of their titles. The final judgment will be passed by readers… and you all have a vote.