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
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
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.
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.
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
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.
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.
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.
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.
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.
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?
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.