[stephenhandley]

Effective TODOs capture a code-level design tradeoff and any associated debt which

- won't have sufficient positive impact on the bug/feature you are working on

- you don't have time to address at that point in time

- are significant enough to require pay down later

How to address them in terms of tooling and process is a way bigger question

[alex-moon]

I think this is a really good way to think of it actually. My business partner and I often have this back and forth: "Do you want this done the right way or the fast way?" Most often we do a "happy medium" between the two and accept that there is work to be done in the future. This is not a bad way to do it, as more often than not the "right way" actually needs quite a bit more customer research first - often pushing "Todo" code to production reveals the use cases that show that the suspected "right way" was wrong, and the actual "right way" is to burn all the code and use a completely different existing module to do it instead, consolidating what were (incorrectly) understood to be different use cases. This is probably my favourite way of paying down technical debt.