The Pragmatic Programmer – Review / Summary Notes.

Brian Du PreezDecember 9th, 2011Last Updated: October 21st, 2012

0 44 3 minutes read

I recently finished The Pragmatic Programmer, to be completely honest this had been the 3rd attempt to read it, although the book is good and well worth the read, I had unfortunetly learnt most of the lessons the hard way on my own over the last decade or so of being a software developer, so I found often myself easily distracted.

I have to add, had I read this when it was published it would have undoubtedly saved me some pain, but even with that it’s always good to reaffirm some of your good habits, and keep your bad ones in check. It covers 46 sections with 70 different tips that are generally useful to any programmer. Jeff Atwood – coding horror made a list of all 70 tips.

As with most things some tips are “more equal” than others, the ones that really stick out and probably can’t be emphasized enough are:

Care About Your Craft
Why spend your life developing software unless you care about doing it well?
Think! About Your Work
Turn off the autopilot and take control. Constantly critique and appraise your work.
Don’t Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.
Invest Regularly in Your Knowledge Portfolio
Make learning a habit.
DRY – Don’t Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Make It Easy to Reuse
If it’s easy to reuse, people will. Create an environment that supports reuse.
Prototype to Learn
Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.
Don’t Panic When Debugging
Take a deep breath and THINK! about what could be causing the bug.
“select” Isn’t Broken.
It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.
Design with Contracts
Use contracts to document and verify that code does no more and no less than it claims to do.
Crash Early
A dead program normally does a lot less damage than a crippled one.
Minimize Coupling Between Modules
Avoid coupling by writing “shy” code and applying the Law of Demeter.
Don’t Program by Coincidence
Rely only on reliable things. Beware of accidental complexity, and don’t confuse a happy coincidence with a purposeful plan.
Refactor Early, Refactor Often
Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.
Design to Test
Start thinking about testing before you write a line of code.
Some Things Are Better Done than Described
Don’t fall into the specification spiral ?at some point you need to start coding.
Don’t Be a Slave to Formal Methods.
Don’t blindly adopt any technique without putting it into the context of your development practices and capabilities.
Don’t Use Manual Procedures
A shell script or batch file will execute the same instructions, in the same order, time after time.
Test Early. Test Often. Test Automatically
Tests that run with every build are much more effective than test plans that sit on a shelf.
Coding Ain’t Done ‘Til All the Tests Run
‘Nuff said.
Test State Coverage, Not Code Coverage
Identify and test significant program states. Just testing lines of code isn’t enough.
Find Bugs Once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.