This is Part 5 of 7 part series inspired from the book Pragmatic Programmer, read Part 4 here:
- 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.
- Prototype to Learn: Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.
- Estimate to Avoid Surprises: Estimate before you start. You’ll spot potential problems up front.
- Keep Knowledge in Plain Text: Plain text won’t become obsolete. It helps leverage your work and simplifies debugging and testing.
- Use a Single Editor Well: The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.
- 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.
- “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.
- 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?
- You Can’t Write Perfect Software: Software can’t be perfect. Protect your code and users from the inevitable errors.
- 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.
2 comments