There’s definitely lost
linkage of knowledge if you can’t reference the ticket from your editor, which for many if not most workflows means you never can. The loss is that an unadorned hack may have a corresponding ticket, with no way of knowing there’s even anything to look for. The workflow challenge is chicken-egg: people seldom file a ticket on
proposed, unmerged changes, and most teams would balk at the concept without specific procedures in place; people definitely don’t go back after a change is merged to annotate a hack with whatever ticket was filed for posterity.
IME, a better solution is keeping the TODOs (or FIXMEs or whatever your preferred label[s]), with linter rules to require aging them so they must be addressed eventually, somehow. Even if you address them by removing them. At least then there’s some possibility of relinking them later, tied directly to the commit history.
I agree with your point about polluting the code with good intentions, however. And I agree with the article author’s point that most of the time you’ll not go back and fix it. Those points combined suggest that most TODOs should actually just be explanatory comments. In fact, as someone who writes very few code comments, I think a good heuristic for when to write them is my usual “does someone need this explained?” (either by my anticipation or by their direct questioning) plus “would I be inclined to write a TODO about this?”