todo lists post

update todo lists

move blog to date folder

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.