I write TODO for something that would be too disruptive to do as part of the current change but nice to have done. E.g refactoring a bunch of files - one of them should be renamed but that would add every file that refers to it to the change and make it harder to see the real work done. Next time I’m in that code with a simple change, I can submit a rename CR that doesn’t have anything else mixed up in it.
> I write TODO for something that would be too disruptive to do as part of the current change but nice to have done.
One more reason to not have a TODO item and instead track work on a ticket. Sneaking fixes/changes as part of other tickets mixes up the rationale for tickets and makes changes harder to track. If all you're doing is a cleanup then all the more reason why it should be in an independent PR tracked accordingly.
Where it will never be picked up, because rework tickets never get prioritized over feature work until something breaks.
And when some future engineer comes along and asks themselves why the hell this code is the way it is, they'll have to git-blame, dig through commits, find PRs for commits, hopefully find referenced ticket numbers, read those, and play archeologist to try to reconstruct whether there's good reason for the existing code's being from those indirect signals. Whereas a simple "TODO" could just tell said future engineer what they ought to know.
I sincerely appreciate a well-written TODO, and I make every effort to write good TODOs for others.
