I would like Tech Books to be like this

I just received my copy of Using the HTML5 Filesystem API by Eric Bidelman and wanted to use it as an example of how I would like Tech Books to be:

This book is specialized and concise. As you might see from the image, it comes it an well under 100 Pages and covers exactly one topic.

I have only very limited time compared to the amount of technology that’s out there. The Web is evolving so fast, it’s hard to keep up with new developments. Information is scattered in blog posts, and it’s often hard to just find a cohesive front-to-back tutorial. Also, even though I own both a Kindle and an iPad, I prefer my books to be on dead trees.

Tech Books are often massive, 500 to 1000 page compendiums, and there are cases when it’s necessary. If you read the .net Specification, the C# Language Specification or David Flanagan’s excellent JavaScript: The Definitive Guide, it’s hard to get these under 500 pages, and that’s okay because they are compendiums about an entire language.

However, way too often I see books that have a lot of text but very little information. One of my Pet Peeves is the Introduction and Installation section. Many Web Books start with a 50 page history of the Internet, from CERN to HTML5, how the internet has revolutionized the world and what great things lie in front of us. Sorry, if I really want to know about the history of the Internet, I hit up Wikipedia, just like the book author likely did when researching. The only interesting piece of History is the motivation behind a technology, answered by asking two questions: What Problem did the creator of a technology run into, and how is this technology attempting to solve it?

Same for the installation Section. I don’t need a 20 Page installation that’s outdated anyway when the book comes out, Give us the official Project Website and maybe a few gotchas, but we can take it from there.

Being able to read a book in an evening is a huge win because it already plants knowledge into our brain about what’s available. I might not have immediate need for a technology, but knowing what and how it does stuff means that the next time I run into a technical problem, I might think “Hey, I can use X to solve that!”.

The HTML5 Filesystem API book does just that. It has a small Intro and dives right into code examples. The API is simple, yet does introduce new objects into JavaScript. There is no example application per se (One could think that building an Address Book with uploadable Photos would be cool), presumably because it would take the focus away from the core. The code builds on top of each other though, from the creation of a file system to adding, deleting, uploading and remote getting files.

In fact, this book is good for another point: Tech Books are usually behind the applications they release. When a technology comes out, the early books are usually garbage, based on Beta/Prerelease versions with code examples that are slightly broken because RTM changed stuff. They don’t have many real world usage scenarios, often cover too much too shallow. This is even worse when the technology is an update (e.g., ASP.net MVC 3) and the early books are just previously released books (e.g., for ASP.net MVC 2) updated with some new features rather than redoing the entire book front to end with the new technology in mind.

The later books are usually too late – by the time they come out, the successor technology has already been announced, and people gained knowledge through blog posting, cursing at how bad the technology is documented.

Tech Books remind me a lot of Waterfall development, in that they simply take way too long to come to the market and don’t meet the needs of the customers. Writing a 500+ page tome simply takes time.

The agile version of that is what the above book demonstrates: The technology it’s discussing isn’t even out yet and may change, a fact that’s clearly stated in the book. However, because it’s only 80 or so pages, it’s quick to write and gives the reader enough knowledge about all aspects of the API, so that eventual changes should be fairly trivial to do (Eric also includes the link to the W3C Spec, so you can stay up to date). But even if they completely throw away and redo the API, it only wasted a small amount of my time – and my money. The book is $20 (cheaper on Amazon right now), so it’s not a massive investment at all, especially if I would calculate the time it would take me to scour through scattered blog postings as billable time.

Another great example is The Node Beginner Book. It’s cheap ($5), comes in at about 60 pages, is cohesive and available right now (compared to some books that are scheduled to come out in 4 months or more). CoffeeScript: Accelerated JavaScript Development is another excellent one. I heard that the Nuget folks are considering a book as well, and I would love to just get a book that covers how Nuget works internally, how the Server was written and how to interact with the Visual Studio plugin. Sure, I can look at the source code, but again, a concise and cohesive overview with samples and a reference part is all that’s really needed.

Some other books I would totally buy: Model Binding and Validation in ASP.net MVC 3/4, RESTFul WCF Applications, Ways to send data from the Server to a browser (From COMET and setInterval/JSONP crutches to Web Sockets and Server Side Events), Writing an ORM from Scratch.