> I'm certainly not opening JIRA for it, so (...)

That's the universe telling you the TODO is useless noise that points to a workitem that no one, not even you, find it relevant enough to track or work on.

When that happens, do everyone around you a favour and leave out the TODO comment.

Or it could be useful context for the next person to modify the code. Maybe it’s something that is only worth doing under certain conditions?

    // TODO: This is fine for now, but if we start handling `bar`s, we’ll need an extra field for `quxx`.

This is a great way of introducing a bug. The TODO is only visible to somebody looking at the code. If somebody changes a caller to send over bars but doesn't check the comment then you've got a bug. If instead this was linked to the feature request to add support for bars then you've got the relevant context right there on the ticket and whoever is implementing support for bars is much less likely to miss it.

And if the reason bars aren’t implemented yet is because nobody requested it, then there is no tracking ticket.

Nothing is important enough to be worth using JIRA for. When a company or team adopts JIRA it's the universe telling you that they've given up on doing anything valuable or useful. Trying to make such a codebase better is an exercise in futility; writing TODOs is as good a way to pass the time and collect a paycheck as any other, and any vestigial useful work to be done is more likely to be tracked in TODOs than in JIRA tickets.

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.

I explicitly said it would be a separate code review. Not every change needs a ticket, and the idea that it does is a barrier to improving code.

> instead track work on a ticket

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.