We all write the dreaded // TODO: and // FIXME: comments every once in a while. Sometimes we do it because we know our code can be better but we're...
For further actions, you may consider blocking this person and/or reporting abuse
5 all day :)
Almost the same as comments - asking yourself why you're doing this and handling it right there is definitely the say to go. If it is a task that needs to get done, I've found adding it to your backlog so there's some accountability is a better way to go.
A tip so simple yet so difficult in practice... 🤦♂️
Totally agree on being upfront on the cost associated with not paying down tech-debt, and that is a definite advantage to having TODO items as tickets -- generally speaking the biz folks aren't in the code, so they don't see TODO's, but they will see an issue in JIRA or whatever task tracker you use.
It took me an embarrassingly long time to realize it's nearly always better to "just do the thing" right then. Obvious, in retrospect...
I like the idea of filing an issue for things, but I've found in practice those issues never get done (they tend to be hard to prioritize over other biz-facing features) & tend to clutter up backlogs.
Generally speaking the size of a TODO item tends to be quite small, probably too small to be encapsulated as a single issue in a task tracker, so if every "TODO" item became an issue there's a very real risk of being killed by a thousand paper cuts" as well.
TODO's in code can have the same issue around "never getting done", but at least then while working in an area of code you're forced to see related TODO items in that area that can give you context around shortcomings or areas in which that code can/should be improved.
From my experience TODO tends to stay in the code forever. I only use them while I'm refactoring some code or if I know I'm going to deal with them within a few days to complete a feature. As a matter of fact I'm now in the midst of migrating a project from Objective-C to Swift and I'm using a lot of TODO, but I know they'll eventually go away.
The problem with TODO is sometimes you use them when you write something in a hurry, you feel is not optimised and you leave a comment for the future self to refactor that particular piece of code. You'll hardly find time to deal with it, and the TODO will stay there so just avoid adding it in the first place.
Exactly, marking your todos with your name and date helps you and your team to keep you accountable. And making sure you have a ticket in your tracking system of choice ensures that nobody forgets them. And by calling them out in a code review and asking for the todo to be resolved before merging prevents the todo from ending up in your code base completely.
I would say put a ToDo as a place holder in the code only if you create a new story/feature for the work to be planned.
otherwise they just create noise in the code
I love #5. If I see the same poor design more than once, I'll take some time to refactor. Boy Scout's Principle :)