I am a Pragmatic Programmer Part 6

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

  1. Use Exceptions for Exceptional Problems: Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.
  2. Minimize Coupling Between Modules: Avoid coupling by writing “shy” code and applying the Law of Demeter.
  3. Put Abstractions in Code, Details in Metadata: Program for the general
    case, and put the specifics outside the compiled code base.
  4. Design Using Services: Design in terms of services—independent,
    concurrent objects behind well-defined, consistent interfaces.
  5. Separate Views from Models: Gain flexibility at low cost by designing
    your application in terms of models and views.
  6. Don’t Program by Coincidence: Rely only on reliable things. Beware of
    accidental complexity, and don’t confuse a happy coincidence with a
    purposeful plan.
  7. Test Your Estimates: Mathematical analysis of algorithms doesn’t tell
    you everything. Try timing your code in its target environment.
  8. Design to Test: Start thinking about testing before you write a line
    of code.
  9. Don’t Use Wizard Code You Don’t Understand: Wizards can generate reams of code. Make sure you understand all of it before you incorporate it
    into your project.
  10. Work with a User to Think Like a User: It’s the best way to gain
    insight into how the system will really be used.

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

I am a Pragmatic Programmer Part 5

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

  1. There Are No Final Decisions: No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.
  2. Prototype to Learn: Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.
  3. Estimate to Avoid Surprises: Estimate before you start. You’ll spot potential problems up front.
  4. Keep Knowledge in Plain Text: Plain text won’t become obsolete. It helps leverage your work and simplifies debugging and testing.
  5. Use a Single Editor Well: The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.
  6. Fix the Problem, Not the Blame: It doesn’t really matter whether the bug is your fault or someone else’s—it is still your problem, and it still needs to be fixed.
  7. “select” Isn’t Broken: It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.
  8. Learn a Text Manipulation Language: You spend a large part of each day working with text. Why not have the computer do some of it for you?
  9. You Can’t Write Perfect Software: Software can’t be perfect. Protect your code and users from the inevitable errors.
  10. Crash Early: A dead program normally does a lot less damage than a crippled one.

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