
Why read and write tech books? - michael_fine
http://www.johndcook.com/blog/2012/05/28/why-read-and-write-tech-books/
======
rsaarelm
The point about a specifically authored narrative leading to a deeper
understanding is a good one, but what about the suitable length for that
narrative? The length of technical books is dictated by printing technology
and market pressure (people think they get their money's worth if the book
looks thick), not by what's the least amount of pages that can impart the most
understanding.

Technical books are generally divided into chapters somewhere around 30 pages
in length. This is also in the ballpark of the length of most standalone
technical articles. So the book can be thought of as a series of shorter
articles that form an overarching narrative, even if it's by a single author.

I wonder if things can go even more concise from the 30 page article form, and
still maintain the property of being pleasant to read, easy to learn from and
imparting a deeper understanding through a narrative going through multiple
chapters. We are still bad at using proper hypertext for long-lasting useful
and serious writing compared to the conventions in writing for print.

~~~
nailer
> The length of technical books is dictated by printing technology

You're equating books with printed material.

~~~
rsaarelm
The equation is pretty much built into the connotations of the word as it's
currently used. Documents called "articles", "reports", "wikis" or "blogs"
don't create the expectation of potentially being printed and bound like
documents called "books" do, even if all of them are being viewed using a web
browser.

This is most likely going to change, but we don't seem to be there yet. It
might even be that the word "book" just can't shake off the print connotation,
and will end up going the way of "folio" and "vellum" as an obsolete format-
specific word when printed books start becoming curiosities.

------
FreakLegion
Petzold is absolutely right (and his _Programming Windows_ is still a
fantastic resource). It's just that not all technical books live up to the
high bar he's set for them. Most technical books are JATBs ("Just Another
Technical Book"), but every once in a while we get a _Learn You a Haskell_ or
_Eloquent JavaScript_. It's the same with every kind of book: a few gems
hidden in a mound of trash.

(Also re: rsaarelm's comment, the two books I mention above were available for
free online long before anyone gave a thought to publishing them. Their length
is in no way dictated by printing technology or market pressure.)

~~~
johndcook
A couple more gems: Douglas Crockford's _JavaScript: The Good Parts_ and Jon
Bentley's _Programming Pearls_.

By the way, I find it ironic and disappointing when O'Reilly's "nutshell"
books run to 700 pages.

~~~
minikomi
I also think The two I'm currently reading together at the moment are both
really nice examples of tech books with a narrative - _The Joy of Clojure_ and
_The Little Schemer_.

------
glimcat
A somewhat mercenary perspective:

There is always new tech coming out. Tech workers have a perception that they
must be up on the newest tech in order to remain valuable. Halfway decent tech
books therefore sell like candy in a continuously renewed market. You also
establish yourself as an authority on the newest tech, increasing your own
perceived value.

------
chj
Bought the consumer preview edition. Love the writing style.

The challenge nowadays for tech writers is people become impatient, they can't
sit there and wait for you to tell the whole story. They simply jump. So it
would be better that the book is narrative and also jump-friendly.

------
pagejim
What if an app is able to collect all the relevant information about a subject
and is able to produce a book. We arent very far away from that happening.

