BK97PRSK.RVW   20101211

"97 Things Every Programmer Should Know", Kevlin Henney, 2010,
978-0-596-80948-5, U$29.99/C$37.99
%E   Kevlin Henney
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2010
%G   978-0-596-80948-5 0-596-80948-4
%I   O'Reilly & Associates, Inc.
%O   U$29.99/C$37.99 800-998-9938 fax: 707-829-0104 nuts@ora.com
%O  http://www.amazon.com/exec/obidos/ASIN/0596809484/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0596809484/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0596809484/robsladesin03-20
%O   Audience a Tech 2 Writing 2 (see revfaq.htm for explanation)
%P   229 p.
%T   "97 Things Every Programmer Should Know"

The preface describes this book as a "crowdsourced mosaic of what
every programmer should know."  The editor freely admits that there is
no attempt to structure or make the contributions fit together, and
that some will contradict each other.  It is up to the reader to
consider the points, and weigh them against experience on the job.

The individual pieces (all fitting on two facing pages) suggest that
you should pay (put in the effort) now (early in the development
process) instead of pay later, consider the user, standardize,
simplify, make code legible, collaborate, comment, test, practice,
handle errors properly, don't mess with production, know multiple
languages, estimate, remember that "quick" code may last a long time,
communicate, and consider the future.  Many articles reiterate the
same points.

There certainly are contradictions.  One will say that tools can be a
problem, another says that tools are seldom *the* problem, while a
third says that you should be careful that convenient tools are not
making decisions for you.  Yes, you should comment, no, you should
keep comments to a minimum.  It's important to read the code, it's
important to clear your mind of the code.  (I suspect that there
actually is some structure to the book: contradictory items are often
placed back to back.)

Of the "97 Things ..." series, I suspect that this is the most useful
for the target audience.  Programming is an idiosyncratic activity,
often pursued alone, even when part of a team.  At the same time, it
changes constantly, as new problems are presented and new tools
arrive.  Even the most experienced programmer probably needs a
reminder, every once in a while, that a) it wasn't always this way, b)
the current approach doesn't fit all situations, and c) there's always
something else you've forgotten.

copyright, Robert M. Slade   2011     BK97PRSK.RVW   20101211