The Pragmatic Programmer: From Journeyman to Master

This book provides sound, practical advice that makes sense on almost any development project. The Pragmatic Programmer is not limited to a specific niche or language – any developer can take and apply these principles. It employs a good, familiar writing style which makes the book easy to digest, and the material is quick to absorb and apply.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.

This is a great book for any programmer, full of excellent advice. The subtitle "From Journeyman to Master" is not a joke, however; notice that beginner is not included in that range. Much of the book will not make sense if you do not have a decent amount of experience with programming.The best thing I can say about the book is this: If you are not already following the advice in this book you are not programming up to your potential. If you read, understand, and implement the practices in this book you will write better software. It's not some load of theoretical crap, either; it's real advice for solving real problems. Good for programmers who care about getting work done today instead of sitting around talking about what they'll do tomorrow.

How many have I read? Cover-to-cover, none except this one. But I've had a habit of leafing through software books for the past 15 years and collecting ones that interest me.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.