Follow the Authors
The Pragmatic Programmer: From Journeyman to Master 1st Edition
There is a newer edition of this item:
From the Publisher
Some of the authors' nuggets of pragmatism are concrete, and the path to their implementation is clear. They advise readers to learn one text editor, for example, and use it for everything. They also recommend the use of version-tracking software for even the smallest projects, and promote the merits of learning regular expression syntax and a text-manipulation language. Other (perhaps more valuable) advice is more light-hearted. In the debugging section, it is noted that, "if you see hoof prints think horses, not zebras." That is, suspect everything, but start looking for problems in the most obvious places. There are recommendations for making estimates of time and expense, and for integrating testing into the development process. You'll want a copy of The Pragmatic Programmer for two reasons: it displays your own accumulated wisdom more cleanly than you ever bothered to state it, and it introduces you to methods of work that you may not yet have considered. Working programmers will enjoy this book. --David Wall
Topics covered: A useful approach to software design and construction that allows for efficient, profitable development of high-quality products. Elements of the approach include specification development, customer relations, team management, design practices, development tools, and testing procedures. This approach is presented with the help of anecdotes and technical problems.
From the Publisher
Simply put, this book tells you how to program in a way that you can follow. You wouldn't think that that would be a hard thing to do, but it is. Why? For one thing, not all programming books are written by programmers. Many are compiled by language designers, or the journalists who work with them to promote their creations. Those books tell you how to talk in a programming language---which is certainly important, but that is only a small part of what a programmer does.
What does a programmer do besides talk in programming language? Well, that is a deeper issue. Most programmers would have trouble explaining what they do. Programming is a job filled with details, and keeping track of those details requires focus. Hours drift by and the code appears. You look up and there are all of those statements. If you don't think carefully, you might think that programming is just typing statements in a programming language. You would be wrong, of course, but you wouldn't be able to tell by looking around the programming section of the bookstore.
In The Pragmatic Programmer Dave and Andy tell us how to program in a way that we can follow. How did they get so smart? Aren't they just as focused on details as other programmers? The answer is that they paid attention to what they were doing while they were doing it---and then they tried to do it better.
Imagine that you are sitting in a meeting. Maybe you are thinking that the meeting could go on forever and that you would rather be programming. Dave and Andy would be thinking about why they were having the meeting, and wondering if there is something else they could do that would take the place of the meeting, and deciding if that something could be automated so that the work of the meeting just happens in the future. Then they would do it.
That is just the way Dave and Andy think. That meeting wasn't something keeping them from programming. It was programming. And it was programming that could be improved. I know they think this way because it is tip number two: Think About Your Work.
So imagine that these guys are thinking this way for a few years. Pretty soon they would have a collection of solutions. Now imagine them using their solutions in their work for a few more years, and discarding the ones that are too hard or don't always produce results. Well, that approach just about defines pragmatic. Now imagine them taking a year or two more to write their solutions down. You might think, That information would be a gold mine. And you would be right.
The authors tell us how they program. And they tell us in a way that we can follow. But there is more to this second statement than you might think. Let me explain.
The authors have been careful to avoid proposing a theory of software development. This is fortunate, because if they had they would be obliged to warp each chapter to defend their theory. Such warping is the tradition in, say, the physical sciences, where theories eventually become laws or are quietly discarded. Programming on the other hand has few (if any) laws. So programming advice shaped around wanna-be laws may sound good in writing, but it fails to satisfy in practice. This is what goes wrong with so many methodology books.
I've studied this problem for a dozen years and found the most promise in a device called a pattern language. In short, a pattern is a solution, and a pattern language is a system of solutions that reinforce each other. A whole community has formed around the search for these systems.
This book is more than a collection of tips. It is a pattern language in sheep's clothing. I say that because each tip is drawn from experience, told as concrete advice, and related to others to form a system. These are the characteristics that allow us to learn and follow a pattern language. They work the same way here.
You can follow the advice in this book because it is concrete. You won't find vague abstractions. Dave and Andy write directly for you, as if each tip was a vital strategy for energizing your programming career. They make it simple, they tell a story, they use a light touch, and then they follow that up with answers to questions that will come up when you try.
And there is more. After you read ten or fifteen tips you will begin to see an extra dimension to the work. We sometimes call it QWAN, short for the quality without a name. The book has a philosophy that will ooze into your consciousness and mix with your own. It doesn't preach. It just tells what works. But in the telling more comes through. That's the beauty of the book: It embodies its philosophy, and it does so unpretentiously.
So here it is: an easy to read---and use---book about the whole practice of programming. I've gone on and on about why it works. You probably only care that it does work. It does. You will see. --Ward Cunningham
- ASIN : 020161622X
- Publisher : Addison-Wesley Professional; 1st edition (October 30, 1999)
- Language : English
- Paperback : 352 pages
- ISBN-10 : 9780201616224
- ISBN-13 : 978-0201616224
- Item Weight : 1.33 pounds
- Dimensions : 9.2 x 7.4 x 0.9 inches
- Best Sellers Rank: #441,066 in Books (See Top 100 in Books)
- Customer Reviews:
About the authors
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
There are many classics, like "The C Programming Language," or Knuth's "The Art of Computer Programming" series. Then there are modern classics, such as "Design Patterns," and more recently "Learn Python the Hard Way." But this book excels them all in several ways.
The programming world has long-lacked a normal approach to itself for outsiders. This is why so many programmers are self-taught. We work in a budding field that still hasn't come of age. If the authors continue to revise and improve this work, I would go so far as to say this might the _the_ classic for introducing practical-minded outsiders to the befuddling world of computer programming.
I've always been a geek at heart, but my interests expanded easily past computers to things I can understand better. I found programming books verbose and filled with not enough "why" answers, except when those "why" answers served as rationalization for the author imposing their bias and subjective understanding of various problems onto your entire view of computer science.
The Pragmatic Programmer does not do this. It assumes you are intelligent and can think for yourself about problems, and need help solving them, but not necessarily to be told _how_ to solve them. So much of "teaching" software development is just faulty teachers trying to impose implicit software paradigms on incomplete problems and expecting you, the learner, to be not only satisfied with the completeness of their answer, but to understand why they picked the particular subjective approach that they did.
In truth, this happens in all fields, but it gets especially religious in the field of computer programming. Most people apply the reverse of the sour-grapes fable from Aesop to their own programs. In other words, "My programming grapes are so juicy and sweet that everyone else's in comparison taste quite sour."
Programmers love to take the religious experience of making a computer do something and assume that they should be all-powerful just because they figured out an effective, repeatable way to solve a problem. News flash: There are 1000 ways to tell a computer to do the same thing in 1000 different programming languages. The real test is not whether your software works, but if it works well enough given the constraints you faced in creating it.
So few people understand this and think it's just about the code. It's not about the code, it's about problem solving, and not just formal problem solving, but real-world and practical problem solving. What problem does your software solve, and does it solve it the most effective way you can think of? If you've been frustrated by the approach of most software books, you should give this one a try.
Thomas and Hunt present content that is useful for everyone from the novice to the expert. They organize their advice into approximately 46 topics that cover a wide range of programming best practices. The tips build on each other throughout and are loosely categorized so that tips on similar themes are grouped together. To get the most out of it, I suggest reading the whole book, or at least sizeable sections, beginning to end to clearly see how they integrate. However, because there are so many tips, integrating them all at once initially may be difficult. It’s easy to bite off more than you can chew here, so perhaps a good starting point is to begin with the tips that are most relevant for you and branch out from there. A couple of sections resonated strongly with me:
1) A useful practice that I operate by and push my developers to operate by is refactoring (Chapter 6 – “While You Are Coding”, p. 184). This book provides a framework for the appropriate mindset to take on how to handle and maintain a code base. In refactoring, you don’t relate the software so much to a construction project but to creating and maintaining a garden – code is dynamic and its environment is ever changing. You’ll need to adapt and adjust code as the project moves along, and developers need to operate from the mindset that they’ll need to change things and adapt their code as they proceed.
2) Another practice that I follow extensively is Design by Contract (Chapter 4 – “Pragmatic Paranoia”, p. 109), or the idea that you build/structure elements to a defined contract. This could be a contract between systems, classes, or even functions. I use this approach with both my local developers and external developers, and this book gives a good framework and guidelines on how applications and classes need to work. For example, I can define a contract for how a base class and its subclasses need to work and interact, and then work with a developer to provide the specific implementation for that class. I also use this approach for APIs when coordinating with an external team to handle an exchange of data.
I’m a software architect and developer with over 20 years of industry experience across a number of languages and systems, and I’ve completed hundreds of projects both individually and with technical and cross-disciplinary teams of varying sizes. Most of the subjects covered in this book are best practices I look for or insist on establishing on my projects to ensure work moves along smoothly during development. This book covers the spectrum – it’s equally useful to me, my project managers and developers, and those just getting into our industry. It’s a solid book to return to every once in a while to make sure you’re in alignment with best practices. I highly recommend it to both new and experienced developers. I hope it helps you as much as it’s helped me.
But if it is for you, you'll be glad you gave it a chance. I usually peruse negative reviews before I make a book purchase. They don't always sway me away from making a purchase and this is one case where I'm very grateful they didn't. Your milage may vary. If you're unsure, checkout the "Look Inside" feature. If that doesn't tilt the scale one way or the other, you might try your local library's copy before committing to a purchase if you think you may lean more to the negative reviews side of the aisle. I actually purchased this book in January of 2018 and read a little past "Tracer Bullets" which really resonated with be. Then I got busy with other things and "The Pragmatic Programmer" sat on the shelf for awhile. Well, I've taken it up again and am going through it slowly, savoring every bit. My thanks and appreciation to the authors, Andrew Hunt and David Thomas! Excellent book!
As far as the "...common sense tips...etc." from the negative review excerpt above, you can gain all that "common sense" the hard way (unless it just intrinsically dwells in you), or you can let this book put you on the trail and enjoy the journey with some great insights.
This book will always hold a prominent place on my computer science bookshelf. If I had known how much I would love programming in the beginning, this is a book I wish would have crossed my path much sooner. Thanks again Andrew Hunt and David Thomas!