The code should describe your business logic, not the work to do to build that code. What if no one looks at that file for a year?
The code should describe your business logic, not the work to do to build that code. What if no one looks at that file for a year?
Nothing wrong with referencing tickets in TODOs, except when references go stale. It's easier to just do periodic 'TODO' searches on mature code.
What doesn't seem to work is to turn every tiny TODO into an issue and then hope someone decides to recredentialize in some possibly large code just to fix some small issues because they stumbled upon it on the issue tracker.
When working on X, and noticing another piece of work Y, thinking too hard about Y can break context/concentration and your focus on X.
Focus needs to be preserved, which is why you drop TODO markers, rather than "just doing them" - you are already doing something, doing something else means not doing what you are meant to be doing now - not pragmatic at all.