The Pragmatic Programmer

A review by Andrew Forward, of Andy Hunt and David Thomas' book on software programming

The Pragmatic Programmer - a forward from A. Forward


Andy Hunt and Dave Thomas started the pragmatic trend with this book, The Pragmatic Programmer. This book is a must read, must own, must review, must re-review book. The comprehensive review found in this article will summarize all 70 of Dave and Andy's tips - as well as review a few key concepts from the book.


If you are looking to skim this information, simply follow the shaded boxes to learn Dave and Andy's 70 tips for pragmatic programming. For a thorough review of several key topics in the book, please read from head-to-foot including the shaded gems. Finally, if you want more examples, more advice, more words from the author then you can simply buy the book.


Software Entropy

From physics, entropy refers to the amount of disorder in a system. In software, the same is true. The broken window concept, used to clean up crime in New York, is an interesting and compelling theory that says to keep free and clear of the big issues you need to focus your efforts on the small things. By leaving in the little things (poor code, bad design, ...) you open the door for bigger and harder to fix problems.

TIP 1 Care about your craft
TIP 2 Think! About your work
TIP 3 Provide options, don't make lame excuses
TIP 4 Don't live with broken windows
TIP 5 Be a catalyst for change
TIP 6 Remember the big picture
TIP 7 Make quality a requirements issue

Good-Enough Software

Good enough for your users, for future maintainers, for peace of mind. Do not confuse good-enough with poor, bad or low quality.

Building your (knowledge) portfolio

Invest regularly, diversify, manage risk, buy low sell high, review and rebalance. Quite simply, maintain your skills with small steps, learn new technologies (but we weary not to invest in just one technology). If your past was all ASP.Net, then consider working trying out Ruby on Rails - and the earlier you get in, then better it can pay off.

Here's how you can build your portfolio: learn a new language every year; read a technical book (hey start with this one) each quarter; read non-technical books too; take classes; and be involved in local user groups.


Communication is all about your reader, and little about you.

What do you want them to learn?
What is their interest in what you've got to say?
How sophisticated are they?
How much detail do they want?
Whom do you want to own the information
How can you motivate them to listen you?

DRY - Don't Repeat Yourself

Duplication happens everywhere, in your code, in your comments, in your documenation. Be aware of the following types of duplication and try to minimize: you have no choice, you do not realize you are duplicating, or you (well not you, but your teammates) are lazy.

TIP 8 Invest regularly in your knowledge portfolio
TIP 9 Critically analyze what you read and hear
TIP 10 It's both what you say and the way you say it
TIP 11 DRY - Don't repeat yourself
TIP 12 Make it easy to reuse
TIP 13 Eliminate effects between unrelated things
TIP 14 There are no final decisions