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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
21 comments
[ 3.9 ms ] story [ 54.0 ms ] threadThe 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 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.
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.
http://en.bookfi.org/
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.
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.
Yes, that definitely was not vague.
All of which was great for sales back in the day, but not so great for the quality of the books.
"..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