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.

Pragmatic Programmer touches on many excellent software development practices and design methodologies, although there is not much depth on any one topic. If I had read it much earlier in my career, I think I would have learned a lot more from it. But I've been developing for 12+ years now, and I've already picked up on nearly everything this book had to say. I guess I already was a "Pragmatic Programmer". I found myself skimming a lot of the sections and whispering to myself, "Yeah, yeah, good stuff. I know this already."The book is very readable, although it lacks personality. Not dry, just impersonal. It has a lot of "We think this, we think that..." but I kept asking myself, who is "we"? What experiences informed these points of views? How long have the authors been developing code, and in what subspecialties? Sure, some of this information about the authors can be looked up. But I'd rather have seen some of these details come out in the text of the book itself, in the course of explaining their points of view.

I have looked at this title in the listings for many years, but for some reason it was never the one I bought. I should have bought this a long time ago! My bad.Better late than never, they say, and that's definitely true of this title. It bears its age remarkably well. In fact, only minutiae makes it look old by any standard.The book is a long list of carefully explained sections that are ultimately summarised as a set of tips. If you have ever read Scott Meyers' work on Effective C++ you sorta get the idea. However, where Scott is intimately involved with using C++, Andrew Hunt and David Thomas are concerned with general approaches to development. What to do. What not to do. In general. And specifics. Regardless of your chosen programming language.The book's age only shows when they talk about concrete technologies; Java was new and shiny at the time. eXtreme Programming was around, but Agile was not. C++ had only just been standardised for the first time. There was no subversion, let alone mercurial or git.These age symptoms are irrelevant though, because any technology is only used in very short snippets, and only to demonstrate a point.So, what's in here? You'll find guidelines such as "Learn a new programming language every year," "Keep knowledge in plain text," "Don't program by coincidence," and "Gently exceed your users' expectations." You'll also find a thorough discussion of why these guidelines are important.The style is informal without getting chatty. The authors exhibit a dry sense of humour that makes the reading go smooth at all times.Anyway, you gotta love it when the authors' remind you that perl can be used to manipulate text, host web pages, do math and write program source that looks like Snoopy swearing.This one is going to be a stable. All serious programmers, regardless of language, platform or technology, should read this.