Mark Needham

The Book

The Productive Programmer by Neal Ford

The Review

I first came across this book when I was browsing Andy Hunt's Pragmatic Thinking and Learning: Refactor Your Wetware on Amazon. It showed up as one of the related books.

I had expected it to be a more theoretical book than it actually is. It is full of really useful command line tips and ways to use system tools and IDEs more effectively. It only took until page 3 for me to learn something from this book - a short cut for navigating Firefox tabs which I now use all the time. Apple Key + Tab Number (Mac) or Ctrl Key + Tab Number (Windows) takes you to the appropriate tab for those who are intrigued!

The first half of the book (Mechanics) covers general power user tips and tricks for using your machine better while the second half (Practice) is more about ways that you can be more productive as a developer.

I will summarise some of my favourite parts of the book and the most interesting things that I learnt from reading it.

Mechanics

• I have often wanted to learn how to use the Unix command line properly - I know how to do basic operations but nothing spectacular - but I found it difficult to work out how to make full use of it short of pairing with an expert. Having read this book I have learnt some excellent tips that I wouldn't have come across otherwise.
• The idea of shims - little pieces of code that you can write to solve small problems - is the standout idea in this book for me. I often find myself repeating the same boring manual steps without even considering that there could be a better way. This book completely changed the way I think about these types of tasks.
• I thought I had a pretty good idea how to use a lot of the tools on the Mac but Neal shows so many different ways that you can improve your effectiveness with them. The book lists innovative ways to make use of QuickSilver, the Clipboard and Shell and also includes links in the footnotes to applications referenced in the text. This is something I haven't seen done in a book before but it's a really good idea as far as I'm concerned.

Practice

• Neal explains how to use open classes in Ruby when creating fluent interface DSLs and finally I now finally understand why extension methods have been introduced into C#. When there are code samples these are annotated and then explained in detail. This certainly made it easier for me to follow some of the examples around using the Unix shell and Ruby.
• Neal reminds you of things that you probably know but need reiterating. The 'angry monkeys' story is a particular stand out with regards to this. This covers the idea of always challenging why things are being done a certain way and not accepting 'because this is how it's always done' as an acceptable answer. There is an interesting example used with regards to using underscores in test names as suggested here.
• The chapter on Composed Method and SLAP (Single Level of Abstraction) when writing code was especially good - I knew of the concept but I didn't know there was a pattern named after it. My reading around this led me to an interesting post on the Arrow Head anti pattern - this is what the code can end up looking like if you don't keep to one level of abstraction.

I found that the best way to read this book was to read a bit of it and then try out the suggestions on the computer. It's not really a book that you can read on the train for example.

In Summary

I would rank this book up there with The Pragmatic Programmer as one that I would recommend all developers read. There are so many tips in it that you are bound to find some that you didn't know about and your view of automation will be much broader having read it, which can only be a good thing.

I was an automation junkie after reading The Pragmatic Programmer, but after reading this book I think I'm going to become even more obsessive about it.

—

As a side note this is the first time I've tried to write a review of a book on the blog. Feedback on whether doing it like this is useful or better ways that you've seen it done would be gratefully received.