From 394681636f08f5e79aeaefadfbb665779996b7e4 Mon Sep 17 00:00:00 2001 From: ktyl Date: Thu, 17 Mar 2022 00:52:30 +0000 Subject: [PATCH] todo lists post update todo lists move blog to date folder --- blogs/2022/3/21/todo-lists.md | 103 ++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 blogs/2022/3/21/todo-lists.md diff --git a/blogs/2022/3/21/todo-lists.md b/blogs/2022/3/21/todo-lists.md new file mode 100644 index 0000000..e7f6e9f --- /dev/null +++ b/blogs/2022/3/21/todo-lists.md @@ -0,0 +1,103 @@ +# todo trees: project management for prototypes + +!! If you're not the kind of person to have a favourite text editor you're probably not the target audience of this post. +I talk mainly about software projects, since that's my bias/experience, though I think the principles are widely applicable. +You have been warned. + +Having a number of side projects, I like to adhere to the principle of making it as easy as possible to start work. +Though often distract by shinier objects, I try to keep as many interesting projects ticking over at once. +Projects vary in scope, tooling and complexity and are driven mostly by fleeting bursts of inspiration. + +This in mind, I find it's best to keep my project management as light and available as I can. +Though card-based kanban or scrum based tools like [Trello](https://trello.com/), [Jira](https://www.atlassian.com/software/jira) or the issue trackers integrated into [GitHub](https://github.com/features/issues) or [Gitlab](https://docs.gitlab.com/ee/user/project/issue_board.html) are great for team coordination, planning releases and responding to customer feedback, I find them a bit cumbersome for stream-of-consciousness making-for-fun. + +For one, they all need an internet connection, and a full-fat web-browser to boot. +That's a lot of system load (read: a lot of battery use!) for what is really just glorified post-its. +Browsers also carry a distraction risk; I might start with good intentions but new tabs are just too easy to open. +They also need a login. I would hate to come back to a project years from now after combing through an old hard drive to find its tasks locked in an long-lost account. + +Instead, I keep project notes in nested todo lists, or todo trees. +They look like this: + +``` +* [x] landing page +* [x] gallery + * [x] add pictures + * [x] apply styles + * [x] responsive design +* [x] about +* [-] blog + * [-] write some blog posts + * [x] git server + * [-] todo trees + * [x] self-referential humour + * [-] cogent argument + * [ ] referencing + * [ ] relativistic ray tracing + * [ ] generate html +``` + +I'd just like to take a few paragraphs to explain why I like this method of organisation. + +## Flexible, accessible + +Keeping it simple means it can be used in simple tools. +Simple tools have limitations, which often play to their advantage. +For example, using a monospaced font I may be restricted to only a hundred or so columns per line, which will of course restrict how long I can make an item and still have it be readable. +This isn't actually a limitation at all, but instead encourages me to write short items that are to the point. +If something is more complex, I can add sub-items. +The end result is that my items start to read almost example like the commit messages I'm about to make while implementing them. + +## Learnable, memorable, imperishable + +Just from looking at an example it's clear how it works. +There's basically one rule: + +> Items with sub-items cannot be completed until all sub-items are completed. + +I don't need to remember any features of any organisation tool. +I can create a list on anything with a text editor (it is a bit awkward on mobile, but so is kanban). +It will still be readable and make sense decades from now. + +## Todo-aided design + +Projects are often structured like trees. +In a physical sense (insofar as digital files are physical) filesystems impose a tree structure on collections of files, organising them into directories, and so software projects are virtually all trees of some kind. +In a (frustatingly) less tangible sense projects can be regarded as trees when describing their features, too; a website has a landing page, a navbar, a hero image, a footer... + +As such, organising todos into a tree encourages design that meshes with a view of the finished thing. +When I find myself adding suspiciously similar-looking sub-items in different parts of the tree, I often find it's because I've made some design errors. +It's a good opportunity then to re-think my current design and re-organise the tree to fit. +Which brings me nicely onto... + +## A living document + +A frequent issue with any project documentation is that it goes stale. +This is rarely good, and can have a range of effects from being outright wrong to just making every search for truth into a miserable trudge through reams of information which just isn't relevant. +This is particularly an issue in wikis, as almost all the information is deliberately (though quite understandably) not visible at any one time, making it forgettable, forgotten, and ultimately opaque. + +With just a todo tree however, the cost of re-organising is low. +Those comfortable with their [favourite text editor](https://ash-k.itch.io/textreme) will be comfortable moving lines around, indenting whole blocks, and adding or removing items in bulk. + +I also feel no qualms about deleting things often. After a little while hacking a way at a project, todos quickly become outdated and unnecessary, as designs or intentions change. +That's fine and a natural part of project development, so it's healthy to cull them every once in a while. +Because they were so little effort to create, it's also not painful to let them go. +In a project with source control, deleted items can always be retrieved later if they are really missed. + +These elements help to keep a project focused, though still leave room for the random meandering exploration that makes side projects so much fun in the first place. + +## Built-in scope control + +The most obvious limitation of todo trees is their linearly increasing complexity. +As a project grows, more features are added, which are broken down into more tasks, more indents, more sub-items until it becomes unmanageably large. +However, from another perspective, we see this isn't actually a limitation, but rather a feature unto itself - it keeps the project scope in check. + +Scope creep is a universal problem, and though orgnaisation tools may promise the moon in helping its users overcome it, ultimately that is the responsibility of the craftsperson, not their tools. +By keeping project documentation and management light on the ground during prototyping, the most focus can be given to the creation, to validate the idea as quickly as possible before over-committing. +An upper limit to project management items discourages over-planning and encourages clearing completed items, which keep the project moving and not getting choice paralysed when picking up the next thing to do. + +## Final remarks + +I definitely didn't come up with this, but I also haven't seen it described as a project management strategy before either. +I got the idea from [GitHub-flavoured Markdown task list items](https://github.github.com/gfm/#task-list-items-extension-), but notably most renderers will only show three levels of indentation. +As such I like to just use monospaced text editors to look at and manage todo trees, whichever is the most available.