Jan Kubr

Posts Tagged ‘andrew hunt’

A book read: The Pragmatic Programmer by Andrew Hunt and David Thomas

In Uncategorized on May 17, 2008 at 20:57

The Pragmatic Programmer is a book that will help you become a better programmer. At least that’s what the authors say in the first sentence of it. I have to say.. they are right!

First a general remark. I’ve been discussing approaches to work with anyone I could ever since I started working more than a few hours a week and even more after reading The 4-Hour Workweek. In my opinion, going to work just because you “have to” (there are bills to pay) is the saddest thing ever. What more though, if you want to feel “comfortable”; meaning you don’t want to face any major challenges, you just want to do what you usually do and don’t care much, you might very well die now. If you don’t evolve, if you don’t learn, you stand at the same place while the world is moving. And it’s moving fast these days. I warned you.

Anyways, the great thing about The Pragmatic Programmer is that not only does it challenge you to be better at your job, but it also encourages you to never stop improving. And to care. That’s probably the crucial part. If you don’t care what the results of one third of your day are, you might just very well die now. (For the second time already, too bad.)

Now the book is a bit older (2000) and the authors are not the youngest folks either, so some of the technical aspects seem to be a bit obsolete. However, that is not the main strength of the book and thus no big deal. The book is full of great tips on how to improve your skills as well as the usefulness and maintainability of the code you produce. My take-aways from these three areas:

  1. Skills (& attitude): Care about your craft, think about your work, don’t make lame excuses (provide options instead), don’t live with broken windows (fix results of bad or obsolete decisions early), be a catalyst for change, make quality a requirement, invest in your knowledge portfolio, use a single editor well, don’t blame (fix the problem instead),  organize teams around functionality, don’t use manual procedures.
  2. Usefulness: Remember the big picture, prototype to learn, don’t gather requirements – dig for them, work with a user to think like a user.
  3. Maintainability: Write code that writes code, crash early (use assertions and raise exceptions in cases when something that “should never happen” happened), minimize coupling, design using services, refactor early and often, design to test and test (or your users will), test your tests (use saboteurs), find bugs once.

There are a lot of technical tips in the book (from not mentioned ones “Don’t repeat yourself” or “Make it easy to reuse”) and although some are a bit contradictory to each other, vast majority of them is crucial and very important. Thankfully, I was taught most of them in college (fortunate to go to a good school) and thus they weren’t such a big surprise for me anymore. If you haven’t heard them yet though, read twice!

That said, there was one technical abstraction I enjoyed: the principle of orthogonality. Two lines are orthogonal if moving along one of the lines doesn’t change your position projected onto the other one (e.g. they meet at right angles). This makes it great analogy to software design: making a change to one component shouldn’t affect any other component. Although it is almost impossible to achieve 100%, I found that analogy very interesting.

The last tip in the book summarizes it for me pretty well: Sign your work! Work to be proud of your results.