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.