The Productive Programmer

Author: Neal Ford
Rating: 3.5/5

As a developer I am constantly seeking ways in which I can improve my ability to quickly generate high quality code so I was excited to pick up Neal Ford’s latest book, The Productive Programmer. This book offers advice on how to accelerate the production and quality of code by exploring many tools and practices that developers can use on a daily basis. In the book, Ford introduces several productivity patterns that can be used immediately, but more importantly he defines a nomenclature that allows developers to construct additional productivity patterns on their own.

The Productive Programmer is broken up into two parts:

Part I. Mechanics

This section discusses tips, tricks, and tools that developers can use while physically engaged in the act of writing code. This section is laid out in a recipe style format and is the part of the book which I found to be the most useful.

Ford breaks Part 1 down into four chapters which he calls the “Principles of Programmer Productivity”. These principles are:


This chapter discusses tips developers can use to speed up their development efforts. Ford lists many tips on using launchers, clipboards, and keyboard shortcuts for a variety of popular development tools and operating systems.


Ford uses this chapter to introduce guidelines on how to limit distractions, context switching, and pesky officemates so that developers can stay in the zone and focus on what’s really important – their work!


Common tasks that are repeated over and over again can kill a developer’s productivity. This chapter lists strategies for automating such tasks to help save precious time throughout the workday.

Canocality (i.e. D.R.Y)

In this chapter Ford discusses the importance of version control, continuous build machines, and syncing development tools. This helps to ensure the entire development team is on the same playing field so that precious time is not lost in dealing with inconsistencies between individual developer environments.

Part II. Practice

In Part 2, Ford takes aim at practices that developers can use to improve the quality of their code. By using the techniques and philosophies discussed in this section, Ford illustrates how code can be broken down into small, readable pieces that are easy to maintain. Practices covered include Test Driven Development, Static Analysis, and Meta-Programming. Also discussed are a few development philosophies that can guide developers when making decisions about how they should go about writing their code. These philosophies include: YAGNI (You Ain’t Gonna Need It), SLAP (Single Level of Abstraction Principle), and my favorite – Questioning Authority, an excerpt:

This is a story I first heard from Dave Thomas during a keynote address he delivered called Angry Monkeys and Cargo Cults. I don’t know if it’s true (despite researching it quite a bit), but it doesn’t matter-it illustrates a point beautifully.

Back in the 1960s (when scientists were allowed to do all kinds of crazy things), behavioral scientists conducted an experiment where they placed five monkeys in a room with a stepladder and a bunch of bananas hanging from the ceiling. The monkeys quickly figured out that they could climb the ladder and eat the bananas, but every time the monkeys got near the stepladder, the scientists would douse the entire room in ice cold water. You can guess what that generated: angry monkeys. Soon, none of the monkeys would go near the ladder.

Then, the scientists replaced one of the monkeys with a new monkey, who had not been subject to the blasts of water. The first thing he did was make a beeline for the ladder, and all the other monkeys beat him up. He didn’t know why they were beating him up, but he quickly learned: don’t go near the ladder. Gradually, the scientists replaced the original monkeys with new monkeys until they had a group of monkeys who had never been doused with cold water, yet they would still attack any monkey that approached the ladder.

The point is that just because things have always been done a certain way does not mean that we should blindly accept the status quo in favor of doing things that might actually make more sense or improve our code.


The Productive Programmer was an enjoyable read. At 200 pages the book reads very quickly – perhaps a bit too quickly in fact. My one criticism of the book is that it would have helped to have some additional examples to solidify some of the concepts in the second part of the book (I would guess that is probably my one criticism of most books). I did pick up a lot of small tips however and have been using them in my day to day work. I’ve noticed some small speed and productivity improvements so in my opinion this book was totally worth the Amazon sticker price.

Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • DZone
  • FSDaily
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • Twitter
  1. 2 Responses to “Book Review: The Productive Programmer”

  2. I bought this book and it’s great for a lot of suggestions. Really I disagree a few with the YAGNI idea (“don’t build more feature then the features asked NOW”). It’snt too much to short time and not a middle/long time.

    By alepuzio on Feb 4, 2009

  3. Thanks for commenting alepuzio.

    By Justin Spradlin on Feb 4, 2009

Post a Comment