A Short Story About Verbosity | Hacker News Reader

A Short Story About Verbosity

prog21.dadgum.com

82 pointsSwizec21 comments

I don't know who the publisher was, but it doesn't sound like O'Reilly. When I worked for them (in the 2000s) our mantra was that the right size for a book is however long it has to be to say what has to be said. There's a minimum length of around 120-150 pages, below which it's hard to have a visible cover on the spine, but there's no inherent benefit to 600 page books versus 250. With ebooks, of course, there's no such thing as a minimum size: it's whatever there's a market for.

In my experience, the technical books to avoid are the really fat ones with more than four authors. There is usually little coordination between authors, meaning inconsistencies, holes, repetition abounds.

At least one of the publishers thoughtfully sticks (or at least used to) the pictures of all the authors on the front cover. Finding people that have both the time and knowledge to write about a particularly in-demand technology is difficult, I had a publisher I particularly respect approach me to write about SQL Server + XML years ago and I just didn't have the time ... of course if someone asks you for "just a chapter or two" and you think you have something interesting to add (note it was never about the money, at an hourly rate it truly sucked) you might feel like contributing to a "cut & shut" as I like to think of them. Of course if you take that approach you need a really good editing team/overview which doesn't always happen.

My best guess about the "600 pages" rule is that such a length gives the book a nice, thick spine, and a nice, thick spine is a great place to plant a catchy title in enormous lettering. That probably helped when selling the book on shelves. Furthermore, length could be used as a proxy for comprehensiveness, which helped when selling the book through B2B channels, like corporations, academia, etc. (Oftentimes, such buyers were more likely to complain about what a book didn't contain than what it did, hence, the drive toward kitchen-sinkism).

All of which was great for sales back in the day, but not so great for the quality of the books.

The book Don't Make Me Think states that it is meant to be easily readable during one intercontinental flight. I think that is a good length for an introductory book.

I have read a introductory books about programming languages. Usually, all I really need is a good introduction into the syntax and a pointers to the strenghts and peculiarities of a language. All the rest I will have to figure out while programming anyways. Sadly though, this means that I will typically only read about half the book.

With the rise in popularity of ebooks, "number of pages" hopefully will come to matter less, as you'll care more about "quality of content" than "does this paper book feel thick and hefty and worth the $40+ price".

Not sure where most people stand on this, but if I buy a technical reference book, there is no way I want it to have only as a ebook format. If possible, I'd want to have both print and digital version. Unless you have multiple screens, it becomes very tedious to read the ebook and type your own code at the same time. Of course, an e-reader would help, but it's still nowhere as practical when you just want to "browse" in the contents of the book. Books are big, take space, are heavy to carry, but they have several functions that ebooks cannot replicate easily.

Technical books are overpriced?

The print edition of our book — Third-party JavaScript — sells for $45 (during a promotion it can frequently be had for much less). Besides teaching you how to properly write third-party scripts, it guides you through some pretty nasty browser quirks and bugs – issues you might not have known even existed.

If you were to encounter and debug these issues on your own, it could easily cost your firm hundreds – possibly even thousands – of dollars. At which point $45 (and the time to read the book) begins to look like a sound investment.

From the perspective of an organization, technical books are cheap.

From the perspective of an autodidact, technical books are expensive.

From the perspective of a student buying "textbooks", technical books are expensive as hell.

Considering the existence of internet, google, stackoverflow and technical blogs, technical books are silly expensive, take too long to get to the point and are borderline useless.

> technical books are silly expensive, take too long to get to the point and are borderline useless.

Hey, don't tar the whole field with the sins of 99.9% of the elements. Some technical books (those by W. Richard Stevens, K&R, Knuth, and a few others) are wonderful resources.

I mean no disrespect to Knuth, but he seems an odd choice to include in this list. Are you saying his books are exemplars of cheap, fast, or practical?

This book looks amazing! I know this might be kind of counter to your whole comment but - I'm in the army (in Israel, we do 3 years and get 100$ a month) and I just can't afford to buy it. Is there any chance I can get a free slash really really discounted copy? It's exactly the book I'm looking for!

It's not counter to my comment at all. Send me an email (ben at disqus) and I'll see what I can do.

At the very same time very small technical books aren't good either.

I mean to say small books with only facts in them, really don't help at all. They may serve well as a reference once you know everything about the subject not in general.

A good technical book is something that gives out some facts and then make you think about it. Shows you the possibilities of what can be done with the facts presented, how you can use them, and show you the far implications of the facts.

Its quite a rarity to read books like OnLisp, K&R C, Higher order Perl, The joy of clojure etc.

With e-books this shouldn't be an issue, as you can sell smaller units of product -- for example, just a chapter -- without incurring the cost of shipping, carrying excess inventory, etc. It seems the main players in the e-book market (Apple and Amazon) are sticking to a fairly conventional model but I think the industry is still open to disruption.

I dunno. I have written a couple tech book chapters in my life and tech edited a lot more books. I suspect it's not (always) the fluff much rather the fact that explaining stuff in a way that it deserves printing takes a helluva lot more than just throwing up a blogpost.

This reminds me of a quote by our friendly neighbourhood enigma, why the lucky stiff: “Attempt to search on Amazon for anything that’s a beginners’ text of, oh, let’s say the 80-page range”. As far as the Little Coder’s Predicament goes, there’s no doubt in my mind that we ought to focus on books that are as concise, fun, and immediately useful as possible. Unfortunately, the vast majority of people who already program are not concerned with the Little Coders and their plight, and thus 600-page tomes abound.

Reminded me of the quote from Blaise Pascal [1]

"..I would not have made this so long except that I do not have the leisure to make it shorter."

[1] http://answers.google.com/answers/threadview?id=177502

Well, not for long. You can find many books here. The site is slow as molasses, but the selection is very good.

http://en.bookfi.org/

I'm on a 3G connection currently (in southern England), and the site loads and searches instantly. Nice find, thanks.

"I don't mean in the vague sense of sitting in a coffeeshop with my laptop and pretending to be a writer."

Yes, that definitely was not vague.

Reply on news.ycombinator.com