7 von 7 Kunden fanden die folgende Rezension hilfreich.
am 23. Juli 2000
I think almost any programmer can benefit from reading this book. The book is extremely well written and inspiring. Readers of Kent Beck and Martin Fowler will recognize much of their philosophy (see xprogramming.com). Much of the wisdom in the book is condensed into a set of rules listed at the end which makes a very good summary. So even if you have only 20 minutes you will probably walk away inspired and with new insights. What distinguishes this book from other books about programming that I have read (like the Refactoring book by Martin Fowler) is that this book generalizes principles about coding in a very convincing way (many of the principles could probably be helpful for any engineer, not only programmers). Take for example the well known principle of not duplicating code. The authors generalize this principle and say that information should never be duplicated. This means for example that you should write documentation, but the documentation should not duplicate information that is easy to extract from the code (the documentation could for example present the purpose of code and give an overview). Check out the book for many other equally interesting principles!
6 von 6 Kunden fanden die folgende Rezension hilfreich.
am 25. Juni 2000
I bought this on a friend's recommendation, but expected yet another book rehashing the same standard rules: write comments, don't duplicate code, have plans for your projects, eat your vegetables.
Hunt and Thomas vastly exceeded my expectations. This book is never dry, often humorous, and always educational. They don't always say what you expect them to say (e.g., about commenting code), and I didn't always agree with them, but every sentence is full of thoughtful analysis.
One of the best features is their incredibly practical advice -- while yes, this book does teach philosophy and encourages thought, it also provides many immediately-implementable suggestions.
If you aren't a programmer with 10 years experience, buy it anyway -- it is not just for experienced programmers. While you will absorb less of the book, there is still enough to learn, and it's a great book to keep and re-read.
The book includes a pull-out card of the pithy sayings the authors use to sum up each section. Perhaps my mind just doesn't work the way theirs does, but I didn't find their summations to be helpful all the time -- I found myself frequently having to flip back to the section to remember what a particular phrase meant. But it's still useful.
8 von 9 Kunden fanden die folgende Rezension hilfreich.
am 3. Juni 2000
...and what's the difference? I've often felt that the difference was attitude. Programmers (or "professionals" if you prefer) were continually thinking about what they did, why they did it and how they could do it better. And I don't just mean searching for a new language ("maybe I should learn Java this week?").The rest of us are just tooling around doing the best we can and wondering why it sometimes doesn't work.
"The Pragmatic Programmer" is clearly written by and for professional programmers. Reading it with attention will force you to think deeply about the way you develop software. If your first response is "but this isn't pragmatic" or "I don't have time to do these things" then I encourage you to think again. Perhaps the barrier is change itself. Sure, applying the practices in this book may slow you down in the short term (you always go slower when you're learning a new skill) but the benefits to establishing these practices as habits are enormous.
We are working through this book as part of a weekly study group at our office. This seems to be a great way to investigate things you're uncomfortable. And I don't agree with every practice in this book, but please think about them as deeply as you can before you reject them!
Whenever I interview someone I ask them what book has most influenced the way they develop software. If they answer "The Pragmatic Programmer" (or "Zen and the Art of Motorcycle Maintenance") then they have the job!
75 von 89 Kunden fanden die folgende Rezension hilfreich.
am 7. November 2005
As most other reviewers, I was drawn in by the glowing commentaries here on Amazon.
As background, I've been programming professionally for nine years now, on a variety of projects, but generally high-performance embedded stuff. I'm interested in improving my software development & management skills, and have read a number of other, better books (listed later) about these topics.
My first criticism is that the collection of 50-odd tips are simply too shallowly presented to be very interesting. Generally, if you agree, you say, "yeah, duh," and if you don't, there's no discussion of the point, and no attempt to address known difficulties with "good" practices. There also seemed to be no attempt to balance some of the points. For example, the authors repeatedly talk about writing your code so it's flexible. In general, a good idea. On the other hand, they really seem to think you should be writing everything, regardless of what sort of application it is, to run on different machines, under different operating systems, with and without concurrency, etc. This, to me, just seems foolish, extra work, extra code, extra bugs. The estimates I've seen (in other, better, books) say that just writing re-usable code takes three times more work than "normal" code, ignoring multi-platform complexities.
The old school comment (and I consider myself fairly old school) is there because they very obviously come from a Unix/command line environment. I will admit, they motivated me to improve my scripting skills, something I've been planning on doing for a while. But then they have inane advice, like "use only one editor *for everything*". This is perhaps nice, if you can, but on larger projects or organizations, this probably isn't possible. I use the IDE required by the project, a different editor for documentation (also required) and a third one for doing hex & advanced search and replace. Perhaps with emacs and 47 scripts this wouldn't be necessary, but I'm not convinced it would be efficient either.
All in all, the advice is generally good, but I think there are better books out there (e.g. Code Complete, Writing Solid Code, Rapid Development, The Mythical Man-Month, C++ Coding Standards). As a light book to get you thinking about your craft, it's not bad, but that's the best I can say about it.
2 von 2 Kunden fanden die folgende Rezension hilfreich.
am 26. Mai 2009
This book is neither actually bad or good. It makes nothing wrong but could do much better. If you count it up, is has it tells everything a good book for programmers should tell. But it's boring, shallow. And for my taste not very precise. I read Clean Code before this one. Clean Code was almost exciting. The Author conveyed the same Emotions I experienced when programming. It didn't just tell me what to do, but how to do it against all (seeming) odds and against (seeming) good advice from co-programmers. It motivated me, to do the right thing for the right reason. But this one, feels too often like they inceased the font again and again to fill the pages. The Author seems to have a felt knowledge of programming, but he fails to give reason. The rote definitions are too many and too meaningless each one for it self.
If The Pragmatic Programmer could be condensed into half the words, it might get 4 or even 5 stars but not this way.
I'm 2/3 through and I don't know whether I should finish it. I'd say read Clean Code instead. It covers almost everything this book does, but much better.
6 von 7 Kunden fanden die folgende Rezension hilfreich.
am 1. Juni 2000
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!
2 von 2 Kunden fanden die folgende Rezension hilfreich.
am 7. November 2011
Given it's age, this book is not bad, it is just plain old.
However, at least two groups of people might benefit from the book:
1.) Developers who stopped learning at the end of the 20th century
2.) Newbies, who make their first steps towards larger projects
As an active developer, you will notice how many of the touched topics have changed over the last decade: wikis are now everywhere, agile/lean processes are common, modern IDEs as Eclipse and NetBeans emerged, etc.pp.
A second (more timeless) critic: many tricks/hints and techniques are just proposed without pointing out possible negative consequences - e.g.: leaving business-logic to configuration is neat, but it needs a more complex error-checking and -handling during runtime and one also looses the checks/safety a compiler can provide before the system runs in a target-environment.
1 von 1 Kunden fanden die folgende Rezension hilfreich.
am 10. Februar 2000
As a programmer, I like to think of myself as pragmatic. Programming is the most precise discipline there is and justifies the cynical joke, "How many character changes does it take to turn 'success' into 'failure'? Answer: Only one if you are a programmer." However, pragmatic is a very subjective word, so the obvious question that any reader interested in this book would ask is, "So what criteria do the authors use to define a pragmatic programmer?"
In listing the criteria and explaining their reasoning, the authors show their depth of understanding of what is both right and wrong with the current state of the development art. Every keystroke or mouse click that we perform has a consequence, not only today, but in the future. When performing them, we should always be looking ahead to the future, whether that be thinking about how the code will be maintained, how the users will respond to what they find or how your current skill set is expanding or contracting. This eye on the future is the primary theme of the book.
The tips are kept simple, which is effective and is consistent with the secondary theme of the book. Complex systems are what we build, but in totality we cannot comprehend them. Only by breaking a project down into manageable parts can we hope to interact with it in an effective manner. Furthermore, the inertia against changes is much less severe when they are small and simple. Whether it be Ockham's razor, Einstein's statement about the simplicity of theories or simply reciting the KISS (Keep It Simple Stupid) mantra, reducing complexity is effective.
Some very good analogies are used to explain the principles, with my favorite being the broken window tale. The basic story is simple, abandoned buildings or automobiles on the street remain untouched until a window is broken. Left unrepaired, this sends a message that the object is fair game so within a very short time, vandals destroy the rest. The same thing happens in software development. Once a subpar feature is passed as acceptable, the signal to everyone is clear, and the quality of the remaining work suffers.
Granted, most of us in development are severely time challenged and have little to spare to either read or perform code clean ups. However, this is a book where the interest paid over the short and long term will dominate the initial investment. Applying even a few of these principles will help reduce the load in the future as you begin spending less time in all phases of the software cycle. It takes approximately a one percent increase in efficiency to save a half hour a week. This is a book that should be read by all programmers, especially those who wish to control their own destiny.
20 von 25 Kunden fanden die folgende Rezension hilfreich.
am 18. Mai 2000
I like to consider myself a master craftsman. My craft is that of programming. I live for programming. Programming is rarely from my thoughts. I am constantly thinking of ways to improve my craft. Learn a new skill. Develop a new tool. What went wrong? How can I do better next time?
Programming is a rapidly changing craft. A machinist can learn to work a lathe or a milling machine, and expect that his knowledge will stand him in good stead for the rest of his working life. Not so for the craftsman programmer. Ours is a new craft. We are still learning how to do it. Having survived in the game for a decade or two, and having learned dozens of languages, operating systems, database management systems, transaction processing managers, editors, we come to the realisation that this is a hard game. Each of us learns skills that help us cope with all that change. We learn basic programming skills. We go on learning them. We learn to see what is coming, and move in anticipation. We learn what is important, and what is not. We watch those who are successful, and try to emulate them. We watch the unsuccessful with horrid fascination, and try to learn from them also. "There but for the grace of God go I!"
I don't know how to make an object oriented design. I can do design sketches. So I start from there. I build my system, dealing with the problems as they arise. I rely on my experience to keep me out of trouble. When I see commonality between two classes, I take the opportunity to refactor and eliminate the commonality. I am quite happy to rewrite any piece of code to make it better. You know what happens? I end up with a well-designed system despite myself. I am an opportunistic programmer.
I saw the title of this book, and thought: "That's me!"
So I bought it. What a disappointment! It is full of platitudes. It reads like a writer's style manual. It is good to do things this way. It is a bad idea to do it that way. It has no meat to it, no depth. If you want to know more about the topics they discuss, you won't find it in this book. You won't find much of it in the references either.
Let me quote a typical example from the section entitled "Text Manipulation". "Pragmatic Programmers manipulate text the same way woodworkers shape wood ... We need a general purpose text manipulation tool ... Text manipulation languages are to programming what routers are to woodworking. They are noisy, messy, and somewhat brute force. Make mistakes with them, and entire pieces can be ruined ... in the right hands, both routers and text manipulation languages can be incredibly powerful and versatile..." What rubbish! The analogy flows on, and is followed with the advice to learn a text manipulation language, and a list of things possible with such a language. There is not one practical example.
This continues for section after section. In Appendix A: Resources, the authors say "The only reason we were able to cover so much ground in this book is that we viewed many of our subjects from a high altitude. If we'd given them the in depth coverage they deserved, the book would have been ten times longer." All I can say is that they should have covered ten times fewer subjects, to the depth of coverage they deserved.
A journeyman programmer wanting to become a master is advised to study at the side of a master. Buy Kernighan and Pike's The Practice of Programming.
4 von 5 Kunden fanden die folgende Rezension hilfreich.
am 2. November 1999
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.