| A couple of years ago I started using TODO:HIGH, TODO:MED and TODO:LOW. TODO:HIGH is for things that need to be completed for the current feature or bug fix. TODO:MED is for things that should be completed before the next public build. TODO:LOW is for stuff that would be good to get done eventually. (A function is complete but doesn't read well so I'll add a note to refactor it at later date.) When writing new code I try to get something up and running ASAP by filling in functionality with broad strokes. I'll go back and fill in the details once the larger picture is in place. With less code written, it's easier to refactor (or restart), if the design is not quite right. Writing lots of TODOs helps ensure nothing gets forgotten about. Picking an easy TODO from the backlog can be good way to warm up when starting the day too. I'm used to working solo however. Not sure how this approach would go down on a team. |
While I don't use priorities, I do liberally use "// TODO: <problem statement>" if it's something I need to do that takes me out of the current problem. Then when I'm finishing up a feature or bug fix, I just walk past the list of TODO's.
A recent example would be: On this new project I was on, while implementing a feature, I didn't know how resource files were handled yet -- so I hardcoded some strings with a "// TODO: Put these strings in resource files". Researching the way resource files are handled will pull you out of the current problem, while it's something that can easily be solved later.