Why Johnny Coder Doesn't Read

I ran across a blog post today about how most software developers don't read. This is noteworthy because the technology for writing software innovates at a very high rate. How can today's coders keep up if they don't read about new technology? The article conflicts itself about whether or not developers learn about new technology online instead of through books. The major reason given as to why coders don't read books is the lack of quality in the content of the books being published. The author then gives some recommendations for books that he believes coders should read.

I totally agree on the quality issue. Most books on writing software simply stink. They are all about screen shots and "click here, type this" descriptions from the lowest paid geek that the publishing house can find. There are some good books out there written by quality writers but they are in the minority.

Quality isn't the only reason why coders don't read books. Economics is another. The fast pace of innovation dramatically reduces the shelf life of most books on programming that are specific to a particular technology. Microsoft produces a major release of .NET about once every year. Sun Microsystems releases a major release of Java about every two years. The corresponding after market books go for $50 to $75 (USD) a pop. Add to that the fact that the project you are working on most probably won't be able to upgrade to the new version and you quickly find yourself coming to the conclusion that purchasing these books don't have a good ROI.

Another reason why programming books aren't being read by coders is learning modality. Everyone has different experiences which affect how they learn. So, everyone learns differently. What order that facts are presented in a teaching environment affects learning efficacy on a per student basis. Books can't change the order that facts are presented but web sites can because the reader interacts with the content in his or her navigation choices. Obviously, the traditional classroom setting is also sufficiently interactive enough such that a good teacher can get the message across to his motivated students effectively.

I totally agree with the author's book recommendations. Those are some great books to read. You will be a better coder for reading them. In addition to these, permit me to recommend a few more. You may not be a C coder but do read Kernighan and Pike's The Practice of Programming which gives you a great taste for the craft of writing quality code. Most business level development these days is object oriented. If you do anything even similar to object oriented programming, then you owe it to yourself and your employer to read Design Patterns by Gamma, Helm, Johnson, and Vlissides (a.k.a GoF). These two books have a very long shelf life.

Why don't I recommend more books than these? Because, like I said before, people are different. Different strokes for different folks. The book that really does it for me may not work for you. So, get thee to the bookstore (physical or virtual) and leaf through what is available. Look at the writer's style. Pick a topic of interest from the table of contents and read the introductory paragraph. Rinse and repeat until you find the book that you feel is the most lucid and educational for you.

You may be unclear as to what topics that you should be reading about. Well, most modern business application developers should be interested in data access. It is very likely that you will be coding web applications so you should be quite hip to the following standards; HTTP, HTML, SOAP, and CSS. Another interesting platform neutral topic is AOP.

As far as platform specific reading, again, find the right book for you. Looking over my own bookshelf, I can't help but notice the following publishers keep appearing over and over again; O'Reilly, Addison Wesley, Apress, and Prentice Hall Professional. Not a lot here from Wrox or SAMS to be honest. I'm on the fence with IDG, Manning and McGraw Hill. I only have two books from New Riders but they are both good.

Software architects need to go the extra distance to read about competing platforms. Why? How can you make the right choice if you aren't aware of the alternatives? If you don't like to read, then don't become a software architect. Go here for a good list of buzzwords to start your reading list with.

The Human Hive Mind

No, this isn't a blog about the borg. Recently, I ran across an article or two on how products such as delver and twine use social networking APIs and semantic web standards to make search results more intelligent. The idea here is that you pick friends based on what you have in common with them. In which case, it stands to reason that what they think as relevant is a reasonable determinant for what you think is relevant.

This is an offshoot on what is more commonly known as collective intelligence. I first ran across this on the web with the google search engine which capitalizes on the science of predictive markets to provide those miraculously relevant search results at the top of the screen. Books such as the Cluetrain Manifesto and Wikinomics predict and expound on the power and inevitability of collective intelligence and the web, where physical proximity has no affect on cost, as a most excellent way of catalyzing collective intelligence.

April 28 Update: I ran across an article recently called Gin, Television, and Social Surplus that presented a different and interesting take on collective intelligence. The author based this on a speech that he gave at a recent conference on Web 2.0 technology and cultural impact. His upshot it this. One place to go looking for collective intelligence is to siphon off a little bit of the enormous amount of time that people spend watching television.

Cell Phones and the World Wide Wireless Web

I recently ran across an article on the Ten Most Disruptive Technology Combinations which included the combination of cell phones and wireless internet access as the number one combination. The article mentions how this convergence blurs the lines between work and play and that is forcing telecom monopolies to open up their networks.

Within the past year, I upgraded my cell phone which included an Internet package. I thought that I would cancel the package pretty soon but I am still willing to pay $20 per month per phone for the privilege of unlimited web and email. I must admit that this is a compelling technology.

So, compelling that I added a mobile edition to my online publication about what affects that technology and the media have on culture.

Authoring web pages for mobile devices is sort of a Back to the Future experience for me. It's all about a small download to a device with limited interactive capabilities. The version of HTML is hyper modern but there are a lot of elements that you cannot or should not use including script, tables, and images. You should also limit links to the navigation within your site.

Summer Update: I have started a new technology company which also includes a mobile edition.

Say a Little Prayer for the Semantic Web

Earlier, I had blogged about SPARQL. The feedback I got was along the lines of asking why I was bothering about that since RDF never really took off. Well, it is true that adoption of RDF is pretty weak. I guess that means the semantic web is not really ready for the main stream yet.

Too bad, really, because the problem that RDF was invented to solve is both interesting and compelling. It is the problem of context sensitive search. Wouldn't it be nice if you could write a search query that differentiates between Huckabee the politician, the store chain, or the movie? Maybe this problem isn't serious enough to bother with the trouble of authoring anything as onerous as an RDF document because google is already doing some special parsing tricks to provide some pre-canned context sensitivity. For example, if you google movie: Huckabee, then you see only movie reviews with the word Huckabee in them. That's not exactly what was wanted but it is closer. You can do similar stuff with define: and stocks: but this is not a complete solution to the problem of context sensitive search. In the world of google these are called search operators.

But perhaps it is still premature to declare RDF as dead. The CEO for the Reuters news agency has talked up RDF in a recent interview. They have even introduced a cool tool for generating RDF from textual content. There's nothing like a cool tool to generate traction in the world of protocol adoption. However, this tool still has a little ways to go before it is going to be of much use. I pointed the tool at another blog entry of mine (Data Access Strategies), just to see what it would do.

What it generated could do little more than identify the following from the article as industry terms; web application server, web application development framework, ruby utilities, django utilities, rapid web application development, business application software development, operational systems, and web application developer frameworks. Not very intelligent, eh? It did correctly identify Martin Fowler as a person but incorrectly identified VB.NET as a company. To give you a basis for comparison, I went to the bother of authoring an RDF of that article myself. That document won't do you much good unless you are comfortable with RDF or have an RDF editor. As I hinted at before, RDF is kind of complicated. Here is a picture of what that RDF looks like when viewed as a resource graph.



Here is a PDF of the graphical version generated by RDF Gravity.

Here's hoping that Reuters continues to work on making this tool better. There is also a recently published extension to the very popular RSS format that allows you to add more context sensitive tags to your site maps. Here's hoping that takes off too.

Accessing Data with Some SPARQL

It looks like the W3C has promoted SPARQL to that of a standard. The SPARQL Protocol and RDF Query Language is another "SQL on steroids" that allows you to query RDF documents.

This news is the latest in what seems to be a growing trend to extend or enhance SQL to work against non-relational databases. There is a long history of success in embedding or calling SQL from business software applications as an effective means of accessing data. Using the same pattern with an enhanced SQL for non-relational data seems to be very promising. There are competing patterns that are also emerging where the SQL is generated under the covers and not by the application developer at all. I have blogged on this in a larger article documenting trends in data access strategies for software developers.