3 ms·
This is how I work on my projects as an indie dev. When I start working on something significant (a new feature, for instance), I'll create a markdown file that
by allenu 2y ago
This is how I work on my projects as an indie dev. When I start working on something significant (a new feature, for instance), I'll create a markdown file that has a summary of what I'm trying to achieve and then a TODOs section which turns into this massive outline of all the tasks that I'll need to do to complete the work.
At first, the outline just has a few tasks that are fairly high-level, but as I dive into each one, I add more nested sub-tasks. The nesting keeps going until I end up with sort of leaf nodes that can be done without depending on other tasks. This gives me a nice visual of how complex some tasks are versus others.
I generally prototype and design the implementation at the same time, and having this outline gives me a place to "dump" tasks and other work I'll need to do later, and you do often encounter more work than you expect, so an outline makes it easier to find a good "parent" for the task. Having a big outline also lets me jump around from high-level design to low-level implementation easily as well, which you need if you're prototyping and trying to find the right shape for your solution.
It's great as a motivator too since I can see when I complete something big when I check off a parent task that has a lot of nested children.
I find a simple text file outline like this is so much more convenient than say an app or a web UI since I can just jump around the file and cut and paste outlined sections and indent or un-indent them to re-parent them. (Having to use something like JIRA to do this would be way too slow, especially when you're in a flow state.)
- ukuina 2y agoWhat do you do when an idea changes and now there are dozens of nested entries that need to be changed to match?
- allenu 2y agoGenerally, 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.
- lelanthran 2y ago> 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/FrameIntroduction.odp 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.
- jddj 2y agoThis 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.
- lelanthran 2y ago> 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.
- jddj 2y agoI 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
- khimaros 2y agoi use a modified form of https://xit.jotaen.net/ 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.
- leetrout 2y agoSimilar here - i use asana or linear for highlevel planning with a calendar and then as I write code I drop in TODOs and FIXMEs and such then just grep them out or use a VS Code extension called "TODO Tree" to track them.
- darkteflon 2y agoSame here. I wrote a little multitree-based TUI with vim-adjacent key bindings for exactly this purpose, since I find it generalises to all complex projects, software-related or not (and who can resist any excuse to write a TUI?), but a simple markdown file is just as good, really, and for software means you can keep it in the repo directly adjacent to other project docs.
- iman453 2y agoSounds like you’re not looking for an app since a text file works well, but I’ve been using Godspeed and it’s been amazing for this kinda workflow.
- nomadic_09 2y agoWhat in the world... are you me?