This is Part 4 of 7 part series inspired from the book Pragmatic Programmer, read Part 3 here:
- Don’t Use Manual Procedures: A shell script or batch file will execute the same instructions, in the same order, time after time.
- 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.
- English is Just a Programming Language: Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation.
- Gently Exceed Your Users’ Expectations: Come to understand your users’ expectations, then deliver just that little bit more.
- 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.
- Remember the Big Picture: Don’t get so engrossed in the details that you forget to check what’s happening around you.
- 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.
- 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.
This is Part 3 of 7 part series inspired from the book Pragmatic Programmer, read Part 2 here:
- Use Blackboards to Coordinate Workflow: Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.
- Estimate the Order of Your Algorithms: Get a feel for how long things are likely to take before you write code.
- 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.
- Test Your Software, or Your Users Will: Test ruthlessly. Don’t make your users find bugs for you.
- Don’t Gather Requirements—Dig for Them: Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.
- 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.
- Don’t Think Outside the Box – Find the Box: When faced with an impossible problem, identify the real constraints.
- Ask yourself: “Does it have to be done this way? Does it have to be done at all?”
- Some Things Are Better Done than Described: Don’t fall into the specification spiral—at some point you need to start coding.
- 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.