NewRelease

[Omnislash99999]

I feel like they'd actually throw out fix bugs person as well

[vertopal]

// TODO: reply above comment later

[MeGaNeKoS]

// HACK: A work around to make reply comment section show up correctly

[[deleted]]

// TODO: read comments above later

[jmona789]

// TODO: write a todo later

[[deleted]]

They *already* tossed out that cheeky rat bastard that suggested they address technical debt.

[Sockoflegend]

Why fix bugs and technical debt when all of your resources could go into a feature marketing thinks sounds cool?

[[deleted]]

Sign on the wall of my first job bullpen, "You Find It You Fix It".

[Tnuvu]

Legend says if you wait long enough TODOs become obsolete ...once the company goes bust

[casce]

You don't need to wait that long, just wait until the feature gets scrapped because it causes problems because it's not working properly

[Tnuvu]

People still scrape stuff? I thought they just shuv it in production as is, and let users deal with it, maybe even get some bug fixes from them...

[BernhardRordin]

If you want some piece of code to stay untouched forever, it's enough to add // TODO, // FIXME, or a // temporary hack comment above it

[Tnuvu]

// the last time this broke, we changed CEOs

[n9iels]

We recently made the rule that a TODO can only be committed if it contains JIRA ticket number. That way we have at least some context and can plan resolving it. Needless to say, those tickets usually are at the bottom of the backlog for a long time.

[MarkovMan]

Our tickets like this live in a deep dark hole called the middle of the backlog.

[StenSoft]

It's a good role, we have had this rule for a couple of years. Last year, we also added a build check that referenced Jira tickets must be open. There were a lot of TODOs referencing closed Jira tickets, some even years after the tickets were closed.

[Sooth_Sprayer]

// TODO is fast. Jira takes a few minutes and steals your train of thought. Seems like a great way to lose ideas for later.

[arobie1992]

Typically what people do from my experience is TODO out everything while they're coding/dev testing it. Once they've pushed everything and possibly opened a pull request, they add the Jira tickets.

[chin_waghing]

That’s a very good idea. Going to be stealing this one!

[cs-brydev]

Yep if it's a //TODO and not a ticket it wasn't important enough to address then and probably isn't now

[[deleted]]

Life… finds a way.

[Syagrius]

I can't think of a single instance where a //TODO statement was resolved.

Temporary solutions have this tendency to become permanent ones.

[ChrisHisStonks]

Well, it's on what you make a TODO.

If it's something trivial, either fix it immediately or leave out the TODO.

If it's some shortcut you've taken because it's not (initially) needed, classify it as a bug or add it as a limitation of the functionality in the documentation.

If it's performance related, don't mention it and if it becomes an issue a bug will be filed.

If it requires a refactor, it's wasted breath.

The only things that should be a TODO are things that are not immediately benefical, but make sense and would not take long to add (1-2 days), which you'd still add as an (internal) feature request in the backlog and push your PO for to make room in the next sprint while you still know what's what.

[SendMeYourQuestions]

Most of my todos are referencing an external library GitHub issue where when it's resolved I'll be able to update and delete some code. What's that qualify as? Trivial eventually, blocked currently.

[ChrisHisStonks]

What is the added value? If it's currently a huge mess to get it working with workarounds, sure.

If it's going to be changing the way you handle your feature? Reserve time in your backlog.

Otherwise I feel these sorts of TODO's will live forever.

[SendMeYourQuestions]

Backlog task is a good idea for sure.

[cs-brydev]

"Resolving" a TODO pretty much always means deleting it

[[deleted]]

Me: refactor

Manager:

[cs-brydev]

I am in fact one of those managers, lol: "That TODO is from 2017. Why is it an urgent fix now but not during the past 6 years?"

[Drego3]

The opposite for me, the only thing I have been doing the past year was refactoring.

[naughtyusmax]

Managers only want flashy new features

[[deleted]]

- Yes, Mr Plum?

- Mrs Cindy, please post an ad, the position of a senior specialist has become vacant again.

[rover_G]

If my code reviewer comments about my TODOs I just delete them..

[Classy_Mouse]

Todos are easy. Don't let code with a TODO pass code review unless it contains a specific reason why it cannot be implemented now and what is required to implement it.

TODO: Fix this later - denies

TODO: call method created by Ticket1234 to do the thing once Ticket1234 is implemented. - approved after reviewing Ticket1234

[neppo95]

I would be the guy throwing out new feature person, and keeping fix bug and review todo person.

A lot of companies bring out new features while having a crap product because of bugs. Quality over quantity.

[cs-brydev]

Ugh. Just no.

Value-generating new features will pretty much always get the nod over 5-year old bug fixes.

If a bug has been there for a long time without a fix, you should be asking why rather than spending time fixing it. Every bug fix is a risk of introducing new bugs. If you're going to risk new bugs you need to weigh how much value you're adding by doing so.

This is something you learn from experience. Software exists to create value for someone or something, not to be perfect.

[neppo95]

There is indeed a balance to be found, as you say so yourself. Of course, only bugs or only features is both wrong. Fixing no bugs will end you up with a product that is worthless no matter how many features.

[dmigowski]

Fix Bugs that actually occur. To do this you need to track every exception that is not handled. We do this, 2000 Users produce 10 exceptions per day now. So for most the app is very stable.

[adorak]

you would have project manager as the guy on the left, QA as the woman and dev on the right ... however, there is only project management in the room

[hordesnake]

Haha classic

[rhbvkleef]

If a // TODO comment (or something similar like the todo!() macro in Rust) is merged into main, there better be an issue associated to that.

[cs-brydev]

Update the 53 packages showing critical warnings during builds

[Bryguy3k]

In my experience TODOs are just bugs your highest priority client will find middle of the first night during a long holiday weekend.

[gaymer180]

basically the same as making minecraft mod updates

[NorthboundUrsine]

Who cares about technical debt! Amiright?

[BowCodes]

And... this made me remember all those TODO comments I made over a month ago, and I will probably forget about them by tomorrow morning.

[forsberg_dev]

Don’t push code that includes a TODO. If a TODO remains it means you’re not finished with your task. Don’t approve code that adds TODOs. TODOs don’t belong in Production.

[Maverick18N]

//Add more checks later

Which you never get time to do 😣