(2021-08-03) Boyd Wrestling With The Angel Of Death

Stowe Boyd: Wrestling with the Angel of Death. In Hundreds of Ways to Get S#!+ Done—and We Still Don’t, Clive Thompson finds a lot wrong with how we approach task/work management, but he simply accepts a lot of preconceptions without really examining them, I feel. ((2021-07-28) Thompson Hundreds Of Ways To Get Shit Done, and We Still Don't)

The most fundamental preconception -- never examined by Thompson at all -- is the binary nature of tasks in nearly all task management tools. They are open and active or closed and inactive

I believe that a great deal of Thompson’s angst — and other users of task management tools — is related to this mistaken perception.

Thompson is right that there is no single common way to do task/work management

‘Vistas of despair’ is a bit much, Clive. Consider that the purpose of a task is not to be checked off: it’s a bit of information about us and our work. That might turn down the angst.

We are seeing defections away from baseline task/work management toward... alternatives support very different constituencies who are trying to accomplish very different things. In general, core task/work management tools are a bad fit for these constituencies, hence defection.

what if you are working with a group on a project? You can't just declare bankruptcy. You have to remove tasks that no longer make sense

I believe that managing tasks should be incorporated into the methods and tools we use to think, write, and remember. That might make me a better version of myself: not spiritually, but a me with a better memory.

I believe that the tasks that are part of our 'workings' -- our journals, notes, and other written materials -- should be embedded there. Not in a separate to-do, stand-alone, unintegrated app.

I never have to worry about bankruptcy because I manage four kinds of markdown journal files in my markdown-based 'work processing' approach. And I lay down new journal entries (note-taking) every day, and never delete anything.

This is a short introduction to my Taskora method for ‘work processing’. You can skip ahead if it’s too wonky for you.

Daily Journal -- I create a daily journal (daily review) file where I capture snippets of things I've read, ideas that have occurred to me, and links to materials I might read in the future. Generally, these items are tagged ('#platform-capitalism', or '#clive-thompson'), and often associated with tasks.

I seldom worry about how many tasks exist in my journal, nor do I feel the weight of the tasks there. They are milestones, landmarks, and aspirations, not pebbles in my shoes.

Meetings/Calls -- I keep notes during calls, and often create tasks for action items.

As in all cases, I rely on the search capability in my markdown platform, Typora, to search for all tasks related to 'work futures', 'AdjectiveNoun', or 'Miller's Plumbing'. This task is urgent, denoted by the exclamation mark ( ‘- [!]’).

Projects -- Once an activity becomes large enough to warrant it, I create a journal file for the project describing what it’s about, pending and completed action items, and so on.

Since these change frequently, I often timestamp sections of the project file (newest at the top) and move tasks forward, or indicate their status

Source Materials -- I keep large excerpts or complete copies of material I plan to refer to and reread. Can include tasks, but always includes a lot of tags. (This is part of my streamlined zettelkasten method, too detailed to explain here.)

One thing to note: tasks in the Taskora convention are spread all over the place. I don’t have long lists of tasks all by themselves. Tasks are embedded in the text that I use to explain, plan, consider, and remember. I create nothing like a ‘list of shame’. Tasks are just a special form of notes that I leave behind in my daily meanderings, and that I can find again by search.

Note that the way I denote tasks is not ‘supported’ in Typora: it’s just a convention using text. I am actually avoiding the binary tasks supported directly in Typora

*I would never declare task bankruptcy because tasks are woven into my workings, the way that I think, write, and remember. Bankruptcy is just not a consideration.

Yes, projects come and go. Yes, I create aspirational tasks ( ‘- [?]’ ) that I may never return to. So what?*

I would never declare task bankruptcy because tasks are woven into my workings, the way that I think, write, and remember. Bankruptcy is just not a consideration. Yes, projects come and go. Yes, I create aspirational tasks

At the end of a year (usually a few months into the new year), I create a new folder for the entries for the new year (like 2022, say next April) and move all the markdown files — journal entries, meetings/calls, and still-active projects — into the 'Journal 2022' folder. The 2021 items stay in their 2021 folder

Thompson describes various approaches he's used to manage tasks and they share one glaring characteristic: they were isolated from the tools and methods he uses to keep track of everything other than tasks.

Why waste time winnowing away tasks? I can understand the desire to review the status of the AdjectiveNoun project, but why throw tasks away? Just change their state, if necessary. Make a task urgent, make another inactive, create a new provisional task.

Me, I don't care about increasing output, I just want better outcomes. And a better memory.