Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Pragmatic Programmer, The

by footpad (Monsignor)
on Apr 27, 2001 at 22:45 UTC ( #76219=bookreview: print w/replies, xml ) Need Help??
Order Pragmatic Programmer, The

Item Description: Excellent Guidebook into the Craft of Good Programming Practices.

Review Synopsis: Want to learn how to be a good or better programmer? Buy and read this book. Now!


The Pragmatic Programmer: From Journeyman to Master
by Andrew Hunt and David Thomas

Published October 1999 by Addison Wesley Longman, Inc.
ISBN: 020161622X
List Price: $34.95 U.S., $52.50 CAN
Edition Reviewed: First Edition, First printing
Web Site, Sample Chapter, and Errata:

Review Contents


The Pragmatic Programmer, by Andrew Hunt and David Thomas, has an ambitious agenda, one stated in the first line in the Preface, This book will help you become a better programmer. It's a bold assertion and, given the number of books making similar claims, one to use as a benchmark against the book's success. By this, and any other benchmark, the book succeeds admirably.

Since I'm sometimes criticized for ambiguity in my posts, let me state this as clearly as I can: The Pragmatic Programmer (TPP for short) will help you become a better programmer...if you are receptive, open to its lessons, and willing to change.

TPP is not about Perl, though it refers to it often and with much respect. TPP outlines several ways to use Perl effectively in any project, regardless of the implementing language.

TPP is about software craftsmanship. Indeed, Hunt and Thomas aren't concerned about teaching you how to use a single language. Instead, they use the lessons they've learned in their combined forty years of software development experience to argue that the best programmers have a broad enough background and experience base to allow to choose good solutions in particular situations. (quote taken from the Preface, p. xviii).

In the paragraph immediately following the one containing that quote, Hunt and Thomas summarize their philosophy:

You adjust your approach to suit the current circumstances and environment. You judge the relative importance of all the factors affecting a project and use your experience to produce appropriate solutions. And you do this as your work progresses. Pragmatic Programmers get the job done and do it well.

When read completely in context, it's an extremely powerful argument. Once they're presented their goals, they get straight to work. Make sure you read the Preface.

How It's Done

In each of its eight chapters, TPP collects a series of essays covering specific aspects of software development. When reviewed as a collection, you notice that they've touched on every element of the entire development process. Coverage includes:

  • Why programmers (and their code) should be pragmatic, not perfect.
  • How to design effective subroutines, modules, algorithms, and programs,
  • Effective commenting, documentation, and communication techniques.
  • The importance of testing, as well as how to design effective tests.
  • Why version control is so important.
  • How to collect, document, and communicate the proper requirements your applications need to solve.
  • How to make users and project sponsors truly happy
  • Where to go for more information and how to ask good questions.
  • The benefits of following the book's advice as well as the dangers of ignoring it.

Take a moment to review the Chapter Summary provided below. TPP clearly covers many topics. To tie this broad range of material together, the authors' develop a series of Tips (starting in the Preface) they believe all good (read: pragmatic) programmers should follow. Not only are these Tips useful, practical, and accurate, they're also summarized in a convenient quick reference chart. Pull it out of the book and keep it near your keyboard.

You don't have to read TPP sequentially. Each essay stands on its own and is fully supported through examples, code samples, ancedotes, challenges, and exercises. Essays refer to others providing information related to, or referred by, the topic at hand. Furthermore, the book carefully refers to a wide range of other resources for continued study, including web sites, books, periodicals, and so on. TPP would make an excellent textbook for classes devoted to effective programming practices.

TPP also emphasizes the importance of personal disclipine, resposibility, and critical thinking. It effectively documents techniques ignored by most technical titles, such as othoganality, reversability, and refactoring. It provides solid advice on how to use these critical techniques, how to develop your skills, and how to prevent projects from falling apart.

Putting it into Practice

TPP was clearly designed using the techniques the author's advocate. Each word, example, description, anecdote, and point is carefully chosen. For example, the second essay in Chapter 1, Software Entropy, summarizes the findings of a study into the causes of urban decay. This study found a single trigger that rapidly transforms a building and its surrounding neighborhood into an area people avoid. (I won't tell you that cause, because I want to you to buy the book and read it for yourself. However, I can tell you from my own experience, it's accurate, easy to remember, and requires a commitment few are willing to make.)

To illustrate this trigger in action, I recently dinged another book pretty heavily for typos and other editorial mistakes understandably present in the first printing of a new book. As I said in that review, I tend to notice such mistakes. My copy of TPP is also a first printing and I found no typographic errors. While TPP's web site outlines a few syntax errors in code samples and a couple of grammatical errors, I find it interesting (and instructive) that I noticed no blatant mispellings or typographical errors. Since I know how boring, time-consuming, and exacting it can be to review galley sheets, I believe this clearly demonstrates the authors' attention to detail and commitment to quality.

Chapters move logically, carefully progressing through the same process master craftsmen use when approaching their work. It starts by analyzing thought process of a pragmatic programmer (Preface and Chapter 1), transitions to approaches that lead to excellent (read: pragmatic) programming (Chapter 2), reviews the tools you need in your arsenal (Chapter 3), and continues evolving its coverage until the final essay, Pride and Prejudice, which advises you to sign your work and to own it.

The craftmanship metaphor infuses the book. From the cover art (a wood plane), the subtitle, and the prose. Interestingly, the authors' biographies on the back cover lead with their outside interests and downplay their technical accomplishents. The author's assertion that programming is a craft is firmly delivered.

As a result, the book itself compellingly supports the practices it advocates.

Certain points may make you feel uncomfortable. That's a good thing, for it means you're aware of the authors' wisdom. Learn from your discomfort and use it to adjust your approaches accordingly. You cannot avoid previous mistakes, but you can learn from them and prevent them from recurring. The book shows you how.

Who Can Benefit?

I believe that everyone involved in any part of software development will benefit from the advice in this book, for it covers more than effective programming. Its practices apply to any project, even non-technical ones. It doesn't matter if you're a code-slinger, project manager, system administrator, support engineers, QA tester, or even a fast-food cashier. Granted, few non-technical tasks can benefit from understanding effective use of assertions, however, every task has problems to deal with and the author's ideas can be adapted to even the most obscure task. Every position requires thought and every activity flows from specific decisions that you make. This book helps you learn to make better, more effective (read: pragmatic) choices.

That said, experienced programmers will gain the most from this book, for they will have made the mistakes the authors are trying to help you avoid. Experienced programmers have seen the results the authors are trying to prevent. Experienced programmers will understand the accuracy of the authors' experiences, even if only intuitively.

For example, I recently ranted about a project I'm currently involved with. Had I employed this book's advice from the start of that project, I doubt it would be floundering now. Had I had this book's knowledge in hand ten years ago, I would not have had made certain mistakes. I can honestly say that it will improve my future efforts.

This is not to say that novice programmers can't learn from the book. The information presented is valuable to anyone in the process. However, you may not fully appreciate that until after you'd made some of your own mistakes and developed some of your own ideas from practical, real-world experience.

Again, you need this book. You need to read and re-read this book (often). You need to refer to it when you're stuck and before you write a single line of code or design a single algorithm.


It's very easy to review a bad book. You catalog a laundry list of major flaws, tell your readers to avoid the title, and then submit the copy, secure in the knowledge of a job well done.

Good books are just as difficult to review, for you want to communicate your reverence over the authors' accomplishments, your wonder at the accuracy of their observations, and your honest hopes for the book's success. Indeed, there's an awareness that your review must be as carefully crafted as the work you're reviewing, for failing to do so may allow some readers to pass on the title.

I don't want to make that mistake in this review. If you're not convinced you need this book, please look past the shortcomings of my writing skills and see my enthusiasm for the work. I realize I've been a little lean on the specifics; that's because Hunt and Thomas communicate their ideas better--and more succinctly--than I can.

If you care about your work as a programmer, wonder how to develop your programming skills, are frustrated by the lack of progress on a project, or even if you think you know it all, I strongly and emphatically implore you to buy this book. If you read it, incorporate its ideas into your work, and return to it frequently, you will become a better programmer. Yes, it'll take time, but the investment will return far more than it will cost.

Final Score: Six out of five camels...yes, it's that good.

Table of Contents

  1. A Pragmatic Philosophy
    1. The Cat Ate My Source Code
    2. Software Entropy
    3. Stone Soup and Boiled Frongs
    4. Good Enough Software
    5. Your Knowledge Portfolio
    6. Communicate!
  2. A Pragmatic Approach
    1. The Evils of Duplication
    2. Orthogonality
    3. Reversibility
    4. Tracer Bullets
    5. Prototypes and Post-It Notes
    6. Domain Languages
    7. Estimating
  3. The Basic Tools
    1. The Power of Plain Text
    2. Shell Games
    3. Power Games
    4. Source Code Control
    5. Debugging
    6. Text Manipulation
    7. Code Generators
  4. Pragmatic Paranoia
    1. Design By Contract
    2. Dead Programs Tell No Lies
    3. Assertive Programming
    4. When to use Exceptions
    5. How to Balance Resources
  5. Bend or Break
    1. Decoupling and the Law of Demeter
    2. Metaprogramming
    3. Temporal Coupling
    4. It's Just a View
    5. Blackboards
  6. While You Are Coding
    1. Programming by Coincidence
    2. Algorithm Speed
    3. Refactoring
    4. Code That's Easy to Test
    5. Evil Wizards
  7. Before the Project
    1. The Requirements Pit
    2. Solving Impossible Puzzles
    3. Not Until You're Ready
    4. The Specification Trap
    5. Circles and Arrows
  8. Pragmatic Projects
    1. Pragmatic Teams
    2. Ubiquitous Automation
    3. Ruthless Testing
    4. It's All Writing
    5. Great Expectations
    6. Pride and Prejudice


  1. Resources
    • Professional Societies
    • Building a Library
    • Internet Resources
    • Bibliography
  2. Answers to Exercises

[- End -] 

Replies are listed 'Best First'.
Re (tilly) 1: Pragmatic Programmer, The
by tilly (Archbishop) on Apr 28, 2001 at 19:52 UTC
    I think I can summarize what I liked about the book very simply.

    Pragmatic programmers realize that rules don't exist because there is some ideal aesthetic in which that is the right way to do things. Rules exist because someone tried to put into words what works and what doesn't. Rules are someone's opinion on how to do things. Opinions backed by practice, theory, and (unfortunately) prejudice.

    This book explains a lot of the rules that the authors have found useful over decades of programming. But more importantly than that, they explain why each rule exists. And they strongly encourage you to examine how you work and continue to learn.

    Indeed I have found from personal interaction with the authors that they consider this key. They really believe that it is better to always be thinking while you are programming than it is to blindly follow what someone laid down as good rules. If you blindly follow rules you will not know how to apply them well, and will not understand when you are misapplying them. If you stay concious, and seek to improve, you may come to different rules, but you won't be forever limited by the imagination of the person who laid down the rules, or limited by your initial misunderstandings of what that person's rules were supposed to mean...

Re: Pragmatic Programmer, The
by footpad (Monsignor) on Apr 28, 2001 at 21:08 UTC

    Strictly as an aside, I noticed that the authors' other book, Programming Ruby: A Pragmatic Programmer's Guide is now online.

    So, if you're at all curious about this thing that's been known to raise hackles in the CB, this might be an interesting way to check it out.


Re: Pragmatic Programmer, The
by Anonymous Monk on Apr 28, 2001 at 02:38 UTC
    I thought a pragmatic programmer is someone who writes code like this:
    #!/usr/bin/perl use attributes; use attrs; use autouse; use base; use blib; use bytes; use charnames; use constant; use diagnostics; use fields; use integer; use less; use lib; use locale; use open; use ops; use overload; use re; use sigtrap; use strict; use subs; use utf8; use vars; use warnings;
      No that's pedantic.
Re: Pragmatic Programmer, The
by FoxtrotUniform (Prior) on Jun 09, 2004 at 20:17 UTC

    I try to re-read this book every six months or so, just to keep everything swapped in. It's very, very good.

    F o x t r o t U n i f o r m
    Found a typo in this node? /msg me
    % man 3 strfry

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: bookreview [id://76219]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (9)
As of 2017-02-24 12:01 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (354 votes). Check out past polls.