The Pragmatic Programmer is one of those books that has rapidly slipped into the subconscious of much of the programming community. So much so that I have delayed reading it for quite some time simply because I suspected its content to have been duplicated in the many, many articles on development techniques that have passed through my newsreader. But recently, feeling the need to spend a bit more time reflecting on my coding habits I decided to give it a go and I’m glad I did.
Much of the content has indeed become so much a part of developer folk wisdom that it was a quick and familiar read, but as so often happens there were details that I hadn’t been able to glean from those derivative pieces and taking the material as a whole prompted a different focus than would many disparate shorter pieces.
In light of some recent project experiences, their call for a focus on quick walkthroughs of the main areas of projects (whether on paper or screen) was something I’ve already adopted—in this case as HTML since it’s for the use of a designer, though I understand others’ preference for hand-drawn diagrams. And the emphasis on unit tests reminded me that while recent work has often needed too many upfront deliverables to give me time for the serious testing I want to do, I have a few regularly used, oft-tweaked components that should have tests.
Beyond the particular disciplines the book encourages, the more profound impact was a reminder to focus on continuing to learn, becoming a better coder, and taking pride in your work. It’s all too easy for the freelance coder to get caught up in a rush of projects, putting off learning for those quieter periods that come from time to time. The book left me determined not to do that, and to try to set aside a specific period of time in each day to read and practice simply for the sake of getting better.