The Pragmatic Programmer

Feb 24, 2025 4 min read 2025-02Pragmatic ProgrammerBook ReviewProgrammingSoftware DevelopmentBest PracticesTech2025

I have been reading The Pragmatic Programmer and I have to say it is a fantastic book. It is full of great advice and tips for programmers. I highly recommend it to anyone who is a programmer at any level.

Lots of the advice is common sense and things I already do, but there are also lots of things I know in the back of my mind that I should be doing. So reading it has been a great reminder of those things.

Here is the complete list of tips that can be found in the book (I am reading the 20th anniversary edition, so these might be slightly different if you are looking at the original edition):

  1. Care About Your Craft
  2. Think! About Your Work

A Pragmatic Philosophy

  1. You Have Agency
  2. Provide Options, Don’t Make Lame Excuses
  3. Don’t Live with Broken Windows (I blogged about this in 2015)
  4. Be a Catalyst for Change
  5. Remember the Big Picture
  6. Make Quality a Requirements Issue
  7. Invest Regularly in Your Knowledge Portfolio
  8. Critically Analyze What You Read and Hear
  9. English is Just Another Programming Language
  10. It’s Both What You Say and the Way You Say It
  11. Build Documentation In, Don’t Bolt It On

A Pragmatic Approach

  1. Good Design Is Easier to Change Than Bad Design
  2. DRY - Don’t Repeat Yourself
  3. Make It Easy to Reuse
  4. Eliminate Effects Between Unrelated Things
  5. There Are No Final Decisions
  6. Forgo Following Fads
  7. Use Tracer Bullets to Find the Target
  8. Prototype to Learn
  9. Program Close to the Problem Domain
  10. Estimate to Avoid Surprises
  11. Iterate the Schedule with the Code

The Basic Tools

  1. Keep Knowledge in Plain Text
  2. Use the Power of Command Shells
  3. Achieve Editor Fluency
  4. Always Use Version Control
  5. Fix the Problem, Not the Blame
  6. Don’t Panic
  7. Failing Test Before Fixing Code
  8. Read the Damn Error Message
  9. “select” Isn’t Broken
  10. Don’t Assume It - Prove it
  11. Learn a Text Manipulation Language

Pragmatic Paranoia

  1. You Can’t Write Perfect Software
  2. Design with Contracts
  3. Crash Early
  4. Use Assertions to Prevent the Impossible
  5. Finish What You Start
  6. Act Locally
  7. Take Small Steps - Always
  8. Avoid Fortune Telling

Bend, or Break

  1. Decoupled Code is Easy to Change
  2. Tell, Don’t Ask
  3. Don’t Chain Method Calls
  4. Avoid Global Data
  5. If it’s Important Enough to be Global, Wrap It in an API
  6. Programming is About Code, But Programs Are About Data
  7. Don’t Hoard State; Pass It Around
  8. Don’t Pay Inheritance Tax
  9. Prefer Interfaces to Express Polymorphism
  10. Delegate to Services: Has-A Trumps Is-A
  11. Use Mixins to Share Functionality
  12. Parameterize Your App Using External Configuration

Concurrency

  1. Analyze Workflow to Improve Concurrency
  2. Shared State is Incorrect State
  3. Random Failures Are Often Concurrency Issues
  4. Use Actors for Concurrency Without Shared State
  5. Use Blackboards to Coordinate Workflow

While You Are Coding

  1. Listen to Your Inner Lizard
  2. Don’t Program by Coincidence
  3. Estimate the Order of Your Algorithms
  4. Test Your Estimates
  5. Refactor Early, Refactor Often
  6. Testing is Not About Finding Bugs
  7. A Test is the First User of Your Code
  8. Build End-to-End, Not Top-Down or Bottom-Up
  9. Design To Test
  10. Test Your Software, or Your Users Will
  11. Use Property-Based Tests to Validate your Assumptions
  12. Keep it Simple and Minimize Attack Surfaces
  13. Apply Security Patches Quickly
  14. Name well; Rename When Needed

Before the Project

  1. No One Knows Exactly What They Want
  2. Programmers Help People Understand What They Want
  3. Requirements are Learned in a Feedback Loop
  4. Work with a User to Think Like a User
  5. Policy is Metadata
  6. Use a Project Glossary
  7. Don’t Think Outside the Box - Find the Box
  8. Don’t Go into the Code Alone
  9. Agile is Not a Noun; Agile is How You Do Things

Pragmatic Projects

  1. Maintain Small, Stable Teams
  2. Schedule It to Make it Happen
  3. Organize Fully Functional Teams
  4. Do What Works, Not What’s Fashionable
  5. Deliver When Users Need It
  6. Use Version Control to Drive Builds, Tests and Releases
  7. Test Early, Test Often, Test Automatically
  8. Coding Ain’t Done ‘Til All the Tests Run
  9. Use Saboteurs to Test Your Testing
  10. Test State Coverage, Not Code Coverage
  11. Find Bugs Once
  12. Don’t use Manual Procedures
  13. Delight Users, Don’t Just Deliver Code
  14. Sign your Work

  1. First, Do No Harm
  2. Don’t Enable Scumbags
  3. It’s Your Life
Understanding and Handling Exceptions in .NET

Related Posts

Comments

comments powered by Disqus