Take a photo of a barcode or cover
226 reviews for:
The Pragmatic Programmer: 20th Anniversary Edition, 2nd Edition
David Thomas, Andrew Hunt
4.22 AVERAGE
226 reviews for:
The Pragmatic Programmer: 20th Anniversary Edition, 2nd Edition
David Thomas, Andrew Hunt
4.22 AVERAGE
Read this while switching careers to become an engineer from product management, because many people and blogs encouraged it.
It's a late 90s book that was probably way ahead of its time when it came out. Some of the concepts in it are so widespread today that they may seem trivial. Some parts are oddly specific and have dated, but much of the remaining advice is solid. This book can be a decent stand-in for people who don't have a senior mentor, or are studying alone.
The premise is that pragmatic programmers are holistic programmers - true professionals. They think deeply about the code they write and how they write it, the people who will read it, and the business they work for. They actively engage with all of the above with a view to making things better. This is different to people and organizations I've seen, where engineers relegate themselves to "just technology" or "writing the code" because the rest is "(business) bullshit".
My favorite part was a chapter that suggests our metaphors for explaining programming are flawed: business people see programming as analogous to building, which suggests a few neat and distinct phases: surveying, bringing in architects, building the house, owners moving in, and the owners reporting issues to their building manager. The authors suggest planning is more akin to gardening: a process that entails tending your garden every day, replanting, trying different seeds and varietals, sometimes rethinking the entire garden depending on season, climate, or the whims of the house owner.
If you read it and take away the philosophy behind the mentality, I'd say it's still a good book in 2020.
It's a late 90s book that was probably way ahead of its time when it came out. Some of the concepts in it are so widespread today that they may seem trivial. Some parts are oddly specific and have dated, but much of the remaining advice is solid. This book can be a decent stand-in for people who don't have a senior mentor, or are studying alone.
The premise is that pragmatic programmers are holistic programmers - true professionals. They think deeply about the code they write and how they write it, the people who will read it, and the business they work for. They actively engage with all of the above with a view to making things better. This is different to people and organizations I've seen, where engineers relegate themselves to "just technology" or "writing the code" because the rest is "(business) bullshit".
My favorite part was a chapter that suggests our metaphors for explaining programming are flawed: business people see programming as analogous to building, which suggests a few neat and distinct phases: surveying, bringing in architects, building the house, owners moving in, and the owners reporting issues to their building manager. The authors suggest planning is more akin to gardening: a process that entails tending your garden every day, replanting, trying different seeds and varietals, sometimes rethinking the entire garden depending on season, climate, or the whims of the house owner.
If you read it and take away the philosophy behind the mentality, I'd say it's still a good book in 2020.
The second edition is an enjoyable read, but it’s more like a high level self help book to me:)
A very resourceful book that has earned its status as a classic. It's an all-encompassing brew of topics, including personal philosophy, team psychology, coaching in how to think as a developer, but also techniques and practices to utilize as a developer. Without assuming knowledge in any particular language or framework of thought, this book steams you ready to be resilient for whatever the future may bring.
The first few chapters were a little dry for a technical person like myself, but there were some very important facts that my experienced self needed to be reminded of. In the topic "Software Entropy", one of my dearest values is emphasized: if you leave something small broken, this will lead to more disaster in a snowballing effect. I value quality of code very highly, and in a competitive (albeit friendly) working environment it can be hard sometimes to assert yourself. It's nice to be reinforced in my beliefs and convictions by a classic book written by world famous revolutionaries.
Some other tip I highly appreciate are to keep a journal of your technical challenges. It's hard to start doing it, but it is a great way to learn, and not forget about your lesson.
At the heart of this book however, is the "ETC" principle: make your code easier to change. There's many acronyms and ways to achieve this, but ultimately that's what matters, especially in the highly dynamic and evolving world of today. It connects perfectly to the agile mindset they preach, and that many teams these days use: start small and iterate soon and often. We have learned that is to be expected that the requirements are incomplete, faulty or changing, and the same goes for the code. It is subject to change all the time, for all sorts of reason, and if it's easy to change, then you have combatted one of the biggest problems in the trade.
The nuanced differentiation between prototypes and what they have dubbed tracer bullets is very useful as well. Prototyping is intended to explore, or to prove a concept, and it should then be dismissed. If your prototype doesn't feel like it can be trashed easily, you probably put to much effort and detail into it.
Only when your prototype has proven that the concept works, or that the client is happy with the set goal, only then do you proceed to build the actual code. This, you also do incrementally of course, and the suggestion they make is fantastic. Instead of starting to build one component after another (or simultaneously in the case of several people), they suggest to start with writing some feature that hits every part of the program. This is what they call a "tracer bullet", since it gives you a sense of where you're going. Imagine having some feature that hits the database, backend logic and frontend logic (for example). You have the benefit of having their co-operation implemented and therefore proven, which allows for iterations of improvement and expansion in a way that's more operational and therefore testable at a more conceptual level. It is easier to fail fast, and re-iterate.
Again, the first few chapters are especially useful for beginning developers, but starting from chapter 4 there's a good chance you'll learn something new as an experienced developer. I was only vaguely familiar with the idea of "Assertive Programming", and was happy to see examples of "Design By Contract" in other languages such as Clojure.
As far as the more technical chapters go, I believe chapter 5 is the most challenging, packed and important chapter. It's here where they lay out the "Tell, Don't Ask" principle which is crucial for a well-encapsulated component/system. By telling what you need (give me the users who used a discount in the last month) instead of asking for it (can I have the users please, oh, and now I'd like to get all the orders they made, filtered by those who had a discount, ...) you minimize how much the consumer of a provider (a module, API, etc.) is supposed to know about the internal implementation of that provider. This looses coupling, and improves maintainability.
In chapter 5, important lessons about the caveats with inheritance ("Inheritance Tax") are discussed, as well as a completely different mindset (the one used in Functional Programming) to approach your application as a series of data transformations ("Transformative Programming"). Lastly, they explain Finite State Machines as a tool to build applications in a more declarative way. They expand on this with the Observer Pattern, which is expanded upon further in chapter 6 ("Concurrency").
I love how many different methodologies and techniques the book knows to bundle into a relatively small book. One surprising example that I think is (sadly) quite niche is that of "Property-Based Testing", a technique that allows the generation of test data based on the declaration in properties (invariants and post-conditions). This is an incredibly useful technique for certain types of applications, and it's great they expose many people to it in this book.
There's so much more to say, but I'll conclude by praising the authors with their incredible book. They understand how learning works, how psychology works, and no less importantly, what the software development trade is about. They managed to write a book that's a perfect mix of a reference and a (superficial) teaching textbook, making it suitable for reading from start to finish, as well as for referencing tips/parts at some other time.
They approach pragmatism and agility from first principles, without the buzzwords and fake layer. The topic of superficial and fake agility is even treated in the book as a problem, which I greatly appreciate.
If you want to learn some fundamental principles to become a professional, resilient and future-proof developer, be sure to pick this great classic up!
The first few chapters were a little dry for a technical person like myself, but there were some very important facts that my experienced self needed to be reminded of. In the topic "Software Entropy", one of my dearest values is emphasized: if you leave something small broken, this will lead to more disaster in a snowballing effect. I value quality of code very highly, and in a competitive (albeit friendly) working environment it can be hard sometimes to assert yourself. It's nice to be reinforced in my beliefs and convictions by a classic book written by world famous revolutionaries.
Some other tip I highly appreciate are to keep a journal of your technical challenges. It's hard to start doing it, but it is a great way to learn, and not forget about your lesson.
At the heart of this book however, is the "ETC" principle: make your code easier to change. There's many acronyms and ways to achieve this, but ultimately that's what matters, especially in the highly dynamic and evolving world of today. It connects perfectly to the agile mindset they preach, and that many teams these days use: start small and iterate soon and often. We have learned that is to be expected that the requirements are incomplete, faulty or changing, and the same goes for the code. It is subject to change all the time, for all sorts of reason, and if it's easy to change, then you have combatted one of the biggest problems in the trade.
The nuanced differentiation between prototypes and what they have dubbed tracer bullets is very useful as well. Prototyping is intended to explore, or to prove a concept, and it should then be dismissed. If your prototype doesn't feel like it can be trashed easily, you probably put to much effort and detail into it.
Only when your prototype has proven that the concept works, or that the client is happy with the set goal, only then do you proceed to build the actual code. This, you also do incrementally of course, and the suggestion they make is fantastic. Instead of starting to build one component after another (or simultaneously in the case of several people), they suggest to start with writing some feature that hits every part of the program. This is what they call a "tracer bullet", since it gives you a sense of where you're going. Imagine having some feature that hits the database, backend logic and frontend logic (for example). You have the benefit of having their co-operation implemented and therefore proven, which allows for iterations of improvement and expansion in a way that's more operational and therefore testable at a more conceptual level. It is easier to fail fast, and re-iterate.
Again, the first few chapters are especially useful for beginning developers, but starting from chapter 4 there's a good chance you'll learn something new as an experienced developer. I was only vaguely familiar with the idea of "Assertive Programming", and was happy to see examples of "Design By Contract" in other languages such as Clojure.
As far as the more technical chapters go, I believe chapter 5 is the most challenging, packed and important chapter. It's here where they lay out the "Tell, Don't Ask" principle which is crucial for a well-encapsulated component/system. By telling what you need (give me the users who used a discount in the last month) instead of asking for it (can I have the users please, oh, and now I'd like to get all the orders they made, filtered by those who had a discount, ...) you minimize how much the consumer of a provider (a module, API, etc.) is supposed to know about the internal implementation of that provider. This looses coupling, and improves maintainability.
In chapter 5, important lessons about the caveats with inheritance ("Inheritance Tax") are discussed, as well as a completely different mindset (the one used in Functional Programming) to approach your application as a series of data transformations ("Transformative Programming"). Lastly, they explain Finite State Machines as a tool to build applications in a more declarative way. They expand on this with the Observer Pattern, which is expanded upon further in chapter 6 ("Concurrency").
I love how many different methodologies and techniques the book knows to bundle into a relatively small book. One surprising example that I think is (sadly) quite niche is that of "Property-Based Testing", a technique that allows the generation of test data based on the declaration in properties (invariants and post-conditions). This is an incredibly useful technique for certain types of applications, and it's great they expose many people to it in this book.
There's so much more to say, but I'll conclude by praising the authors with their incredible book. They understand how learning works, how psychology works, and no less importantly, what the software development trade is about. They managed to write a book that's a perfect mix of a reference and a (superficial) teaching textbook, making it suitable for reading from start to finish, as well as for referencing tips/parts at some other time.
They approach pragmatism and agility from first principles, without the buzzwords and fake layer. The topic of superficial and fake agility is even treated in the book as a problem, which I greatly appreciate.
If you want to learn some fundamental principles to become a professional, resilient and future-proof developer, be sure to pick this great classic up!
As a work of writing, "The Pragmatic Programmer" provides illustrative stories to teach concepts, presents ideas in an organized and easy-to-follow manner.
As a work of audio, I love the use of different speakers to create engagement. Furthermore, the audiobook does a fantastic job of making changes to code examples presented in the book to accommodate listeners.
Not only is this an exceptional technical guide for good programming (and it's extremely thorough, even highlighting important topics such as teamwork, client satisfaction, and ethics), this may be one of the best audiobooks I've ever listened to.
As a work of audio, I love the use of different speakers to create engagement. Furthermore, the audiobook does a fantastic job of making changes to code examples presented in the book to accommodate listeners.
Not only is this an exceptional technical guide for good programming (and it's extremely thorough, even highlighting important topics such as teamwork, client satisfaction, and ethics), this may be one of the best audiobooks I've ever listened to.
There is nothing wrong with the content of this book (except it's slightly outdated in places, referring to long dead tools). I can absolutely see how this might've completely changed how some programmers approached their craft... in 1999, when it came out.
However, as a programmer dabbling since childhood and starting my professional career in 2016, I already knew pretty much everything described in the book, just through occasionally reading a blog or two, or browsing /r/programming every once in while.
However, as a programmer dabbling since childhood and starting my professional career in 2016, I already knew pretty much everything described in the book, just through occasionally reading a blog or two, or browsing /r/programming every once in while.
Nothing to say or criticize about the content itself, the best practices and tips included are a must to follow. But overall way too general, useful just for beginners to read in the library, and of very limited utility beyond that.
A great resource
All of the unspoken aspects of software development study skills. And as checklist of hard skills to acquire. I really enjoyed this and will constantly revisit
All of the unspoken aspects of software development study skills. And as checklist of hard skills to acquire. I really enjoyed this and will constantly revisit
informative
medium-paced
A timeless book that's always a good idea to reread every few years to remind you of the basics that improve your coding and save time in the long run.