15 Commandments to Curb Bad Programmer Habits
I hijacked this from here and modified it.
- Thou shalt not break the unit tests or system functionality (by checking in half done crap code to source control).
- Thou shalt really understand the requirements driving your work (not make them up or not bother to read them and/or not ask questions when necessary).
- Thou shalt deliver what the customer needs (not that which is easy to implement).
- Thou shalt estimate work effort accurately (and deliver within agreed estimates).
- Thou shalt understand the implications of thy work with respect to others on the team.
- Thou shalt not just comment out code because it causes the test to fail (without understanding why it was there in the first place).
- Thou shalt understand the implications of thy work with respect to other areas of the system as a whole.
- Thou shalt follow the business priorities (not just do what you think is interesting).
- Thou shalt deliver stuff that actually works - including the user interface that can't be unit tested (i.e. actually try it out rather than hoping for the best - test the UI - don't just leave it for the external tester to find as that is "their job").
- Thou shalt not regard communicating with other members of the team as an unnecessary and tiresome overhead that can be ignored.
- Thou shalt not deviate from the "agreed" development approach without a good reason that has been thought about.
- Thou shalt understand that the external image of the development team is important - even though it does not contribute to your daily work.
- Thou shalt not call the customer a wanker even when it is true. <ok, can't have this on the wall>.
- Thou shalt understand that sometimes thou must do things because they are important to other people's jobs (thou art not the only person in the universe).
- Thou shalt understand that getting the software out there, so others can see something has actually been done, is important (we're not just doing this as an intellectual exercise).