[Sydneyco]

Interesting reasoning and I like the questions you ask yourself.

This makes me think of Polaris Methodology I heard from a french tech team: Sometimes you just need to get the code working to advance in your feature or whatever you are trying to build so you add a TODO to your code; The problem is that you never come back to it.

The Polaris methodology is that after 6 weeks of the sprint, they have 2 weeks of 'rest'. Rest time is used for code that hasn't been completely finished, code that "smells". You use those two weeks to refactor what is fresh in your mind and whatever you feel needs to be made better.

[atoav]

I usually add a

  // TODO: description what needs to be done where and why

and then regularily grep for it when I start working on a project again. Often I'd go "oh let's fix this small thing first before going ahead".

[diamondo25]

I feel like adding TODOs for non-critical changes are a good braindump that you can come back to.

[jraph]

And it's fine to leave them there for years. It's still possible to solve them when actually needed.

I've recently thanked myself for a TODO note: "oh, that not done... because that's not done [yet]! [conscientiously, deliberately]"