The Pragmatic Programmer Tips
Nov 25, 2015
2 minutes read
  • Care About Your Craft
  • Think! About Your Work
  • Provide Options, Don’t Make Lame Excuses
  • Don’t Live with Broken Windows
  • Be a Catalyst for Change
  • Remember the Big Picture
  • Make Quality a Requirements Issue
  • Invest Regularly in Your Knowledge Portfolio
  • Critically Analyze What You Read and Hear
  • It’s Both What You Say and the Way You Say It
  • DRY—Don’t Repeat Yourself
  • Make It Easy to Reuse
  • Eliminate Effects Between Unrelated Things
  • There Are No Final Decisions
  • Use Tracer Bullets to Find the Target
  • Prototype to Learn
  • Program Close to the Problem domain
  • Estimate to Avoid Surprises
  • Iterate the Schedule with the Code
  • Keep Knowledge in Plain Text
  • Use the Power of Command Shells
  • Use a Single Editor Well
  • Always Use Source Code Control
  • Fix the Problem, Not the Blame
  • Don’t Panic
  • “select” Isn’t Broken
  • Don’t Assume It—Prove It
  • Learn a Text Manipulation Language
  • Write Code That Writes Code
  • You Can’t Write Perfect Software
  • Design with Contracts
  • Crash Early
  • If It Can’t Happen, Use Assertions to Ensure That It Won’t
  • Use Exceptions for Exceptional Problems
  • Finish What You Start
  • Configure, Don’t Integrate
  • Put Abstractions in Code Details in Metadata
  • Analyze Workflow to Improve Concurrency
  • Design Using Services
  • Always Design for Concurrency
  • Separate Views from Models
  • Use Blackboards to Coordinate Workflow
  • Don’t Program by Coincidence
  • Estimate the Order of Your Algorithms
  • Test Your Estimates
  • Refactor Early, Refactor Often
  • Design to Test
  • Test Your Software, or Your Users Will
  • Don’t Use Wizard Code You Don’t Understand
  • Don’t Gather Requirements—Dig for Them
  • Abstractions Live Longer than Details
  • Use a Project Glossary
  • Don’t Think Outside the Box—Find the Box
  • Listen to Nagging Doubts—Start When You’re Ready
  • Some Things Are Better Done than Described
  • Don’t Be a Slave to Formal Methods
  • Expensive Too Do Not Produce Better Designs
  • Organize Around Functionality, Not Job Functions
  • Don’t Use Manual Procedures
  • Test Early. Test Often. Test Automatically.
  • Coding Ain’t Done ‘Til All the Tests Run
  • Use Saboteurs to Test Your Testing
  • Test State Coverage, Not Code Coverage
  • Find Bugs Once
  • Treat English as Just Another Programming Language
  • Build Documentation In, Don’t Bolt It On
  • Gently Exceed Your Users’ Expectations
  • Sign Your Work