The Productive Programmer

mapleoin@bluepink.ro (Oin Maple) — Fri, 18 Sep 2009 14:00 GMT

Today I read The Productive Programmer .

I’ve already got a bunch of books piled up and waiting to be read, some of which I’ve reached the middle of and some of which I’ve read only the introduction to. I was bored today and this looked like an easy read that I could drop at any time. It is an easy read, but the fact is, it’s very catchy. It draws you in and doesn’t want to be let go. It’s a great way to spend half a day.

This could have been another one of those “94 things you need to know” books, but I think this title is way better. The tips are divided into 2 big sections and a few separate chapters within each one, giving the book some structure. One of the strange things about it is that its advice spans across 3 different platforms (*nix, OS X and Windows) and they’re all mingled together in the same chapter. I was put off by this at first, but after I’d gotten into the book a bit I realized that it is, in fact, a good idea. The whole theme of the book is programmer productivity and the reason it has this title and not a cheesy title with numbers like “94.3 productivity tips for programmers” is that the tips aren’t what’s important. The book is there to hit people in the head with and open their minds. You aren’t supposed to just use the tips provided, that’s unimportant. What’s important is that you have a shock and realize that you’ve been the wrong kind of lazy as a programmer. You’ve stopped automating, you’ve become a machine; in the author’s own words, computers have started “getting together late at night to make fun of their users”. As soon as I realized what this book was really about, I started reading the Windows tips as well. I also stopped a few times to look in my distro’s repository for tools that I had known of, but never used before, only now understanding their true purpose. There are many applications that seem just trendy at first, until you realize that even a small productivity boost is a big productivity boost. (Go check out gnome-do , I’d heard about it years ago, but never tried it until now).
The book contains tips ranging from application launchers, Firefox’s magic address bar, bash scripting commands to office productivity tips for killing distractions. Once again, the mindset is important, not the tips themselves. The big take-away from this book is beginning to constantly judge everything you do as a programmer. This isn’t new advice (at least for those who have read The Pragmatic Programmer”, which by the way is mentioned several times in this book), but I find it’s better emphasized in this book. At one point in the book, the author explains how it took his team one hour to devise a Ruby script to automate some simple task that would’ve required 10 minutes if done manually and finally only needed doing 5 times. One could say there was a loss in productivity, but as the author points out, one would be wrong. Those 50 minutes would’ve been spent with the brain turned off, whereas the hour writing the script was spent learning, focusing, practicing, gaining knowledge that can later be used on a different project. Some of us would probably have gotten bored in those 50 minutes and fallen into procrastination. That doesn’t happen when you’ve got a complex problem to solve.
That was the first part of the book, Mechanics. The second part, Practice is a bit harder to read, as it’s not just disparaged tips on very different applications. They’re quite two separate books actually. The majority of the examples in Part IIare java (they’re mostly readable even for someone who doesn’t speak the exact dialect of OOP that java uses) and this part is mostly about software construction as Steve McConnell would say, but it’s also about Java. I learned a new acronym: YAGNI which basically means that thinking ahead is bad. This is probably one of the advices that I feel the least guilty about, but which I sometime observe in people around me. Never program a feature you don’t urgently have a need for.
One of the good points of this book is the originality with which the ideas are expressed. Most of these ideas aren’t new, especially to anyone who’s read other software engineering books. The text is spiced up with little narratives of different adventures from the author’s experience as a consultant and there is also an Ancient Philosophers chapter and an explanation of the PacMan game’s way of functioning (although I didn’t understand how that’s supposed to make the game less enjoyable).

Revolution blahg

The Productive Programmer