The Productive Programmer, by Neal Ford. O'Reilly, 2008. $39.99. ISBN: 978-0-596-51978-0. Free online access to the Safari edition for 45 days is included with purchase.

He has realized that, while computers have become easier for end users, the very features that paved the way to point and click simplicity are actually making programmers less productive. "Developers who grew up using graphical user interfaces don't know many of the cool, efficient tricks of the trade of the Really Smart Guys of yesteryear," he says.

His goal with The Productive Programmer is to spur those computers from a gentle stroll to at least a brisk trot.

The book is divided into two parts. The first talks about the mechanics of productivity, and the second looks at the practice of productivity.

Part One starts with ways to speed up your interactions with the computer. And, no surprise, they concentrate on typing (did I mention this guy really doesn't like GUIs?). Be it Windows, MacOS or Linux, every common operating system offers keystroke sequences as well as clickable ways to launch applications and perform many functions, and Ford points out several of them.

Next, he discusses ways to eliminate distractions and increase focus while working. Turning off little things such as tool tips that pop up and disturb your train of thought, using dual monitors with code on one and debugger on the other, and segregating workspaces through virtual desktops are but three of his suggestions.

Another productivity killer is repetition. The next chapter of the book talks about ways to automate common tasks, but cautions against shaving yaks in the process. Yak shaving, for the uninitiated, is what occurs when a simple task grows into a herd of unrelated tasks that must be completed before the original can happen. Seth Godin describes it delightfully in his blog posting (http://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html).

There's also the little issue of version control, not only of the software you're developing, but of the machines you're developing on. There are few things more irritating – or harder to troubleshoot - than having software fail on a few machines and work on others because of a different version of a plug-in.

One big-time bonus tucked into chapter five is the source code for a Subversion plug-in that extracts comments from source code and posts them in a wiki for reference by the team.

Part Two begins with a chapter on test-driven design (TDD). Says Ford, "TDD requires that you create the first consumer before you write the code, making you think about how other code will eventually use the code under development." The chapter includes hints on design, and how using TDD methods makes code more reusable.

Next up is static analysis, with descriptions and illustrations of a bunch of handy tools, including some tidbits for users of dynamic languages.

Citizenship and coding are not typically thought of as related, but, says Ford, "good citizenship refers to objects that are both aware of their own state and considerate of the state of others around them."

And that, he says, is all too often ignored as developers "code on autopilot".

What's coding on autopilot? Ford presents this scenario: "You create a new class, you create a bunch of private member variables for it, you tell the IDE to spit out properties (either get/set methods in Java or properties in C#), and then you engage your brain." Public properties on private fields destroy the intent of the property mechanism, he says. You should create properties only when you need to call them from other code.

He's also rather allergic to default constructors, arguing that it doesn't make sense to have objects with no state, and he's not crazy about static methods either.

Antisocial behavior also includes things like the workings of java.util.Calendar which, Ford says, allows engineering purity to override common sense. He recommends developers evict it from their worlds and substitute something better-behaved such as the Joda library (http://joda-time.sourceforge.net).

Complexity is another sin that threatens productivity, and speculative development – stuffing something in because you might need it later – introduces complexity. Thus, says Ford, stay away from frameworks unless they're absolutely essential; they're not inherently bad, except when built purely speculatively. Two bad examples: Enterprise JavaBeans versions 1 and 2, and JavaServer Faces, both of which Ford says are massively over-engineered, making it difficult to actually get work done.

From here he segues to ancient philosophers.

Yes, Aristotle and Occam have slithered into a book on programming. Galileo pays a visit too. And the point is, pay attention to "ancient" lore – its authors already have the battle scars and are passing on their learnings.

And ask questions. The story of the angry monkeys explains why.

The last few chapters include musings on meta-programming (writing programs that write programs), which is described as making "hard things easier and impossible things merely improbable", composed methods, single level of abstraction and polyglot programming (building applications in one or more specialized languages as well as a general-purpose language). Ford even suggests that the era of single-use general purpose languages is approaching its end.

We wind up our tour of productivity builders and killers with a look at tools – finding the right ones, and un-finding the wrong ones. And finally there's an appendix looking at Cygwin and the cool and useful goodies it adds to Windows.

Then Ford invites readers to join in a dialogue about productivity through his public wiki at http://productiveprogrammer.com.

All this, believe it or not, is crammed into just under 200 highly-readable pages, with tons of code samples, and pithy notes sprinkled throughout.

This is not a book for someone who knows nothing about programming. You're expected to understand the terminology and to be able to read the many samples and make sense of them, although Ford does include some command-line basics in his appendix to help out the GUI-centric.

If you fit the target audience, you'll learn something from this book, even if you're a seasoned veteran. And if readers contribute, as Ford hopes they will, the wiki promises even more ongoing value. It is, after all, impossible to be too productive!