Wednesday, April 30, 2008

On Reading Programming Books

OK it's an over done topic. I just happen to think that there really is a market for well written books on technical subjects. This post was prompted by a blog entry by Jeff Atwood on his blog Coding Horror Programmers Don't Read Books -- But You Should. Referenced in this article is another of his posts Do Not Buy This Book. This article talks more specifically about what Jeff considers to be worth while programming books. In it, Jeff poses this question, "Do highly technical books tied to a specific technology have any reason to exist in an era of ubiquitous, high speed internet access?" And goes on to explain why he does not believe so. Many of his arguments are valid and make sense.

But I don't completely agree. I do not believe that all technical books can be replaced by the internet. One reason I still find well written books incredibly useful is for thorough coverage of large concepts. A well written book (let us just assume I am talking about well written books going forward unless I say otherwise) logically organizes large amounts of information in a manner that is easy to read and digest. In this day of short attention spans and even shorter internet content to fit those attention spans I find this very important.

Maybe if you diligently read many blogs and decipher and internalize many of the examples on a subject you will eventually gain all the same information you would from a book. But due to the brevity of most blogs or articles online, they do not have the in depth information necessary for a reader to fully grok more complex situations. Also, connecting and de-duplicating all the information in multiple blogs and articles as well as all the different third-party examples is an additional exercise in data management and collation. And who has the time to read all those different sources in the first place. Why bother?

One way or another (book or blog) you need to bother or important concepts can be missed and everything ends up looking like a problem for the few solutions you have uncovered. The worst part is, you might not know what you missed. I have run into this phenomenon several times now. The most recent example involved the ASP.NET AJAX framework. For a number of months, a few of the developers on our team were working with the framework. I was a bit confused when I looked at the code because every piece of client side code had been implemented as an instance of a single type (Sys.UI.Behavior) when there were three to choose from (Sys.UI.Control and Sys.Component being the others). I was also confused because, when compared to winforms, it seemed to be the wrong type to use. I mentioned this, but did not argue too much. They had done far more work with javascript than I had and so I trusted them. In the end though, the solution was over-engineered and difficult to maintain.

This probably happened because the developers almost went out of their way to not read a book on the subject even though it was suggested several times. They were already familiar with javascript behaviors from other libraries and instead of reading about the new framework simply Googled to determine how to hook up behaviors to the ASP.NET server side code. A few blogs on the subject were occasionally skimmed. Even the ASP.NET documentation was consulted and the information found there was shoehorned into their view of how things worked. The general javascript behavior concept was confused for Sys.UI.Behavior and hijinks ensued. I have emails where developers made assumptions about the framework that were flatly contradicted in parts of the documentation not consulted.

However, another one of our developers read a book and suggested it frequently to no immediate avail. It will not be a timeless tome as it is tied to a specific technology (ASP.NET AJAX). But I would still declare the book a great print book and one definitely worth reading if you are working with this particular technology; ASP.NET AJAX in Action is the title. I read this book shortly after it was brought to my attention. The other developer who read the book and I understood enough to write a feature similar to the over-engineered one in less time. Our feature has fewer bugs and is easier to maintain. Bugs that are found take much less time to fix. Why? Because we read a good book on the subject. We had a much more thorough understanding of the concepts involved and were able to create a solution that better utilized the framework. And we spent less time researching the material by reading the book and following up on the web then the original developers spent on Google, Code Project and their prototypes.

I'm not going to say that this information couldn't have been found on the internet. But I will say that a good technical book can still be a time saver in the long run. A good book can expedite the learning process by consolidating and de-duplicating the information needed to comprehend complex subjects into passages and examples that flow from one to the next. I have yet to find the blog or other free online format that can cover larger topics in an easy to understand yet effective way.