Why read and write tech books?(johndcook.com)
johndcook.com
Why read and write tech books?
http://www.johndcook.com/blog/2012/05/28/why-read-and-write-tech-books/
11 comments
If the Pareto principle applies to technical books, you should be able to write a 100-page version of a good 500-page technical book that still imparts 80 % of the understanding the original book did.
> The length of technical books is dictated by printing technology
You're equating books with printed material.
You're equating books with printed material.
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.
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.
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.)
(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.)
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.
By the way, I find it ironic and disappointing when O'Reilly's "nutshell" books run to 700 pages.
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.
Great examples, both. Even though Programming Pearls is a series of articles bound together, being by the same author and on a common theme makes them feel like they have a narrative running through them.
Petzold's Code is another example that I'd recommend to anyone interested in how computers work.
Petzold's Code is another example that I'd recommend to anyone interested in how computers work.
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.
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.
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.
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.
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.
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.