REVIEW: "The Productive Programmer", Neal Ford
- BKPRDPRG.RVW 20091004
"The Productive Programmer", Neal Ford, 2008, 978-0-596-51978-0,
%A Neal Ford nford@...
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
%G 978-0-596-51978-0 0-596-51978-8
%I O'Reilly & Associates, Inc.
%O U$39.99/C$39.99 800-998-9938 nuts@...
%O Audience a- Tech 2 Writing 1 (see revfaq.htm for explanation)
%P 206 p.
%T "The Productive Programmer"
The preface states that this book started out as a book of tips for
the use of the command-line, but developed into a more general work
identifying factors that make programmers productive. (This audience
description is later modified to individual programmers, ratehr than
teams.) Chapter one is an introduction to the book.
Part one contains the mechanics of productivity, in terms of specific
tips (divided by category). Chapter two deals with acceleration, but
of the interaction with the computer, rather than the computer itself.
This material is very useful, and feels somewhat like that contained
in the O'Reilly "Annoyances" series of guides and particulars, save
that Ford does not always fully explain how to set up or implement the
functions he is recommending. The ability to focus on work, and avoid
distraction and clutter, is addressed in chapter three (although much
of the text is concerned with searching for files). Chapter four
exhorts you to automate small, repetitive tasks. The actual tips,
however, are unlikely to be of much assistance unless you want to do
those specific functions, or already know the tools being displayed.
The advice on limiting the number of copies of an item, in order to
reduce spurious "versions," is good, but the author seems to go
overboard, in chapter five, regarding complex ways to achieve this
Part two provides general concepts and practices to promote
productivity. Chapter six recommends "test-driven design," whereby
the tests are created first, and the application written to meet those
tests. While there is merit in this approach, security professionals
know that the presence of desired functions does not preclude the
existence of unwanted vulnerabilities. A few code static analysis
tools are described in chapter seven. Proper object behaviour is
encouraged in chapter eight. In chapter nine Ford recommends that
programmers not build code or functions that they do not need.
(However, as one of the illustrations shows, knowing what you need is
not easy.) Chapter ten notes a few "ancient philosophies," mostly to
do with maintaining simplicity. Having told us to learn from the
past, though, the author turns around in chapter eleven and suggests
that we dispense with received wisdom. Chapter twelve is about meta-
programming: writing code to write code. In chapter thirteen, Ford
seems to implement modular programming in an object-oriented
environment, as he recommends programming everything at a single layer
of abstraction. Somewhat in contradiction to the concept of
simplicity emphasized elsewhere, chapter fourteen stresses using a
variety of programming languages, each where it is most useful.
Chapter fifteen describes some of Ford's favourite editors and other
tools. An odd one-page "this is what I told you" closing makes up
Parts of this book are excellent and helpful, other parts are less so,
presenting contradictory positions without guiding the reader to find
a proper balance. In addition, Ford writes pretty much exclusively
from his own experience and perspective: some of the advice is
general, but a great deal will be helpful only to those who are doing
the same type of programming in the same scale of operation with the
same application intent.
copyright Robert M. Slade, 2009 BKPRDPRG.RVW 20091004
====================== (quote inserted randomly by Pegasus Mailer)
rslade@... slade@... rslade@...
Hain't we got all the fools in town on our side? And ain't that a
big enough majority in any town? - Mark Twain's Huck Finn