Scan barcode
fbroom's review against another edition
2.0
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
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
stefanaserban's review against another edition
3.0
The book reads a bit like a self-help book, but it's full of useful information and saved by the fact that everything is gathered in one place. Even though this is the rewritten edition, this reads slight outdated.
Probably a good read for more "pure" programmers, but for a person in Machine Learning, like myself, I felt like I had use of 40% of the book.
Probably a good read for more "pure" programmers, but for a person in Machine Learning, like myself, I felt like I had use of 40% of the book.
andrewacashner's review against another edition
funny
hopeful
informative
inspiring
lighthearted
fast-paced
3.5