I might be too dramatic, but after finishing this masterpiece I feel sad. The sadness you feel after finishing a wonderful journey. I learned a lot by reading the book, and enjoyed while doing it. I can recommend it without any afterthought, it is simply a must read for anyone involved in programming and technology, from the novice to the expert. The philosophy of the book goes beyond the art of programming, and many lessons can be extrapolated into every day life.

it was a great experience reading this book, i really love how the author explain hard programming jargons with easy to understand real life examples, frequently I quote some paragraphs from this book to my manager which it no from IT field and he understands it better when I use examples from this book.

Full of fun advice and interesting anecdotal cases.

Terrific book.

Great thing explained in the most pragmatic way possible. Due to its usage of metaphors, easy-to-read language, it read like a breeze.

I might have forgotten some of the great stuff in it, might actually reread it soon.

Šią knygą privalėjau perskaityti būdamas pirmame kurse. Gaila, kad tuo metu nepasitaikė po ranka.

It's a great book if you're a comp. sci. sophomore in 1995.

I didn't like the structure of the book. Some of the concepts were vaguely presented. I was also bored a little bit while reading it.


Some notes
Chapter 1. A Pragmatic Philosophy
Tip 3: Provide Options, Don't Make Lame Excuses
Before you approach anyone to tell them why something can't be done, is late, or is broken, stop and re-evaluate
Tip 4: Don't Live with Broken Windows
Don't leave "broken windows" (bad designs, wrong decisions, or poor code) un-repaired
Tip 5: Be a Catalyst for Change
Start with something, (hot water with stones to make a soup) and slowly people will be adding ingredients to your water and see how useful it can be
Tip 6: Remember the Big Picture
Constantly review the project, look out for the big pig picture, things can deteriorate pretty fast
Tip 7: Make Quality a Requirements Issue
Good software today is better than perfect or great software tomorrow, give your users something to play with and evolve from there
Tip 8: Invest Regularly in Your Knowledge Portfolio
Learn a new language, read a technical book every quarter, read non-technical books too, take classes, participate in local user groups, stay current, experiment with different environments
Tip 9: Critically Analyze What You Read and Hear
Tip 10: It's Both What You Say and the Way You Say It


Chapter 2. A Pragmatic Approach
Tip 11: DRY—Don't Repeat Yourself
Duplication can happen when it’s imposed by the environment, when developers don’t realize they’re duplicating code, when we get lazy, code duplicated across different teams
Tip 12: Make It Easy to Reuse
Through the following:
Tip 13: Eliminate Effects Between Unrelated Things (Orthogonality)
unrelated modules should be self-contained and independent, if you change one, the others shouldn’t change dramatically
Tip 14: There Are No Final Decisions (Reversibility)
Tip 15: Use Tracer Bullets to Find the Target
get the code out there
Tip 16: Prototype to Learn
Prototyping is a learning experience. Its value lies not in the code produced, but in the lessons learned. That's really the point of prototyping.
Tip 17: Program Close to the Problem domain
Tip 18: Estimate to Avoid Surprises
Tip 19: Iterate the Schedule with the Code


Chapter 3. The Basic Tools
Tip 21: Use the Power of Command Shells
Learn some shell
Tip 22: Use a Single Editor Well
Tip 23: Always Use Source Code Control
Tip 25: Don't Panic
Tip 27: Don't Assume It—Prove It
Tip 28: Learn a Text Manipulation Language


Chapter 4. Pragmatic Paranoia
Tip 30: You Can't Write Perfect Software
Tip 31: Design with Contracts
The caller must not pass variables which violate the conditions (example: sending negative numbers to sort). It’s not the responsibility of the method itself.
Tip 32: Crash Early
Tip 33: If It Can't Happen, Use Assertions to Ensure That It Won't
Tip 34: Use Exceptions for Exceptional Problems


Chapter 5. Bend or Break
Tip 36: Minimize Coupling Between Modules
By following the law of Demeter: (a function should only act on it’s parameters, objects it creates, methods in the object it creates)
Symptoms of ill-code: (Developers afraid of changing the code because they’re aren’t sure what might be affected)
Tip 37: Configure, Don't Integrate
Tip 41: Always Design for Concurrency
Tip 42: Separate Views from Models


Chapter 6. While You Are Coding
Tip 44: Don't Program by Coincidence
plan, document, test
Tip 45: Estimate the Order of Your Algorithms
Tip 46: Test Your Estimates
Tip 47: Refactor Early, Refactor Often
"Don't try to refactor and add functionality at the same time.”
“Make sure you have tests first!"
Tip 48: Design to Test
When you design a module, or even a single routine, you should design both its contract and the code to test that contract
Tip 49: Test Your Software, or Your Users Will
Tip 50: Don't Use Wizard Code You Don't Understand


Chapter 7. Before the Project
Tip 51: Don't Gather Requirements—Dig for Them
Tip 52: Work with a User to Think Like a User
Tip 53: Abstractions Live Longer than Details
Tip 55: Don't Think Outside the Box—Find the Box
Is there an easier way?
Are you trying to solve the right problem, or have you been distracted by a peripheral technicality?
Why is this thing a problem?
What is it that's making it so hard to solve?
Does it have to be done this way?
Does it have to be done at all?
Tip 56: Listen to Nagging Doubts—Start When You're Ready
But how do you tell if you’re procrastinating or if it’s a good judgment to wait?
A technique that has worked for us in these circumstances is to start prototyping. Either you’ll be bored and start doing the real work or that you realize something isn’t right and you’ll find a solution
Tip 57: Some Things Are Better Done than Described
As a Pragmatic Programmer, you should tend to view requirements gathering, design, and implementation as different facets of the same process—the delivery of a quality system. Distrust environments where requirements are gathered, specifications are written, and then coding starts, all in isolation


Chapter 8. Pragmatic Projects
Tip 62: Test Early. Test Often. Test Automatically.
Tip 63: Coding Ain't Done 'Til All the Tests Run
Tip 65: Test State Coverage, Not Code Coverage
Tip 66: Find Bugs Once
Tip 67: Treat English as Just Another Programming Language
Tip 68: Build Documentation In, Don't Bolt It On
Tip 69: Gently Exceed Your Users’ Expectations
take the extra mile
Tip 70: Sign Your Work

Extremely helpful. Will use a lot of these tips in my work.

The book starts out very strong in the first chapters but then kinda gets boring; I mean its 2022 we all know we should be using git for version control.
I kinda get the vibe that the book is for people who are new to programming want to avoid the big mistakes.

I think I highlighted like 90% of this book.

As old as it is; it is still very relevant.

I highly recommend it.

I just finished the 20th Anniversary Edition. Quite interesting read, especially when they talk about certain differences between the moment they wrote the first edition and nowadays.

The Pragmatic Programmer is centered on good programming practices. It is very well written and is able to persuade you to want to change your habits and behavior. I intend on re-reading this book on a regular basis (anually, perhaps) because there is certainly a learning and adaptation curve to all the techniques that are introduced. Although I do use some of them on my day-to-day work, it's very difficult to start using every single tip at once, so I'll introduce them gradually on my working flow and hopefully become a better overall developer!