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.



Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: