Information Management Weblog

Pragmatic Programming

I've finally gotten around to reading Andrew Hunt and David Thomas' The Pragmatic Programmer: From Journeyman to Master. I say "finally" not because it's been on my reading list for an exceedingly long time. Rather, this is a book that I should have read some time ago.

Although it is a technical book, and it does include code samples, the focus is not on a particular language or technology. This books operates on a higher plane, explaining techniques and tips that will help you become a better programmer. The effect is like that of the "master" explaining to the "journeyman" how the job should be done.

Hunt and Thomas lay out their message in a series of patterns, in the style of one of my favorite books, Christopher Alexander's A Pattern Language. The style encourages connections between patterns, a nice touch as you browse through.

Of course, I don't find everything they say to be fully relevant. The most useful, for me, are the higher-level concepts. At this point, I'm more interested in things that affect architectural decisions as opposed to patterns that are closer to the code. But, the pattern style of the book lets me cherry pick the good stuff and skim the less relevant.

I mentioned above that I wished I'd read it earlier. As I read through, I realize that I have been fortunate to pick up most of the advice from other sources. But having it packaged up like this would have been much easier. Would reading it in one fell swoop have prevented poor decisions in the past? Hard to say. Experience is still the best teacher.

I think one of the reasons I'm excited about the Ruby on Rails system is that it encourages (and sometimes forces) you into using the best practices preached by Hunt and Thomas. The system was designed explicitly to follow patterns like "Don't Repeat Yourself (DRY)" and to use the Model-Controller-View concept. The flexibility provided by, say, perl or PHP, can be great, if you know what you're doing. But, too few developers have the maturity (myself included) to do the right thing. So, you end up with code that is creaky and hard to maintain ("hacks" – using the negative connotation). I have a feeling that a Rails system, even one designed by programmer without tons of experience, will be easier to maintain and extend over the long term. At least, that's what I keep thinking every time I dive into one of the older systems in place at work…