|Do you know where your variables are?|
Pragmatic Programmer, Theby footpad (Monsignor)
|on Apr 27, 2001 at 22:45 UTC||Need Help??|
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
Published October 1999 by Addison Wesley Longman, Inc.
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.
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:
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.
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.
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.
[- End -]