Comment by raytracer | Hacker News Reader

Comment by raytracer | Hacker News Reader

Parent Full thread

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.

Exactly. I don't see why you would do this in another application. Doing it in another application means you also have to take note of _where_ the piece of your TODO is. That means filename and line number?

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.

That's what I do as well. Also, in OO languages like Java or C#, you can throw "NotImplemented" style exceptions. So that if you mistakenly wrote "TO DO" instead of "TODO" and can't find it statically, the runtime will let you know.

I create stories in JIRA. It's a lot more effort but the defects are at least visible to management and actually stand a chance of getting scheduled. You can also include a lot more context than you can in a comment.

Reply on news.ycombinator.com