Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What do you do when an idea changes and now there are dozens of nested entries that need to be changed to match?


Generally, with this type of work (where I'm trying to go fast), I have to be flexible, so I will often just let nested tasks "die off" after I've found alternative ways of solving the problem or I've changed the idea a bit.

Sometimes I'll delete the nested entries outright, but usually I'll just keep them around until I get to a point where I'm close to completing the feature and then I'll re-visit them to see if they still apply or if I need to reincorporate them into the new design.


> What do you do when an idea changes and now there are dozens of nested entries that need to be changed to match?

I use this tool: https://github.com/lelanthran/frame/blob/master/docs/FrameIn...

It allows me to drop a node in the tree, dropping all children along with it. Or rename arbitrary nodes in the tree, or move them around.


This looks very cool, especially for hobby projects. I follow approximately the same flow with infinitely nested TODOs in logseq.

The cli tree flow is very likely better, but those destructive pops -- it would be hard for me to let go of the ability to look back at the end of the day retrospectively and see the path that was explored.


> The cli tree flow is very likely better, but those destructive pops -- it would be hard for me to let go of the ability to look back at the end of the day retrospectively and see the path that was explored.

It's a trade-off: aggressively pruning the noise leaves a lot of signal. I have also found that, when writing down goals/objectives/tasks/whatever, knowing in advance that they are going to be discarded once done makes them more focused on achieving the goal, rather than trying to document what is done.

Essentially, when adding nodes, I add directives to be filled, not documentation for what was done. This keeps me focused on achieving the goal without getting side-tracked by putting in explanatory documentation for future me.

The notes I make are to allow future me to implement $thing, not future me to understand $thing.


I thought that might be the case, and I did stop to wonder if I just wanted to see the path out of pure self gratification or if there's something valuable in taking a step back and assessing the process after the fact.

It's probably the former


i use a modified form of https://xit.jotaen.net/ for my task lists. xit uses [~] notation for obsolete tasks. sometimes an entire branch gets this. i also avoid fleshing out tasks in detail until i've settled on the design for the higher level goal.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: