7 ms·
As a proponent of "TODOs should always point to a concrete issue", you have 3 ways to resolve a TODO before merging: 1. Just file the issue. If it's something
by nevermore 1y ago
As a proponent of "TODOs should always point to a concrete issue", you have 3 ways to resolve a TODO before merging:
1. Just file the issue. If it's something you should actually do, you can take 20 seconds to write it down and track it.
2. Just do it. If it seems like too small of a thing to file an issue for, fix it before you commit it.
3. Turn it into a comment. If it's not worth fixing and not worth tracking, but you want to remember it, that's a fine thing for a regular code comment.
Eat your broccoli. Track your todos.
- mcntsh 1y agoI wish tracking took 20 seconds. In my org (big tech) a JIRA ticket has 10+ required fields.
- hinkley 1y agoJira is awful because it has no opinions and leaves those decisions up to people who have terrible ones.
- indoordin0saur 1y agoJira really seems to have degraded as it has become increasingly bloated. I grit my teeth every time I hear platform ops say "hey, that deployment ticket last week... we noticed you didn't fill out the x, and z fields and also didn't create a follow-up ticket for future deployment to prod with the correct link to the implementation ticket"
- maccard 1y agoThat’s nothing to do with jira and everything to do with your platform ops team.
- hinkley 1y agoThat’s only true if you think the person who made the torture device is not culpable for their customers using it as a torture device. I don’t happen to believe that is true. Pandering to customers makes you part of the problem.
- indoordin0saur 1y agoAh, sorry I think I communicated in an unclear way. Yeah, we have some annoying processes at my office but a big reason that this sort of request sucks for me is that Jira is bloated, slow, confusing and buggy in a way it wasn't 5-10 years ago.
- maccard 1y agoMy experience is that if you give a “better” tool to a bad team they’ll just do something outside the tool. I have never worked with a team who has had a roadmap in jira - there’s always a corresponding excel sheet for that. The best defence against this practice is strong leadership and buy in to the value of the tool. Personally I run myself on a bullet ish journal and I’d probably run my team on Trello given the choice.
- CRConrad 1y ago> ...and I’d probably run my team on Trello given the choice. For how much longer, though? Been quite a while since Trello was bought by Atlassian; dunno how badly Jira-fied it is by now, but I can only imagine it's going to get more and more so.
- zargon 1y agoIt feels like it takes 20 seconds just for the Jira page to load.
- wackycat 1y ago// TODO refactor to make page load faster
- jraph 1y ago// NOTE in the meantime, we added asynchronous loaders everywhere using // a third party library which makes the page even slower to load, and // increased the recommended CPU and RAM requirements for both the server // and the client. // We also added a noscript tag to tell the users they can't load the page // without JavaScript so the loaders can load.
- scosman 1y agoYes! I often add a CI check that TODOs are removed before merging a PR. Have them all you want in your branch, but do one of the above 3 things before merging (sometimes any `TODO`, sometimes `TODO_P0`). I find CI integration also makes TODOs more helpful. You can use them to track a genuine TODO in a working branch, but CI will make sure you don't miss them.
- happytoexplain 1y ago>take 20 seconds to write it down and track it You've described a TODO. If I were to elevate it into a ticket system, besides obviously taking longer than 20 seconds, it would be a distraction, not a help.
- AnotherGoodName 1y agoI personally have no problem with the forcing function of a policy that makes you add a todo to a ticketing system. It sets a bar for the todo to be at least more complex than creating a ticket. Any less and you can just do what the todo says to do.
- cjbgkagh 1y agoMake the bar high enough and people won’t bother to do either and instead just hope for the best or keep their own list of TODOs elsewhere. The point of a cheap informal method is to as low of a bar as possible so that more information is collected. As for always immediately fixing that’s the same as making everything the top priority, the true priority is lost. Too many TODO comments and not enough tracked issues, that’s a sign that issue tracking has too much ceremony. Ban the use of TODOs and you lose even that information. Perhaps a codebase could be watched such that new tracking issues are added and tracked implicitly when checked in by searching for new TODOs in the code. Similarly the tracking issue could be closed when the corresponding TODO is deleted from the code.
- shitpostbot 1y ago[dead]
- hinkley 1y agoI was just having this conversation with myself for another reason this morning (trying to define why automating processes is a force multiplier and mistake reducer). Because there’s little to no IDE integration for ticket tracking, swapping to the ticket system is a context switch. And the ticket system has ways of demanding your attention once you’re in there. If it succeeds now you’re pre-empted. The thing about concurrency is that as long as you don’t know about a priority message you can continue to make progress on the task at hand. The moment you are aware of it you have to deal with it or have to explain yourself later. “I didn’t see it” goes a lot farther than, “I did but I was busy.” My ex would try to check her work email on a Friday evening as we were on our way out the door for a trip out of town. A trip her boss likely knew about. That’s not why she’s my ex but it certainly didn’t help. That email arrived after you already left, lady. That’s your story and we are sticking to it. Don’t go looking for conflict, particularly when doing so affects people other than yourself.
- nonethewiser 1y agoI think the author is basically arguing for #3 but not addressing the difference between a `TODO` comment vs. a non-`TODO` comment. I guess the `TODO` terms has a certain visual flair that makes us immediately understand the class of comment. I guess that would be my best argument for keeping it a `TODO` comment instead of a regular one. But when you see the author arguing that `TODO` comments dont mean you need TO DO anything, it's kind of a smell, isn't it? I find myself generally agreeing with the article's sentinment but think your option #3 of just making it a non-TODO comment an improvement.
- hinkley 1y agoAm I hallucinating or did IntelliJ have a TODO tracker? Webstorm doesn’t bug me about todos, but something I used to use did.
- skydhash 1y agoIt still does. But it’s a user option to run the scan when commiting (or pushing). So it may be disabled in your config.
- nilamo 1y agoRider definitely has a popup with a list of TODOs before you push to the remote. I assumed that originally existed in intellij... but never verified that.
- 0x457 1y agoYes, it's in base IntelliJ. TODO and FIX tracking, IIRC.
- 1980phipsi 1y agoI think the key point is that if you put a TODO comment in the code, it should be resolved before merging. If it's important enough to leave in there, it should be an issue. I only use them as something to grep for and so that I don't lose my train of that as in "oh I need to fix that but I'm working on something else at the moment, write the TODO, finish what I'm working on, then go back to the TODO".
- hinkley 1y agoIf the todo is code you’re working on, yes. If it’s a WTF about code that is next to the code you worked on, no. Boost the WTF ratio of code that deserves it.
- johnfn 1y agoWhat if you're working on something, and you see some code that should be marked with TODO, entirely unrelated to your code? I think it's unrealistic to expect to be able to fix every issue you see.
- moi2388 1y agoThen I create a ticket and we refine it to see if it indeed needs to be addressed
- RandallBrown 1y agoThis is how I use TODO as well. If it shows up in a pull request, it should be a red flag that the work isn't done.
- pornel 1y agoTracking in external system adds overhead not only for filing the issue, but also for triaging it, backlog management, re-triaging to see if it's still a problem, and then closing it when it's finished. Issues in an external systems may also be overlooked by developers working on this particular code. There are plenty of small things that are worth fixing, but not worth as much as the overhead of tracking them. TODO in code is easy to spot when someone is working on this code, and easy to delete when the code is refactored.
- OrderlyTiamat 1y agoYou can leave the TODO in the comments- e.g. ruff the linter has an optional rule to disallow TODO comments unless it's followed by an issue url. If you put that in the CI, then you can use TODOs either as blockers you wish to fix before merging, or as long term comments to be fixed in a future ticket.
- evnu 1y agoSome years ago, I started to use FIXME to indicate that something is blocking the PR and needs to be done before merging, and TODO if something can be done at a later point in time. Then, CI only needs to grep for FIXME to block merging the PR, which works for practically any language. Works pretty well for me, maybe that tip can help others as well.
- pc86 1y ago> Tracking in external system adds overhead not only for filing the issue, but also for triaging it, backlog management, re-triaging to see if it's still a problem, and then closing it when it's finished. Which is already what you're doing in that system, and what the system is designed for. Source code is not designed to track and management issues and make sure they get prioritized, so you shouldn't be using your source code to do this. We add TODOs during development, and then during review we either add a ticket and remove the TODO, or fix the issue as part of the PR and remove the TODO.
- motorest 1y ago
- schwartzworld 1y agoI have a single rule: Every todo needs the ticket number included. // TODO: improve the routing https://jira.com/whatever/TIX-1234 https://jira.com/whatever/TIX-1234 This rule is important because comments can get orphaned. Just leaving a comment is a recipe for a comment nobody knows why it’s there. Just make a ticket or do it now.
- deltaburnt 1y agoI don't understand this? The comment is next to the code it's mentioning. If the comment doesn't have enough context then the comment isn't long enough. Worst case you should be able to find necessary context in the blame. I agree that for particularly complex issues you need to file a ticket, explain all the context, maybe give reasons on why it wasn't solved in the original commit. But for forced issues you can easily have the _opposite_ problem to what you're describing. That is: you're left with a bunch of skeleton issues filed only for the sake of shoving it into a TODO comment. Those tickets end up getting auto closed after X time anyways. Obviously have guidelines, maybe even have a linter warning. But don't implement strict rules. It's a comment.
- schwartzworld 1y ago> That is: you're left with a bunch of skeleton issues filed only for the sake of shoving it into a TODO comment Nobody says it needs to be one ticket per TODO. For example, I usually maintain a CSS punch list ticket to avoid too much yakshaving when developing functionality. Not only will it be more likely to get scoped and done, but another dev will know exactly where the fixes are needed by grepping for the ticket number. But the other upside is that if it's really not worth filing a ticket for, why not just do it? I'm curious what scope of work you think is worth tracking in TODOs but not tickets. If it would be a point of work it probably deserves a ticket. If it's less than a point of work, shouldn't you just do it? > Those tickets end up getting auto closed after X time anyways. That feels like it reinforces my argument to me. If you can't make time for it when it's a ticket, how would you make time when it's just a comment? At least if the team decides in grooming that the work doesn't really need to be done, it's a group decision and not just me passing the buck.
- aoeusnth1 1y agoWhen forced to point to a concrete issue by tooling, I often just end up rewording it - "Ideally this should X, but it Y". Comments are fine, lower overhead and don't require re-triaging later, and have all the context to immediately understand.
- cortesoft 1y ago> If it's not worth fixing and not worth tracking, but you want to remember it, that's a fine thing for a regular code comment. In my mind, every todo in code is of this type - worth fixing (someday, maybe) but not worth tracking. If it needs to be tracked, put the details in the ticket and just link to the code, don't put a commment in there. To me, the point of the todo comment is to see it if I am working/touching/utilizing that bit of code. That is the time it should be worked on, not when someone finally gets to a ticket in the ticket tracker. It's all about the method of action - if the task is something that should be prioritized against other work, put it in a ticket. If it is a task that should only ever be done if I touch this bit of code, then put it in a TODO comment.
- navane 1y agoTodos can also serve as a direction where you want the code to go to. Leaving this in the code ensures everyone working on it sees it, and every change they make can take this direction in mind. Maybe THIS change finally warrants implementing foo, or at least refrain from implementing bar.
- PicassoCTs 1y agoAny MBA in the comments- those issue growths will make me look bad in front of my superior- we should delete all those issues once a year. Thus introducing the ToDODOs - which is a attempt to hold memory of important tasks facing extinction through cooperate dementia, which those who hold idealistic views of the stakeholders while engineering processes have no living memory of due to job hoping.
- KolibriFly 1y agoSometimes the value is just in capturing that thought in situ, even if it never gets acted on. It's less about task management, more about code archaeology
- bayindirh 1y ago4. Take a look at TODOs while maintaining the code, and promote them to the issue tracker if you feel like their time has come or have time to fix them. Take note that it's being actively worked on, on the codebase. Eat your veggies. All veggies matter. Be flexible. P.S.: This is what I do. My IDE gives a nice list of them.
- stared 1y agoI disagree. In each practical project, there is an order of magnitude more things than you could do. One of the crucial job is to prioritize things well, knowing the context. Regular tasks trackers put things outside of context. Low-priority things might go better in code. That is, you don't need to care about performance of a particular function as it does not matter. But when it starts to matter, and you see "TODO: cache results to speed up", you see an easy win.
- Pxtl 1y agoIssue trackers are often politicized. You get projects where they auto-close stale issues. Or where they're resistant to creating issues that they know that realistically nobody is going to work on this in the foreseeable future. TODOs are an excellent place for developers to describe where they'd like to go with a given pile of code if they had the time, and realistically that kind of work isn't suitable for every issue tracker depending on who has access to that issue tracker and who has opinions about what goes in there.
- inadequatespace 1y agoIt’s worth noting that 1. is not mutually exclusive with writing a TODO. In fact, on my team, all TODOs must have a bug in parentheses immediately afterwards to satisfy the linter. So not only not mutually exclusive, but the opposite.