on April 15, 2004
A friend of mine recommended this book to me a year ago and I finally got around to reading it. Not only do I wish I had taken him up on his recommendation immediately, I wish that I had read it years earlier. The book's subtitle "from journeyman to master" really sums it up nicely.
The book contains practical advice from experienced programmers that will help you become a more effective software developer. Unlike many books which dogmatically preach a specific methodology, this book focuses on (not-so-)common sense practices that are simple yet effective, as well as highlighting potential pitfalls to be avoided. Many of them can be applied to your own development process without requiring radical changes, while others will require team- or project-wide changes. Fortunately the nature of the recommended practices is such that you don't have to adopt all of them to be effective. You can pick and choose which ones are most appropriate and gradually incorporate them into your development process.
The range of topics covered is fairly broad, but the important themes are writing easy-to-maintain, reusable code, identifying and adjusting requirements quickly and effectively, managing large projects, and avoiding bad habits and developing good attitudes. Although I don't absolutely agree with everything the authors present, the justification they provide is thought stimulating and will probably change how you do things even if you don't consciously decide to adopt any of their practices.
I found the exercises (and their accompanying solutions) scattered throughout the book to be extremely useful in internalizing the principles being taught, as well as gauging how well I approach problem-solving. I'd highly recommend working through them as you read the book.
Finally, it's worth mentioning how enjoyable this book is to read. The authors' sense of humor and sprinkling of anecdotes make this an easy read without in any way detracting from the content.
If you're a brand new programmer, you probably won't appreciate many of the ideas presented in this book, but come back after you have a year or two of experience. Successful, experienced programmers will find that this book confirms many of the things you're already doing, while providing a lot of useful ideas to become even better. Even if you're not a programmer, but manage or otherwise work with programming teams, you'll find a lot of helpful information here. If there were one book I could require all of my coworkers to read, this would be it.
on January 28, 2004
"Any clod can have the facts, but having opinions is an art." (Charles McCabe)
By McCabe's definition, this book is very artful. That's a good thing - the opinions are founded on long experience and on broad familiarity with software development. The authors, true to their "pragmatic" promise, often omit the theory and case history that justify the opinions. They offer reams of advice on nearly every part aspect of industrial programming, and I think that all of the advice is good.
I don't agree with all of it - good advice is good within its limits, and my work often lies outside of their limits. Take, for example, their editor fanaticism. I've been hearing for 25 years how much more efficient my work will be if I use editor <xyz>. First, I move between development environments so much that learning funny key-pokes for one environment just gives me the wrong reflexes for the next environment and the one after that. Mostly, though, text entry is about 5% of my problem. Suppose, after a "near-vertical learning curve", that the cult editor cuts 20% off my editing time - data entry would then be 4% of my problem. The cost/benefit ratio underwhelms me. If you really love your escape-meta-alt-control-shift (emacs) editor, though, don't let me get in your way.
I still think that almost all of the authors' views are good ones, with good reasons behind them. I rabidly agree with lots of them (especially DRY - Don't Repeat Yourself), and for lots more reasons than they give. The book is helpful even where I disagree. When I rethink my own circumstance, it's not that their reasoning is wrong, but that different reasoning is more right.
This is one to keep, not just for the programmers in the trenches but for their managers, as well. Best, it doesn't try to dress up the -ism of the day as holy law - as the title says, it's about pragmatics.
on December 31, 2003
I've had this book for a number of years now and skim it regularly. I've recommended it to starting and would-be programmers as well as hoary old "I remember punch-card" war horses. I often wish there were more books in this same vein.
The only downside that I could note is that the authors often refer to their own preferred languages & scripts, which both dates the product a little (more so with each passing year), and is also not so useful to those working in different environments or who have their own strong preferences.
However, the nuggets of wisdom and common-sense analogies in this book are golden. If you're like me, you'll often find yourself nodding along with the book while reading a passage that describes something you've experienced or espoused first hand and grimacing when it points out a trick you wish you had thought of when working on some past project.
This book really doesnt have much to do with _programming_ but is really more about _being a programmer_. It's sort of like a self-help for proggies, a mentor-in-a-book. The book's subtitle is "From Journeyman to Master", and this jives with the idea of the things in the book being the sort of Guild-lore a Master Craftsman might pass on to his favored Journeymen prior to retiring back in the days of yore.
I've been a professional developer now for 6 years, self taught and continuously employed at several companies during that time. This book appealed to me when I picked it up because it is true-to-life, and several of the real-world considerations mentioned jived with my own experiences. The ideas and practices that I already had were crystalized and refined by this book, and it also introduced me to ways of thinking that I had not considered.
Perhaps the most significant single line in the book for me is on page 255, "A project that falls below expectations is deemed a failure, no matter how good the deliverable in absolute terms". This struck home because I was once involved in a major project involving multiple programmers from multiple locations around the States, which met every design specification and delivered exactly what was promised, but which was mothballed after its completion because the management didnt understand it. Their expectation was something other than the specification which they had approved and thus we harried developers wasted the better part of a year on a system doomed to failure not because it didn't work or was a bad idea, but because the head honchos just didnt get it. I never understood why until I read that line in this book, and then it all came clear -- their expectations were not in line with the deliverable, and thus they did not want the deliverable despite the fact that it functioned exactly as planned.
Since then I've made it a point to personally do all that I can to ensure that the consumers of projects I'm involved with are "on the same sheet of music" when it comes to understanding what all the tech-speak and specifications actually MEAN. Prototyping and "Tracers" as described in this book have been used to provide mockups before any real code has been written. Documents couched in "Laymans Terms" have been produced. Sometimes it's overkill, but at the end of the projects no consumer comes back saying "thats not what I thought it was going to be". Some Project Managers dont like it, as they feel like it's stepping on their toes, but in the end no Project Manager will complain if the Project is successful -- they get to look good for a while, so kibitzing over the means isn't a priority ;) .
All that aside, if you are a working developer with a grounded approach to programming, and dont have the conceit that you already know everything, I think you should give this book a read thru.
on December 24, 2003
Provides a lot of what experienced developers would consider "commonsense" advice and philosophies. Also gives an excellent language for talking about this sort of stuff with others.
Short and to the point. It's sometimes hard to get "I'm too busy" developers to read, especially the big, dense books lots of folks like to produce around the programmer management area. It's easy to find sections in this book that are useful, can be thrown at someone and be consumed by them in a half-hour (not fully digested, though!). Absolutely wonderful.
What can I say? It's hard to find fault with this book. The only thing I can say that might have helped are a few stories about the risks of not following the practices, though it's questionable how much that would help things. If programmers were horses, you could lead them to water, but not until they'd suffered severe dehydration and a hospital trip or two would they convince themselves that advice you'd given around appropriate water consumption was actually useful...
on May 29, 2003
This book was recommended by a co-worker, and he mentioned that at a previous gig, his manager got a copy for everyone in the department. This is not a reference book, but it is technical in nature. As such, it is meant for programmers and those who work closely with them (analysts, QA engineers, and project managers could benefit from it as well), but it isn't dry or boring in the least.
It contains quite an assortment of gems gleaned from the wisdom of very experienced coders. Although you won't find anything earth shattering, you will find a collection of concrete examples that you can use to immediately improve your skills. These are not the latest methodology fads (i.e., UML, OOP), but rather things to think about while you are writing code.
As an example, have you ever gotten a program to work, and although you're not exactly sure how, you figure you better leave well enough alone, lest you break it again? This is "Programming By Coincidence," Tip 31, page 172.
I would strongly recommend this to newer programmers, especially. If you look at the talented coders in your organization, chances are they are practicing a lot of the ideas in this book (and most likely they own a copy).
on October 27, 2002
The Pragmatic Programmer is the book all programmers should have to read before they are unleashed onto your source base.
The book is nice and terse, covering the ground it needs to cover in little over 250 pages. Clearly the authors are applying the lessons they learnt from Unix, Perl, c++ and a variety of other sources. Rather than wasting words trying to beat home their lessons, the authors have trusted that the reader has some degree of intelligence. They present each nibble of wisdom in a few paragraphs of pithy text which helps to support the 70 tips they provide throughout the book.
The book covers a fair degree of ground in it's 258 pages. Testing, documentation, automation and even requirements specifications all get a look in. Most of the book however, is devoted to that part of the art which is harder to define and learn. It is usually learnt from painful experience, or passed on by a senior programmer if you are lucky enough to have one around. It is this knowledge that makes the book worth the read.
It's value is not so much that you will find anything revolutionary inside the book, you wont, but that the book provides a terse and approachable font of wisdom for programmers of all skill levels. It is filled with the sort of sensible advice that stops you getting third degree burns while cooking, or cutting your hand off while doing woodshop. Managing to convey that knowledge without sounding preachy or ivory tower in nature adds to it's charm.
This book will be required reading for all the programmers on my team at work. It will help them to understand the bigger picture of development, rather than focusing on the minutae of cutting code.
on September 7, 2002
If you're already a pragmatic programmer, this book positively reinforces that which you probably already know (either innately or through experience ... but usually the latter), while drawing out many tidbits of knowledge that lie dormant in our subconscious.
If you're new to programming and lack the mentorship of a pragmatic programmer, read this book! Be open to the ideas and absorb the wisdom.
I read this book cover-to-cover. I found the content well-organized, and I appreciated the inclusion of exercises (with answers in the back) which tested my knowledge and assumptions. The checklist and quick reference guide is also a nice touch. Overall: an easy read.
As a final note, readers will find errata on the authors' website with the exception of the following: Detracting from an otherwise excellent book are the glaring bugs in the answers to Exercises 7 and 8; specifically, the bison/yacc grammar and Perl code don't handle a range of valid input (e.g., "12:30am").
on August 2, 2002
Okay, so it has been a long time since you read "Code Complete". Time to brush up. This book is a retreat for road-worn warriors. Many good ideas (okay, not all of us will give up our productive IDE habits). Good presentation. I like the exercises along with the answers in the back. I especially like how the answers are presented. Typically, it is just the answers. This book has both the questions AND the answers in the back. No need to flip back and forth. Also, it is harder to get the answer to the next question by accident (typically if it is just answers, my eyes wander to the next answer).
The only complaints I have are the cover. First, it curls too easily. After reading first 20 pages, had permanent curl to it. Second, the color/material is grease prone. I take good care of my books (I often sell after reading once and the buyers swear they are in mint condition). However, after that same 20 pages, the cover had fingerprints and smears on it. It may be due to the dark charcoal color. Probably more due to poor materials. So, buy it, read it, keep it on your bookshelf.
on March 5, 2002
The most challenging thing that I have to overcome as a developer is to make the most use of all the tools that I have acquired from reading technical books and papers. Most of the time, I find that I know how to do something, but I need a push in the right direction to show me what is achievable with my skills.
This book doesn't teach you how to create X using Y. It doesn't tell you how to write sort algorithms or develop asynchronous messaging systems. It makes the daring assumption that you already know how to do all that type of stuff. Instead, it teaches you how to rearrange your skills into a more efficient and inspiring toolset.
The most important thing to ask yourself is not "What do I know" but instead, "What is possible". This book lays out a framework for thinking more in these terms without concerning yourself with the minor details that can be looked up in a book.
I hate to borrow from the old "Teach a man to fish..." story but I have to say, I'm catching fish all over the place!
on January 15, 2002
I came to this book at a low time in my life. I had been working in software for over 12 years and I was beginning to think that I was an old fossil that no longer knew anything about how to write code "these" days. This book reassured me that I still knew what I was talking about and that my experience still had relevance in today's software environments. For that, I cannot thank the authors enough.
What I liked most about the book is how it is based in the real world. This isn't an airy-fairy book about how things should be done but what the authors have discovered as they have progressed through their careers. I must admit that a lot of it strikes a resonance within me, especially the areas that I feel that I am weak on.
In many ways the book confirmed many of my long-held beliefs (e.g. the command line is a "good" thing ... for developers). However, it encouraged me to think more about documentation (i.e. building it in) and meta-programming (to cut down on duplication and ease code generation). I have thought about this issues from time to time but Andy and Dave help you to realise that this can work for you, and cut down the overall amount of work you have to do. I had always avoided meta-programming since getting the immediate task completed always "seemed" more important at the time.
I cannot praise this book enough. It covers the praticalities of working in software in a way the Steve McConnell's Code Complete does not. I think the chatty style is what makes the difference. Code Complete, which I admire in many ways, seems far more dry than The Pragmatic Programmer. I would recommend that a engineer read both books since CC covers so many basic issues that it is difficult to fault (expect for the positioning of braces in C code) whereas TPP is ground in the practicalities of what does, and does not, work within a wide variety of environments.
I would heartily recommend TPP to anyone, especially to those that have been working in software development for a few years.