My Notes on “The Pragmatic Programmer”

“The Pragmatic Programmer” by Andy Hunt and Dave Thomas is a critically acclaimed book that covers many non-theoretical software development practices. I chose to read the book based on many recommendations/references I had seen online and am greatful for the decision. It is a book that I plan to come back and read year after year to understand how I’m applying the topics and how I can better use them.

I thought about writing a “review” of the book, but after reading other reviews on the book online, I felt that I could better document what I took away from it by following what one fellow reader did by listing the tips that he is going to focus specifically on:

Tip 16: Power Editing. In this Tip, the Pragmatic Programmers state that you should know your editor like the back of your hand. This saves you time and gets some of the monotonous work done faster. Since my current IDE of choice is Microsoft Visual Studio 2008, I’ve gotten some posters from Microsoft that show the default C++ Key Bindings. I’m planning on printing these posters out and hanging them next to my monitor.

Tip 23: Assertive Programming. This Tip covers the need to never assume the obvious. In code that I maintain at work, there are a couple methods that return pointers to objects. It is currently assumed that these methods will never return a null pointer. To change this pattern, I plan on taking constructs like this and refactoring them to first assert that the pointer is not null, then convert the pointer to a reference and return the reference. This way, no calling method will have to assert that the pointer is not null.

Tip 26: Decoupling and the Law of Demeter. The Law of Demeter states that no block of code should know the internals of any object that it doesn’t own. This law can be simplified by stating that in languages like Java or C#, there should never be more than one period per statement (as always, some exceptions apply). Sometimes, refactoring to follow this law creates quite a few small wrapper methods, but these negative side effects don’t outweigh the positive gains that come from following this law.

Tip 43: Ruthless Testing. I have set a standard for myself in that I will not write code that is not tested. I have been working on integrating MSTest with Google Mock at work in to our MFC project, and this process will hopefully lead to less regression and improve the reliability of the product. In some circumstances, like GUI programming, I plan on maybe using another testing suite like Selenium (for websites) to test out the layout of the application. This will save me time and also help make the product better. I now will be able to run the tests to see if what I am creating is working as expected instead of starting up the program and trying to follow a specific work flow to regenerate a bug or validate that the specific bug is no longer around.

As I said earlier, I truly enjoyed reading The Pragmatic Programmer, and I highly recommend you to read it if you haven’t. I’ll be coming back to the book in the future to evaluate my progress and look at other Tips I can focus on.