7 Habits of Highly Effective Software Developers

1. Design before Coding - We developers often tend to get straight to code spending little time on design. While too much formal and complete design is useless in building software systems, some basic design before coding is extremely helpful. Design does not imply writing a text document with pictures or UML models. Design can be skeletal code that is the basis for the full implementation. I try to first build data structures that hold system state and service interface contracts (not implementations) for the entire application as part of my design exercise. I then try to think through the application flow for various usage scenarios. Good design typically pays off in the end in terms of good quality code developed in a shorter period of time.
2. Re-factor continuously - This seems contradictory to the first habit of designing before coding. After all, if the design is good why should there be a need for re-factoring? The answer is - it is impossible to design software systems accurately and fully at the very beginning. Designs tend to evolve as the system is being built. Often times requirements keep changing. No one can get it right the first time unless you are building a very simple, trivial piece of software. Re-visiting previously written code and continuously re-factoring it is one of the keys to building good software.
3. Unit Test every quarter - No that's not company's fiscal or calendar quarter. It is the 1/4 milestone of your task completion. Break up your task into four, and after each quarter, think of how you can unit test the code you have written. Note that I'm not suggesting you should write a unit test, rather you should have a good mental idea of how one would go about effectively testing what's built so far. If what you have written so far is not unit-testable, re-factor the code to facilitate unit testing before moving on to implementing the next quarter of your task. At the end of a complete task, make sure a formal unit test gets written.
4. Write squeaky-clean code - All brilliant developers that I've seen write very clean code. Clean code means paying attention to removing dead code, avoiding compiler warnings, indentation, spacing, naming, and consistency in code style. This is more than just cosmetics - if your code is not clean, it is unreadable, unmaintainable, less likely to be reused and more likely to get re-written by someone else.
5. Comment code - The only documentation we developers will ever write is comments in the code. Keeping this up to date is of critical importance for the long life of the code. Any code where the logic may not be obvious to a new peer programmer should be documented. Documenting your code is not just for others but for yourself too - how many times have you gone back to your own code written a year ago and wondered what the heck the implementation logic was?
6. Be lazy - Yes, be lazy! Don't write your own code when there is good code already available for the same task. Don't re-invent the wheel. There are a ton of open-source utility libraries that are extensively used; make use of these wherever possible. Why waste time writing code when you can borrow someone else's code which may even be better that what you could write?
7. Get your code peer-reviewed - Peer reviews often help generate new ideas and perspectives on implementation that you may not have thought about. Set your ego aside and solicit peer reviews of your code.