My favorite tips from Pragmatic Programmer

I recently (finally) read the Pragmatic Programmer book and it has lot of good tips. Broken Windows and DRY are some of the widely known pragmatic programmer tips. Below are some of my personal favorite tips from this book:

1. Care about your craft - Care about the product that you develop and not just do it because you have to do it.
2. Don't live with Broken Windows - Make sure to fix bad designs, wrong decisions or poor code as soon as possible.
3. Be a catalyst for change - Like the stone soup story, it's time to bring out the stones. Show people what you got and how it could evolve in future and people will join you.
4. Remember the big picture - Don't be like boiled frogs. Be aware of what's going on around you.
5. Invest regularly in your knowledge portfolio - Just like managing a portfolio, we need to invest regularly, diversify it and manage the risks involved. Also, review and rebalance your technical portfolio in a regular basis so that it reflects the current trend.
6. DRY - Don't Repeat Yourself. Make sure that every piece of code has a single, unambiguos and authoritative representation in the system. Not that this also applies to documentation and not just for code.
7. Eliminate effects between unrelated things - We wants systems to be as orthogonal as possible. Less coupling allows them to change independently.
8. Don't program by Coincidence - Always know what you do and don't code blindfolded.
9. Test your software, or Your Users Will - It is better for the tester in your team to find issues before users find it. Better yet, make sure that you test your code and find any problem before the tester finds it.
10. Work with a user to think like a user - Don't just assume that users might need a feature just because it is in other apps, or it is cool or you like it. Work with a user (or product owner) to find out what they want and learn to think like them.
11. Refactor early, Refactor often - Always refactor to keep the code in good shape. Use the medical analogy of removing "growth", when explaining the need of refactoring to non-technical managers.
12. Don't be a slave to formal methods - Formal methods are good, but don't follow it blindly. It would be good to tweak it to suit your development needs and the team structure.
13. Don't use manual procedures - Always automate anything and everything that you do repeatedly manually.
14. Use Saboteurs to test your testing - Test cases or suites test our code. But, we also need to test the tests. Make sure that your tests produce alarm when they should.
15. Test state coverage, not code coverage - It is possible to fail with 100% code coverage. Make sure that all states of the system are tested well.
16. Find bugs once - When a bug is found, add test for the bug first and see it go red. Then fix it and watch it go green. Automated tests prevent the bug from happening again.
17. Sign Your Work - Take pride in what you do. Just like an artist signs their work, make sure to sign your code (ex - @author tag in Java) and take pride in the code your develop. Other developers should expect to see your name and expect it to be well written, tested and documented.