//TODO: change the downstream code so it's less brittle after we get to prod(WARN)
//TODO: don't hard code this variable, had to get prod up and running due to leap year
In my experience TODO are most commonly placed by either the guy doing a greenfield project, the code maintainer, or the guy getting production out of the ditch at 2am on a Saturday. I don't think I've ever seen a junior dev write one. My code has a few TODO sprinkled in but they're fairly rare, and call out where I had to make a decision due to constraints, and inform which direction I intended to take.
They're placeholders for me. Not for everyone else. I can't write perfect code the first time. I may use hardcoded strings (instead of spending 20 mins uploading the string to localization). I may make a O(n^2) loop because I'm fixing another problem. If you find these TODO in a PR, you should call them out. Or I might be on a long vacation next week but I don't want to leave the branch out of sync for a long time and it works but is a little dirty.
In some other cases, they don't have to be done now. They're bottom priority. A hardcoded color that won't work with dark mode, but we have no plans to use dark mode, etc.
Personally, I normally don't. But every now and then it just intuitively seems like the right way to phrase the comment. Afraid I can't really explain any better than that.
It's useful when an unrelated change unintentionally gets rid of a TODO and you can cross-reference it with the tracker item to see more context and maybe close it too.
