4 ms·

Often when I write a TODO, it's because it's because I'm not going to remember to write it down anywhere else. I'm certainly not opening JIRA for it, so this is

Often when I write a TODO, it's because it's because I'm not going to remember to write it down anywhere else. I'm certainly not opening JIRA for it, so this is as good as it's going to get. Every once in awhile we grep through the TODOs and see if we should write some tickets from them. Works fine.

simplotek 4y ago
> 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.
- wtetzner 4y ago
  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`.
  - UncleMeat 4y ago
    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.
    - wtetzner 4y ago
      And if the reason bars aren’t implemented yet is because nobody requested it, then there is no tracking ticket.
- lmm 4y ago
  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.
lazyasciiart 4y ago
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.
- simplotek 4y ago
  > 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.
  - lazyasciiart 4y ago
    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.
  - sdiupIGPWEfh 4y ago
    > 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.

simplotek 4y ago

> 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.

wtetzner 4y ago
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`.
- UncleMeat 4y ago
  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.
  - wtetzner 4y ago
    And if the reason bars aren’t implemented yet is because nobody requested it, then there is no tracking ticket.
lmm 4y ago
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.

lazyasciiart 4y ago

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.

simplotek 4y ago
> 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.
- lazyasciiart 4y ago
  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.
- sdiupIGPWEfh 4y ago
  > 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.