I am a Pragmatic Programmer Part 4

This is Part 4 of 7 part series inspired from the book Pragmatic Programmer, read Part 3 here:

  1. Don’t Use Manual Procedures: A shell script or batch file will execute the same instructions, in the same order, time after time.
  2. Coding Ain’t Done ‘Til All the Tests Run: ‘Nuff said.
  3. Test State Coverage, Not Code Coverage: Identify and test significant program states. Just testing lines of code isn’t enough.
  4. English is Just a Programming Language: Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation.
  5. Gently Exceed Your Users’ Expectations: Come to understand your users’ expectations, then deliver just that little bit more.
  6. Think! About Your Work: Turn off the autopilot and take control. Constantly critique and appraise your work.
  7. Don’t Live with Broken Windows: Fix bad designs, wrong decisions, and poor code when you see them.
  8. Remember the Big Picture: Don’t get so engrossed in the details that you forget to check what’s happening around you.
  9. Invest Regularly in Your Knowledge Portfolio: It’s Both What You Say and the Way You Say It There’s no point in having great ideas if you don’t communicate them effectively.
  10. Make It Easy to Reuse: If it’s easy to reuse, people will. Create an environment that supports reuse.

Please read part 5 of 7 part series inspired from the book Pragmatic Programmer here.

I am a Pragmatic Programmer Part 3

This is Part 3 of 7 part series inspired from the book Pragmatic Programmer, read Part 2 here:

  1. Use Blackboards to Coordinate Workflow: Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.
  2. Estimate the Order of Your Algorithms: Get a feel for how long things are likely to take before you write code.
  3. 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.
  4. Test Your Software, or Your Users Will: Test ruthlessly. Don’t make your users find bugs for you.
  5. Don’t Gather Requirements—Dig for Them: Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.
  6. Abstractions Live Longer than Details: Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.
  7. Don’t Think Outside the Box – Find the Box: When faced with an impossible problem, identify the real constraints.
  8. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”
  9. Some Things Are Better Done than Described: Don’t fall into the specification spiral—at some point you need to start coding.
  10. Costly Tools Don’t Produce Better Designs: Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.

Please read part 4 of 7 part series inspired from the book Pragmatic Programmer here.