Monday, September 15, 2008

Book Review: The Pragmatic Programmer

PragmaticProgrammer[2]It has been quite a while since I have been able to sit down and get some reading done. However, I was able to finish "The Pragmatic Programmer" by Andrew Hunt and David Thomas last week. This book is full of great advice, examples and insight which can be used by anyone developing applications at any level. There are 70 practical tips and 11 checklists which give advice on many programming tasks.

The authors waste no time in presenting their tips, in fact, they provide two in the introduction. Tip one is “Care about your craft” which is very closely related to tip seventy “Sign your work”. People who care about their craft tend to build better products and by claiming what you work on you are taking responsibility for the work you are doing. Accountability makes all of us pay more attention to what we are doing and promotes better quality as well.

There is so much good information in this book that it is difficult to highlight the best ones. I found some insight in every chapter and with each tip. This is the kind of book that you could read every year and get something new out of it. I think the best thing to do with this book is to take a handful of tips and work on them and then move to a new group. With this in mind I will highlight the handful of tips that I have chosen.

Tip number four “Don’t live with broken windows” I found particularly interesting. This is based on the Broken Window Theory which basically says that if we do not fix broken windows there is a tendency for more windows to be broken. If we leave bugs in our software after we find them then we place less emphasis on fixing future bugs. Although it is impossible to eliminate all bugs, we are developing software after all, making it a habit to fix bugs when they are discovered encourages us to work harder to ensure our code starts out as bug free as possible.

Although I have been doing quite a bit of self-development this past year I chose tip eight “Invest regularly in your knowledge portfolio” as another to focus on. I have read several programming books this past year and I have done more work in Java. I still have some more to learn with Visual FoxPro the next environment that I am focusing on. The authors recommend getting involved in local user groups, subscribe to trade magazines and to get wired, which back in 1999 meant newsgroups. I think my blog list pretty much covers the get wired requirement but I agree that user groups are a great idea.

Tip number twenty-two is “Use a single editor well”. This emphasizes the need for knowing how to use your tools. We all have our preferences on the best editor to use and the beauty of it is that there are many great editors available. The one you choose is really up to you just focus on knowing all the ins and outs of your editor of choice. You can be much more productive when you know all the tricks of your editor.

Tip number twenty-three is “Always use source code control”, I know your all shocked that I am not doing this. In my defense, as weak as it is, the projects that I typically work on are examples and simple utilities. This isn’t an excuse and I have already begun my search for a source code control system which I will use for all my projects. I am sure this will even spawn a blog post or two.

Tip number twenty-eight is “Learn a text manipulation language”. I have used Python for some simple projects and I have done some limited work with Perl. However, I have not used either for any significant projects in the past. I have used regular expressions successfully and they can be a very powerful tool. So it is time for me to revisit one of these technologies.

Tip number fifty “Don’t use wizard code you do not understand” really struck a chord with me. I have been using Visual Studio for many years along with its ubiquitous wizards. I realized that many times I have used a wizard to complete a task but I have rarely examined the resulting code. The authors make the important point that after the wizard has done its job the code is left to the programmer. If the wizard generated code isn’t working then the wizard isn’t going to fix it. Having an understanding of the wizard code could prove to be an invaluable troubleshooting tool.

Tip number fifty-five “Don’t think outside the box – find the box” was presented in a section entitled Solving Impossible Puzzles. While reading this section I couldn’t help but think about the Kobayashi Maru scenario in which Captain Kirk “changed the conditions of the test”. To solve a really difficult problem you need to examine all of the possibilities closely. By narrowing down the possibilities the solution can be reached.

The bottom line is this book can be a valuable resource and should be a part of your library. There is way too much information to absorb in a single reading, making this a book which could be read many times. Hopefully, I will be able to incorporate the tips I have chosen into my programming practice. Once I have gotten better at these I will move on to some more. In fact, I already have my eyes on the tips related to testing; 48, 49, 62 and 63.

2 comments:

Toni M. Feltman said...

Hi Chris, my name is Toni and I am a VFP developer. I just happened to catch your post looking for something else. I am reading the Pragmatic Programmer right now. It is a fantastic book! Anyway, the reason for my comment is about version control. I was a late adopter about 7 years ago. I have used VSS, SOS, Vault and am now using SVN with Tortoise. Tortoise is free and very easy to use. I recommend it as a starting point given the cost. Just my 2 cents.

Chris said...

Toni, thanks for your comment. I have used VSS and CVS in the past as well. I was planning on trying out Vault and Team Foundation Server. I will add Tortoise to my list as well.