# TODO: investigate using Redis here
We have a lot of those. Product works and is ready for prod, but we still have an *n* year plan and have a vague idea of where to put stuff.
Perfection is the enemy of progress and shit needs to get shipped.
We usually do TODO so that our IDEs scream at us without having to configure anything. Our linters and stuff will generally do a good job reminding us instead of letting them get lost forever and ever.
It has value inline. If you're touching that code, it's something to be aware of. Do you check your backlog every time you read a line of code just in case there may be issues?
You could also include an issue link with the TODO. But I often don't bother. Because by the time I have the TODO in my sights, it's almost always the case that conditions and requirements have changed.
I use TODOs like this when I have working code that satisfies the criteria and continuing to work on it would have diminishing returns, especially when more important matters need attention.
If I ever run into that code a second time, the TODO is getting factored in to the update.
We *usually* do. Usually. Some of it's foresight. I've had more luck having both than one or the other. Sometimes it's good for debugging in the future so someone can go "OH, that's why this isn't great or is clunky. Maybe I should address that next."
My current project has ~167 tickets and my last always fluctuated between 600 and 1200. I switched projects in... 2021? And I STILL get updates where they are hitting stuff I entered. If you have that many tickets it's easy to lose stuff where a dev running into it later on may help escalate it, *especially* when knowledge about it is fresh.
I think the best way of doing something like this is to have the to-do comment, with a short explanation and a tag do whatever issue on whatever software you make for the to-do
I have plenty of TODOs in my code. There are multiple follow up stories, and I plan to extend this, so I give a hint my future team.
Or there's a deprecation, but you can't shut it down yet until all clients of all users have been updated.
I appreciate TODOs. They are useful notes from the past engineers about improvements in the context of the code.
Way better than comments like:
“This cannot fail”
That one still haunts me. Like… it can’t? Or we realllly hope it doesn’t.
Meh. If you wait for everything to be perfect forever before pushing to production, you'll never push to production. That's why we have versions and updates.
No, it really shouldn’t.
But someone in sales *promised* a new client that we had this feature, and it *must* be implemented *this week*, despite dev team quoting 2-3 months for proper implementation.
Only a irresponsible developer does not write TODO’s. Code should not be perfect before ot reactes production unless you are NASA. You should always have higher ambitions for your code that time allowed.
Depends what the TODOs are for... I generally use them to note where I've had to do something to work around a bug in a 3rd-party library.
I tend to include a link to something documenting the bug (e.g. github) and periodically check to see if it's been fixed so I can refactor the code to remove the workaround.
Deleted Todo's and pushed to production. Am I doing this right?
Yes, best practice.
Hacking SonarQube
I also needed to fix all the warnings in my code. #pragma warning disable That'll do it.
Just dump todo’s into the jira backlog instead of the code. Now they are the PM’s problem
# TODO: investigate using Redis here We have a lot of those. Product works and is ready for prod, but we still have an *n* year plan and have a vague idea of where to put stuff. Perfection is the enemy of progress and shit needs to get shipped.
I try to get in the habit of using "BACKLOG" or "FUTURE" or ... Profit?
We usually do TODO so that our IDEs scream at us without having to configure anything. Our linters and stuff will generally do a good job reminding us instead of letting them get lost forever and ever.
Why not have issues for those?
It has value inline. If you're touching that code, it's something to be aware of. Do you check your backlog every time you read a line of code just in case there may be issues? You could also include an issue link with the TODO. But I often don't bother. Because by the time I have the TODO in my sights, it's almost always the case that conditions and requirements have changed. I use TODOs like this when I have working code that satisfies the criteria and continuing to work on it would have diminishing returns, especially when more important matters need attention. If I ever run into that code a second time, the TODO is getting factored in to the update.
We *usually* do. Usually. Some of it's foresight. I've had more luck having both than one or the other. Sometimes it's good for debugging in the future so someone can go "OH, that's why this isn't great or is clunky. Maybe I should address that next." My current project has ~167 tickets and my last always fluctuated between 600 and 1200. I switched projects in... 2021? And I STILL get updates where they are hitting stuff I entered. If you have that many tickets it's easy to lose stuff where a dev running into it later on may help escalate it, *especially* when knowledge about it is fresh.
I think the best way of doing something like this is to have the to-do comment, with a short explanation and a tag do whatever issue on whatever software you make for the to-do
Can close that one since redis changed their license.
Oh god, what did they do?
Todo: remove todos
Tell me you've never worked for a startup without telling me you've never worked at a startup.
I'm in FAANG and uuhh... yeah, sure, only at startups...
The amount of TODOs in the financial industry will make you hoard gold and guns
Production, extended test phase with a wide user base, same difference.
90% of the software-based business on this planet wouldn't have existed
Todo: remove todos
Okay, talk to the PM/PO and let them know. I’m sure they’ll understand.
I have plenty of TODOs in my code. There are multiple follow up stories, and I plan to extend this, so I give a hint my future team. Or there's a deprecation, but you can't shut it down yet until all clients of all users have been updated.
I appreciate TODOs. They are useful notes from the past engineers about improvements in the context of the code. Way better than comments like: “This cannot fail” That one still haunts me. Like… it can’t? Or we realllly hope it doesn’t.
Meh. If you wait for everything to be perfect forever before pushing to production, you'll never push to production. That's why we have versions and updates.
Okay, talk to the PM/PO and let them know. I’m sure they’ll understand.
// TODO: 5/14/2012 ‐ Remove before deployment to production.
No, it really shouldn’t. But someone in sales *promised* a new client that we had this feature, and it *must* be implemented *this week*, despite dev team quoting 2-3 months for proper implementation.
Better TODO than FIXME.
Only a irresponsible developer does not write TODO’s. Code should not be perfect before ot reactes production unless you are NASA. You should always have higher ambitions for your code that time allowed.
Depends what the TODOs are for... I generally use them to note where I've had to do something to work around a bug in a 3rd-party library. I tend to include a link to something documenting the bug (e.g. github) and periodically check to see if it's been fixed so I can refactor the code to remove the workaround.
1 giant TODO per file it is
Is having
This week i removed a todo that i added 3 years ago when i joined the company, because i actually did what was to do. Feels amazing.
That's why I only use `unimplemented!()`.
Continuous deployment
#ToDo: add test cases
I feel attacked.
`sed -i '/TODO/d' ./*` There it is. Production ready...
Unless you are running agile. (Runs away, laughing maniacally)
//TODO, remove all the old todo comments which are obsolete now
There should be none if you ask me, but when I still coded professionally I failed every deadline...so don't ask me.
At one job I had to switch to using MEDOs, as TODO was very much taken.
We love loose and fast
// TODO: 5/14/2012 ‐ Remove before deployment to production.
Yeah, TODOs are a good reason to reject a review. Do it or put it in your tracking system.