TODOs are crufty ambiguous notes that often poorly describe the current system and potential future work... and they're so easy to add that the average "todo" is very low-value, dragging down the perceived ROI of fixing any tech debt.

I keep the two separate: good notes describing the state of the world, and a calendar to schedule future actions.

When it comes to software, that means all code must have good documentation and known flaws are scheduled to be fixed. If it's not worth scheduling, it's not worth changing.

My personal life follows the same pattern, although much less formal... there just isn't enough time for every possibility, so I always work backwards from my calendar.

In practice, most people's "todo" list ends up being the garbage bin for low-priority items that they'll never actually do. It's worth separating the things you actually plan to do next week/month, from the ones in a "backlog".

Grep any large code repository for "TODO" comments.

As someone who's worked on multiple teams that used TODO comments and then had a regular type of sprint in which they were grepped and cleared (these weren't perfect projects, there were other organisational problems, but this particular thing was handled well), I was actually quite surprised to get into a discussion recently here on HN about projects where this doesn't happen and TODO comments end up being largely aspirational.

However, I think code and life are slightly different contexts here. I get what you mean about separating aspirations from near-term actual intents but I generally use the word "todo" to refer exclusively to the latter (which still doesn't help a whole lot with ensuring execution as the list still grows quite large).