Why My Books are Different than Others

Since I publish the books that I write, I do whatever I want in terms of book features and layout. As a systems engineer, there are several things that annoyed me with "standard" computer books.

Since I publish the books that I write, I do whatever I want in terms of book features and layout. As a systems engineer, there are several things that annoyed me with "standard" computer books. Therefore, when I started publishing my own, I decided that my books would be different than most. Here's a list of the advantages that my books have over others, (in random order):
  1. Several other books contain many screenshots that are pointless other than taking up space and making the book thicker. (i.e. "Next, click the 'OK' button" with a picture of the "OK" button.)

  2. Some books are 7" or 7.5" wide, yet there are 1" or 1.5" inch margins. This extra white space is used to make the book appear fatter.

  3. Many books are written by multiple authors, with writing duties split by chapter. It is often apparent that they don't talk to each other, and parts of the book are repetitive.

  4. Many publishers have totally annoying "templates" that each chapter must fit into. Authors are forced to present their content in a certain way (for the publisher's "brand continuity," even when it doesn't make sense for the topic at hand.

  5. Other books have chapter summaries which basically retell the entire chapter. In my mind, these just take up space. If a reader doesn't remember what they just read, then they can flip back a few pages and reread a section.

  6. Some books claim to be about one topic, but then they spend pages and pages describing completely unrelated topics. For example, if I buy a Citrix book, I do NOT need a lesson in project management, RAID numbering, or what the OSI model is. While I agree that these are all important, they do not belong in a Citrix book.

  7. I think it's really annoying when an author spends an entire chapter explaining how technology is used, only to close the chapter with a case study that just "happens" to perfectly fit the exact situation outlined in the chapter. Case studies are cool, but only when they show real-world, tough situations whose solutions are not always obvious.

  8. There are several "design guides" where the author lists best practices for a product. The problem is that the author simply says "do it this way" instead of explaining the back-end logic as to why these best practices exist. It's not possible to educate the reader to every single potential situation for a design. Why not give them the knowledge to follow the thought process as to why certain design decisions are made? That way, they can apply the knowledge from the book to any situation—even one not covered in the book.

  9. Some computer books are nothing more that re-hashed product documentation. Even worse, some book authors "tow the company line," and regurgitate a vendor's product rhetoric. If the vendor says that a product's minimum requirement is a 200MHz Pentium, but real world experience suggests nothing less than a 700MHz Pentium, I better not find a book that says I can install it on a 200MHz Pentium. If product vendors get mad at the publishers, that's a good thing.

  10. The last thing I don't like about some "other" books is the writing style. Computer topics are usually really boring anyway, so computer books shouldn't be painful to read. I'm not talking about putting a totally lame joke on every other page. Instead, I'd rather see books that are written like people talk. Even though it's "technically" bad english, the phrase "the farm that server belongs to" sounds a lot more normal than "the farm to which that server belongs." No one talks like that, so why should books be written like that?

Dig Deeper on Desktop Virtualization



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: