The Productive Programmer

Neal Ford’s The Production Programmer1, published by O’Reilly Media, claims to teach you the tricks of the best programmers in the industry. The book proceeds to meet this goal by, in the first half, giving specific tips and tricks for various applications and tools across Windows, Mac, and Linux. The second half discusses the techniques that one can use to learn or familiarize yourself with a new tool in order to ultimately improve your productivity.

I’ll be frank. I don’t think this book is worth the value.

The first half talks about too many tools, too many platforms. It’s not able to cover any one tool terribly well, and it’s attempts to cover a given class of tools felt unfocused and messy.

The advice overall is sound. Learn the tools you’re using. Focus on tools that eliminate the need to move your hands from the keyboard. Automate tasks, often by building scripts.

Maybe it’s just because I’ve been developing on Unix for the past decade, and grew up on the DOS command line before that, but most everything in this book just felt obvious. Hell, I was playing around with Beagle2 (now defunct) for desktop search in it’s very earliest days, well before Google had their own desktop search product3. I live at the command line, even when I’m on Windows as I am at my current day job.

I am not trying to brag. It’s just a familiarity that I’ve gained that even in college I recognized as grossly missing in a lot of my class mates who were bound to their GUI’s and their mouse. For me, the advice was all obvious.

Part two, which covers more of software best practice, like not over developing, or doing proper testing, learning multiple languages, using continuous integration, is also great advice, but I can’t help but think that other books cover the topics better. Admittedly, this book isn’t trying to be comprehensive or definitive on any of these topics, but in it’s general coverage, it seems to fall short.

In retrospect, I am not the target for this book. I read plenty of blogs and other books on the subject of software development and general computing. Ben Collins-Sussman claims that there are two kinds of programmers, the 80% who just plug away, and the 20% who really excel and care4, while Jeff Atwood makes the claim that the 20% are largely the people who actually take the time to read this sort of material5. I am not so proud as to claim myself to be in that 20%. I think I could be some day, and I know that I am above 50%, but I am reluctant to accept the idea of a hard 80/20 split.

This book isn’t bad. It’s fairly entertaining, and it’s got a lot of good information. But it’s almost too introductory. If you feel like you’re trying to get your feet underneath you, and that you really, truly want to be at the top of your field (as you should), then by all means pick up this book. It’s worth it. But if you’ve spent a bunch of time studying the material, reading the blogs, and most importantly, working on techniques to make you faster and better at your day-to-day tasks, then odds are you won’t get too much out of this book.