But what really gets to me is the humongous number of tech books that try to teach a bit of everything at once, and fail on all counts. They're usually something like "PHP and MySQL" or "Java and Oracle" or some other combination of technologies or products, vaguely related in that they can be used together. I've been building furniture recently, so the analogy that comes to mind would be "Hammers and Wrenches: A practical guide to building chairs." (And yes, I do think of MySQL as an inappropriate tool for most jobs, though like the wrench, there's probably some convoluted way it can be used to achieve your goal.) In the case of my analogy, don't you think it'd make sense to have a few short books? "A guide to hammers", "A guide to wrenches", "A guide to making chairs"? Maybe also a few theory-oriented books such as "Working with hard woods", "Drilling", "Glues and how to use them", etc.?
I really wish we had a better set of computer-related books. Because of my education, I'm biased in favor of splitting them up as so: "Turing Machines", "Programming", "Designing", "Performance", "Interfaces", "Information", "Communication", a series of books for each programming language or set of programming languages, a series of books on using features that re-appear in various languages such as "How to use multiple-inheritance" and "How to use callbacks (to your advantage)", and then some area-specific books such as "Web sites" and "Dynamic web sites", some business-oriented books like "The medical industry", "The stock market", "Mercantilism", "Portals", etc.
Of course we can keep coming out with books such as "How to build a web-driven medical portal in Perl and PostgreSQL", and in a sense it likely makes sense economically. If someone needs to build it in PHP instead, they might have to buy two large books: the one above and another, "How to build stand-alone Windows applications for the financial market in PHP, using wxWindows and Oracle" ... and while the programmer's at it, he gets to learn how to splice the information together meaningfully. It's a good skill. Maybe we should have a book on that, "How to find and use information related to your current problem".
The main issue remains that each time something like "interfaces" is re-hashed by a different author whose main topic of interest is not the one at hand, only part of the story is told, badly, disjointedly, and confusingly. Let people who really know interfaces talk about interfaces, and let people who really know Lisp talk about Lisp. If your topic of interest neatly fits with another, tell the reader so, and let them go find their own favorite book on the subject. Maybe even write a good roadmap book to let them know what topics will be important.
But please, I'd like to stop running into so many programmers who only know one solution to any problem, and don't know there are other solutions out there, or even worse, don't care, all because at some point they picked up a book that took them from 0 to 60 along a predefined route. There's still money to be made -- people will buy a whole set of $2 books to get the sum of their information. And just think of the fun you can have color-coding the books and putting neat illustrations on the front (think O'Reilly.)
We don't need to re-explain web site terminology in every other book just to explain a source code example; we don't need to teach basic C in every other book just to get through an example demonstrating a theoretical concept. We don't need to pump business sense into someone who only cares about learning an API. Please, please break books up into useful chunks, and have each chunk written by someone who knows and cares about the subject. Sell them as a boxed set if you like, make the edges form a cool picture when collected and placed together, do whatever you like to make money ... but please, please organize the information orthogonally. (Hey, there's a good book, "Orthogonality, or how not to paint yourself and everyone else into a corner". There's even a pun.)
