Docs and tests are good one. Lots of people like the fun part of coding, which is getting some new thing to work. I've taught myself to like docs and tests, t

Docs and tests are good one. Lots of people like the fun part of coding, which is getting some new thing to work. I've taught myself to like docs and tests, to the point that when I'm reviewing a changeset I look to see if there are docs and tests and just push back right away if there are not. If you get into that groove, write the docs first. When you have to explain your feature, write out the command line options, all of that, you have to sort of imagine it all in your head, you start to think about is this the way other commands work, am I being consistent, etc. I find that when I do the docs first I do a better job on the code, especially the UI parts or where it fits with other code. And tests, regression tests. When I started BitKeeper we did regression tests with every command. So frigging pleasant. It got to a point where you basically couldn't break BK if you passed the tests, or at least you had to be really sneaky. I agree with twobyfour that it's different for different people, his/her comment that you need to be self aware is a really good point.