Rating: 
Summary: If you write code for a living, you should read this book!
Review: First, I should tell you that I did review this book... I got to read it and write a document about my opinion of the book, and it is excellent. There are many books on the market that push one technology or philosophy... this book has a collection of honed practices. It contains sections on your programming tools, code design, project management (among other topics). In short, it is a book that talks about how to become better at what you do for a living. This advice is coupled with excellent examples and stories that make for interesting and memorable reading.I can't emphasize this point enough. This book isn't a collection of stories that support the author's methodology or design technique. It isn't a book designed to sell his software tools. It is a book that will teach you to work more effectively. It talks about practical tips for prototyping projects (different ways to prototype, which is appropriate when, how to justify the time and expense to your manager), how to deal with and communicate effectively with customers, co-workers and managers.... if it sounds like The Pragmatic Programmer covers a lot of topics, that's because it does. If you work with software or manage people who do, you owe it to yourself to read this book! I've been writing code (and reading these types of books) for nearly 10 years, and this is the best one I've ever read.
Rating:
Summary: Wisdom and Humor -- what a rare find
Review: This is, simply, a wonderful book. It is a book that celebrates the real depth of great programming -- something that is too often forgotten or ignored. This is not an idiot's guide to anything -- it is a remarkably entertaining set of dozens of tips to becoming better at what you do, especially if that happens to be programming. The tips are deceptively simple at times, but only a truly naive or inexperienced reader would miss the rich depth that their combination presents. In fact, that is the real beauty of this book -- it does not present some short-lived miracle-cure approach -- instead, it weaves together small bits of wisdom and practical advice into a powerful work-style. They have some controversial views -- these authors are witty and opinionated -- but agreeing or disagreeing with each individual idea is not the point -- "seeing the forest" is. There are numerous specific code examples, but the book is a fun and easy read -- strangely, I also think it would be a wonderful book for someone who is NOT a programmer, but who works with them, perhaps a business manager having a major system built. Even skipping all the really technical parts, it would be a wonderful set of benchmarks to assess how good your programmers really are -- much more powerful than "he has 3 years of C++, 2 years of Linux"... I am hoping this writing team will follow this book with some specific guides as well, but this one is destined to be a classic. These guys really know what they are talking about, and, as a wonderful bonus, they are terrific writers, as well! The book has gotten great reviews on slashdot, as well as a couple of programming magazines, including Dr Dobbs and Software Development -- they were well deserved. Buy IT!
Rating: 
Summary: A welcome kind of view
Review: "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 . 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.
Rating:
Summary: This one is a keeper!
Review: 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").
Rating:
Summary: Absolutely life changing.
Review: For the last year in two different companies I have been evangelizing many of the concepts in "Pragmatic Programmer", but had a hard time validating my thoughts to the more skeptical people in our group. That's over now. "Pragmatic Programmer" has given me not only the ammunition I need to wage war against some of the more Philistine ideas that I must deal with, it has added to my thoughts and made me a better leader, better communicator and a much, much better developer. Any book that tells you to step away from the keyboard before you begin is good, but this book is a masterpiece because it tells you WHY you should take a step back. Every chapter is a gem and stands alone, but taken together with the references and extremely well-written explanations, it almosts reads like a novel. I felt guilty putting it down! If you are serious about software, serious about becoming a real craftsman and a leader in your field, then this book needs to be on your shelf, dog-eared and used.
Rating:
Summary: Extraordinary contents but too bulky
Review: I can only repeat what most other reviewers said: it's an extraordinary book, a real treasure. On a scale of 1 to 5 stars, this book would deserve 6 -- but I must draw one star for the bulky design ;) Information density is high and actually the book could be a small pocket book ideal to take along everywhere. But unfortunately the publishers preferred to use big typefaces, thick paper and include a lot of empty space. They probably blowed up the book to make it heavier and look "more important" in order to sell it for a higher price. For me, they didn't hit the target because I didn't buy the thing. I swear I would spend $40 rightaway if it would be as handy as it could but for now I stick to the electronic version.
Rating:
Summary: A modern classic
Review: 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.
Rating:
Summary: A welcome kind of view
Review: "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.
Rating:
Summary: Excellent book with a good advice a day for weeks
Review: I really did like the book. It is an excellent book, a treasure chest of advice and excellent references to more reading. You can use it for reference and read it in almost any order and at any kinds of intervals.
But the field of general programming advice is so well equipped with excellent books that I can (unfortunately) only give four stars.
Rating:
Summary: Priceless
Review: 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.
|
