Part III. In defense of books
By Douglas Reilly
Software developers constantly need to learn about new technologies, products and methodologies. Think about what sort of programming you were doing 5 or 10 years ago. If you have been developing software that long, you will, no doubt, be working on very different systems now than you were then. Five years ago, I was using classic Active Server Pages (ASP) and VBScript to develop Web pages for a dotcom company. Today, I work primarily on ASP.NET using C#, with the occasional Windows Forms program thrown in for good measure. Moving from classic ASP to ASP.NET meant changing a lot more than just the programming language. ASP was a markup-oriented technology, involving lots of messing with detailed markup, whereas ASP.NET is a control-oriented technology that allows for RAD development – even more so, now that ASP.NET 2.0 is out.
The question is: How do you keep your skills current? How will you prepare yourself for what you will be doing 5 years from now? In part I of this series, I explored the value of conferences and in part II technical forums. Here, I move on to discuss books and the role they can play in keeping the developer up to date.
Why a Book?
In this Internet age, where every kind of information can be delivered to your screen at the click of a Google button, much has been written about the imminent demise of the traditional book. However, for me and many like me, books continue to be a vital source of learning. Now, in the interests of complete disclosure, I should mention that I have a vested interest in software development books. Figure 1 shows the “shrine” in my living room, a stack of the five books that I have written (four as a solo author, one as a co-author).
Figure 1: The Book Shrine
Figure 2 shows some of the bookcases in my basement office. I shelve my books in what my wife calls “The Dougie Decimal System”, a system where books are shelved in general categories, starting with ASP and ASP.NET, then VB and C#, followed by Database topics and so on, ending with Windows system books.
Figure 2: The Dougie Decimal bookcase
In short, I have a lot of books. I love books. Books have been very good to me, both as an author and as a reader. Now, don’t get me wrong; as an author, I have never been tempted to give up my day job. I do not think that the author’s cut of the royalty on today’s programming/development book (usually 10% of net revenue, which equates to about 5% of the price of the book, or about $2-2.5 per book sold) comes close to covering his or her time. That said, writing a book has gotten me through a lot of doors that might not otherwise have been open for me.
Over the following sections, I’ll describe what I consider the primary advantages of books as a learning resource, and then examine some of the commonly-raised objections to their use.
Books are tangible and relatively permanent
There are a number of reasons why books are not obsolete, even in this Internet age. The first reason is that, unlike online resources, which can be here today and gone tomorrow, a book gives you a concrete source of information, one that will be available to you as long as you can find the shelf space for the book. How many times have you remembered a blog entry or forum entry somewhere that solved a problem that you are now facing, then been unable to find the page again? Even with Google, this has happened to me more times than I care to recall. When I remember reading about a topic in a book, I seldom have a problem locating the specific book that contained the solution (especially with “The Dougie Decimal System” in place).
Books are generally authoritative
While you can certainly find exceptions, my experience is that most books are reasonably well written and well researched. By the time a book comes to market at least three or four people, both technical and language editors, have worked through the book. I have performed technical reviews for a number of books and, in some cases I was one of half a dozen people performing the same role. Some publishers are much better than others, and certainly you should let your experience be your guide. Poorly written and technically bogus blog and forum posts are not terribly common but there are still some bad examples out there. Books, on the other hand, are seldom completely off topic.
Can you imagine a classic book like The Mythical Man-Month by Fred Brooks appearing on the web? How about the 900-page Code Complete by Steve McConnell? If you are a developer and have not read these books, you should run, not walk, to the nearest bookstore.
Books can be read anywhere
As you can imagine from my recent article, Coming out as a Cancer Survivor: A Guide for Software Developers, I have spent a great deal of time in doctors’ offices and hospitals. I go to one of the finest hospitals for my disease in the whole world. The care is excellent, and they have kept me alive and relatively well for longer than I have any right to expect. That said, they very often keep you waiting. I have turned a liability (wasted time waiting for doctors) into a positive, and always bring one or more books with me, so that I have something to read while I am waiting.
These days, the Internet can be read almost anywhere, as well. However, today’s monitors, wonderful as they are, are no substitute for the printed page. When I edit my own book or other people’s books, I often find myself printing out a chapter at a time to edit on paper. There is something about the printed page that the display has not duplicated just yet. This is especially true for mobile devices, like notebooks and PDAs.
Books give you the “Big Picture”
When SQL Server 2005 became available, the magnitude of the change from SQL Server 2000 became apparent. Getting a good book on the new product helped me learn much of what I needed to know about it.
What about new technologies? When I needed to understand Service Oriented Architecture, or Refactoring, I looked at some blogs and other online resources, but I learned most from the various books I read.
When you need to learn a new technology in depth, books also offer more detail than you are likely to be able to find conveniently on the Web. For instance, my recent Web Forms introductory book puts together information on ASP.NET, HTML and Cascading Style Sheets (CSS). Even a relatively short book contains a lot more information than a Web article.
Objections to books
Given all these stated advantages of books, it is a bit surprising that according to a recent poll on Programmers Heaven, about 70% of programmers have less than 20 books on programming, including around 20% who have 3 or fewer books. Why is that?
“Books are expensive”
Lots of developers feel that books are expensive. As an author, and someone who has tech-edited a number of books, I can tell you that there is a lot of work involved in getting a book from the initial author idea into your local bookstore. Furthermore, there are a number of websites that sell developer books at fairly substantial discounts. I have used Amazon.com, bn.com and Bookpool.com and, other than an occasional wrong book or folded cover (folded covers make me crazy), I have had great success. I also try to purchase a number of my books from my local bookstore, since I want to keep them around. Some books, by a well-known author or publisher, I trust and will buy sight unseen but, for many books, seeing the book at the bookstore is essential.
How much time does a book need to save you in order to be worthwhile? Given my billing rate, if I save a client an hour’s time by buying a book, I have saved that client quite a bit more than the $50 or so it might have cost. Even if I only use a couple of chapters in the book (and I have a number of books where I have used two chapters or less), it is worth having the book if it saves me time or gets me into new technologies that I need to use.
“I don’t have time to read books”
Not every developer book is designed to be read cover-to-cover. Some are more appropriate for use as a reference book. Reading a chapter or two, or even portions of a chapter, might be sufficient if you are trying to perform some task that the book describes. As Tom Kyte notes in a recent blog, you have to find time to learn this stuff. With software becoming ever more sophisticated and more and more tasks becoming automated, you have to find the time to acquire the knowledge that will continue to make you valuable to your employer. If you are a developer, and you want to keep up to date in the long term, books are essential.
“Books aren’t portable”
This is a genuine compliant that you here from many people – especially consultants who have to travel widely: it’s simply too cumbersome to drag a couple of bricks worth of book around with you.
However, Sites like O’Reilly’s Safari site (http://safari.oreilly.com/), as well as a number of the traditional book-selling sites, offer electronic versions of books. Given modern technology, an electronic version of a book might be ready a month or so earlier than it might arrive on the local bookshelf. Often, these electronic books have gone through the same review and editing process that traditional hard copy books go through.
“Technology changes too fast for books to keep up”
Books are now completed faster than ever before. The time between signing my contract and delivering the last chapter of my latest book was only about three and a half months. My first book (written about 10 years ago) was about a year from contract signing to delivery. Publishers also try to keep content up to date, so that when you buy a book based upon one version of a product, updates are often made available, especially if you are purchasing a book based on a beta product.
Secondly, you can avoid technical obsolescence by choosing timeless books, such as The Mythical Man-Month by Fred Brooks, Code Complete by Steve McConnell, or Patterns of Enterprise Application Architecture by Martin Fowler. These books were great two years ago, and will be great five years from now.
How to select a book
There are a number of ways to determine if a book is right for you. If you are looking for a book to help you accomplish a specific task, a scan the table of contents (or, better still, the index) will let you know quickly if the author is even attempting to address your issue. Often, the table of contents and index will be available online at a store like Amazon.
Sample chapters are another useful way to see if a particular book is for you. You can get a sense of the writing style of the author, as well as how content is covered. Is there lots of code? No code? Does the author bring to the topic a sense of humor that you enjoy?
I cautiously encourage you to assess Amazon reviews. Of all the book sites, Amazon continues to have more book reviews than any other online book seller. Don’t just focus on the star rating, read the actual reviews, and possibly other reviews by the same reviewer. I tend to treat five start reviews posted a few days after the book’s release with a degree of skepticism. Amazon reviews often seem to be related as much to the networking skills of the author, and the enthusiasm of his or her friends and family, as they do to the quality of the book (I have completely avoided requesting reviews for my books). That said, a book that has 20 reviews and averages 5 stars is likely to be pretty good.
Your career is your business. While it would be nice if your employer would cater to your career development needs, the fact is that most employers do not. Books present an effective means of advancing your current skills, and learning new ones, with a relatively low cost of entry. Even if you only pick up only one book a month, I think most developers will find this a very good investment.