on December 5, 2000
This is a decent but not spectacular book, which is written as a series of 46 five to ten page articles on various programming topics, such as "Orthogonality", "Design by Contract" and "The Requirements Pit". The segments are quite heavily cross-referenced (which I didn't find very useful).
The authors dole out a lot of solid advice, which is the book's strength. I found myself disagreeing with very little. There are memorable tips and some good stories. The writing style is also very accessible and conducive to diving in at any page.
The book seems a bit lightweight. The exercises are a little simple and I don't think you'll find yourself going back to this book a lot. Also, the typeface is annoyingly large.
I'd recommend this to someone who has done some programming and understands the syntax and fundamentals but hasn't gotten into programming larger pieces of software. I think that if you have programmed anything significant you won't find much new in here.
on December 14, 2000
this book sat on my "to read" list for months and i finally picked it up based on the strength of reviews here on Amazon. what a disappointment!! the world really doesn't need another book extolling the virtues of thorough upfront design and intense testing without any specific (or even vague) plans for overcoming the traditional difficulties in realizing both those objectives. yeah yeah we know, if we dont design enough up front, we will pay in the long term anyway. enough, already. i was hoping for some creative and interesting ideas and was utterly disappointed. this book is no more than a crude compilation of half-baked ideas from any number of other similar books.
if you're looking for something interesting, "the mythical man month" is a lot better, even though its dated. "inmates are running the asylum" by alan cooper is also great in that it creatively and productively challenges many of the old saws that books like "pragmatic programmer" trot out time and time again (i particularly like Cooper's rant against letting customers dictate design decisions and product paths).
on February 15, 2012
There is a great number of positive reviews for this book, and rightfully so, however there are some critics with a good deal of experience in programming that seem to have some majors problems with it. I believe it comes down to this: it is packed full of common sense and great tips but it's all advice that anyone that has had a few years of experience will probably have picked up already. I wish I had come upon this book as I was entering the job market, but most of it just made me nod in agreement. While I didn't get the epiphany other books managed to provide, even for an experienced programmer, it is good to be reminded of those sound advices and of why exactly we do the things we do the way we do them.
All the tips are covered superficially, but with enough depth that you understand the what and the why, and can still go to the next one quickly. Further chapters don't depend on previous ones, so you can jump in at any topic that interests you. As such, it makes a good a-tip-a-day read.
While the main advice it provides is simply "care about your craft", it is advice I wish more would follow and this book just might convince some and teach the beginners some of what that actually entails. In the end, the simplicity of this book is what makes it such an interesting read.
The font is indeed a bit too big to be comfortable on the eyes, but the chapters are short enough that you aren't forced to strain for hours. The layout of the chapters also seems a bit random.
on December 24, 2001
I read the glowing reviews here and then browsed it at the bookstore...where it looked pretty good...When I took it home and started reading it, a different picture evolved...Here are a few nuggets:
1. Much of what the authors espouse is just common sense and would be picked up or developed by most bright developers on their own.
2. Some of what the authors espouse is just wrong...we have suggestions that if your code is correct then it will take little effort to make it run on Win16, Win 32 , and different flavors of Unix or whatever environment. I disagree. This would only be true for the most trivial programs. Even using a factory pattern, as opposed to the usual compiler switches, one could build such a losely coupled and modern system to run on different environments...but it would hardly be easy to do because the different environments require separate (and hardwon!) skillsets/knowledge...not easy to find in one developer...Perhaps the authors should try their hand on some cross-browser, cross operating system DHTML...and make sure it runs on all versions of Netscape to boot.
3. The authors elevating of the text editor and command line over IDE is just non-sense...and again wrong...they say you cannot configure the IDEs...anyone who has written an add-in for VB knows it is indeed possible.
4. I could go on, but I will conclude with their total lack of understanding of Physics which they quote wrongly...the Universe does not split(Shroedinger's cat) after a measurement and Heisenberg said it was ,IN PRINCIPAL, impossible to perform certain measurements without disturbing the system...On the other hand, it is perfectly possible to perform debugging without disturbing the code...
5. And they have the audacity to call their book "...from journeyman to master."
Having said all of that, there are good ideas to provoke one's computing thinking in this book...and so while I would recommend it, just be careful to examine their suggestions critically before adopting them.
on September 13, 2000
The reviews I read about this book are pretty accurate, except this book is too wordy. It could be 1/2 the size it is if the authors would have gotten to the point faster. A lot of explanations go on and on and I am left wondering when am I going to get to read what the point is?! Get to it!
The two authors are certainly qualified to author this book, judging by what their backgrounds are. For the most part, the chapters are interesting, informative, and thought provoking. Most of the ideas are not what the average, or above average programmer would think of.
Some of the ideas though are not worth the paper to print them on, and many of them are not explained well enough. Given the amount of words for explanations, this should not have been. Therefore, I can only give this book three stars. Overall I feel that the book is too drawn out and not to the point enough.
on April 2, 2006
The Pragmatic Programmer: From Journeyman to Master, is a must-read for everyone involved in the software industry. The tone of this book is casual and often humorous making it fun, enjoyable and easy to read.
As the title implies, this book is targeted towards the programmer (the construction phase of software engineering). The authors outline common sense principals and practices that every developer SHOULD be aware of (but in reality most of these practices are overlooked).
These principals are often obvious, but keep in mind that "the obvious [...] is never seen until someone expresses it simply." (Kahlil Gibran) The authors express good program principals, outline the collection of tools every practitioner should have, and offer priceless advice in a simple manner.
This book left me with many unanswered questions, the authors offered a lot of "How-Tos" and "What-Tos" with out answering the "Whys". Code Complete [Steve McConnell] answers most (if not all) of these questions and in doing so, is three times the size. The Pragmatic Programmer makes an excellent prerequisite to Code Complete. Both books should be read.
It's interesting to note that both authors (Andrew Hunt, David Thomas) are authors of the Agile Manifesto, and have a series of Pragmatic Programming books (Pragmatic AJAX, Agile Web Development With Rails, Programming Ruby, etc...).
Their other texts are equally humorous and easy to read.
The Pragmatic Programmer must simply be read and then re-read, I can attest "this book will help you become a better programmer" (Preface).
on November 28, 1999
The Pragmatic Programmer is a mixed bag. It attempts to cover a large number of broad topics, ranging from object-oriented design to algorithm speed to testing strategies. As a result, each topic gets a fairly superficial treatment, only skimming the surface before moving onto something else.
My other reservation about the book is that the authors are "Unix geeks", and view the world accordingly. They touch on Windows mostly to urge readers to put a Unix shell on top of it; other platforms like Mac OS are mentioned not at all. Personally, I am tired of "real programmers use the command line", or "Emacs is God" posturing (despite the authors' earnest but flawed attempts to justify these), and felt it detracted from an otherwise useful book. Worse, the authors fail to discuss any tools related to building complex interactive applications, a significant omission from the stated goals and scope of the book.
Those complaints aside, the book does contain useful information and ideas, especially for new programmers who often don't have a strong grasp on the bigger picture of software development. The authors offer good insights on topics like design by contract, documentation, and refactoring, which new programmers often fail to appreciate.
on May 22, 2009
Many experienced programmers will have already learned many of the lessons in this book and will be frustrated by the lack of depth. I was hoping for more detail in many sections but as I have not really been programming professionally (after entering management) for a number of years there were a few tidbits, or reminders that encouraged me to go look elsewhere for more detail.
For a new programmer there is a lot in this book to offer. Communication is covered in the first chapter and this is certainly an area that many junior programmers/designers have when first starting out. Orthogonality, how to deliver an estimate, writing your own code generators, and so on are all concepts that many programmers, for whatever reasons, haven't been exposed to.
So, don't buy this if you are looking for more details (i.e, the proper way to write a good unit test)... you'll need to go elsewhere for that. But if you want a decent framework of good methodology, this is worth a look
on May 17, 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.
on December 13, 2003
If you actually like programming. If you don't think programming by horde is a good idea. Or if you aren't looking at it as a stepping one to management. Then you need to read this book. It will make you think about your profession in a whole new light, as a skill and a discipline. After the wave of horde programming J2EE nightmares has passed and there is still real work to be done by programmers it is people who look at programming as a life-long skill who will be left to build the interesting stuff. Get involved. Get on-board. Enjoy programming. Read this book.