This is Part 2 of 7 part series inspired from the book Pragmatic Programmer, read Part 1 here:
- Always Use Source Code Control: Source code control is a time machine for your work—you can go back.
- Don’t Panic When Debugging: Take a deep breath and THINK! about what could be causing the bug.
- Don’t Assume It—Prove It: Prove your assumptions in the actual environment—with real data and boundary conditions.
- Write Code That Writes Code: Code generators increase your productivity and help avoid duplication.
- Design with Contracts: Use contracts to document and verify that code does no more and no less than it claims to do.
- Use Assertions to Prevent the Impossible: Assertions validate your assumptions. Use them to protect your code from an uncertain world.
- Finish What You Start: Where possible, the routine or object that allocates a resource should be responsible for deallocating it.
- Configure, Don’t Integrate: Implement technology choices for an application as configuration options, not through integration or engineering.
- Analyze Workflow to Improve Concurrency: Exploit concurrency in your user’s workflow.
- Always Design for Concurrency: Allow for concurrency, and you’ll design cleaner interfaces with fewer assumptions.
Please read part 3 of 7 part series inspired from the book Pragmatic Programmer here.
This is Part 1 of 7 part series inspired from the book Pragmatic Programmer:
- Care About Your Craft: Why spend your life developing software unless you care about doing it well?
- Provide Options, Don’t Make Lame Excuses: Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.
- Be a Catalyst for Change: You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.
- Make Quality a Requirements Issue: Involve your users in determining the project’s real quality requirements. Critically Analyze What You Read and Hear Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.
- DRY—Don’t Repeat Yourself: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
- Eliminate Effects Between Unrelated Things: Design components that are self-contained, independent, and have a single, well-defined purpose.
- Use Tracer Bullets to Find the Target: Tracer bullets let you home in on your target by trying things and seeing how close they land.
- Program Close to the Problem Domain: Design and code in your user’s language.
- Iterate the Schedule with the Code: Use experience you gain as you implement to refine the project time scales.
- Use the Power of Command Shells: Use the shell when graphical user interfaces don’t cut it.
Please read part 2 of 7 part series inspired from the book Pragmatic Programmer here.