On using #todo lists efficiently
This short write-up by @bzg is a must-read to keep a sane level of to-do lists and tasks. I constantly struggle with it as well. #PIM
Maybe I know, maybe I don’t.
But article does not encompass his background.
I find your work very interesting, and need to study much of it.
The article mentioned is subjective not objective. Some things I agree upon, some not.
Very often to-do lists become your enemy
Not that I can agree on that. Never happened to me. But I did understand him, it did happen to him. That is why I say it is subjective.
Because it gives you a false sense of control, it slowly erodes your goals’ clarity, which weakens your motivation
Programmer is not necessary a planner, even a programmer of software used for planning. Not that I have ever experienced false sense of control. This may be due to somebody taught me to start planning from objectives down the hierarchy. My tasks and projects are separate by groups or people, there is absolutely no confusion. Goals clarify cannot erode as goals have been defined in the first place.
It is very subjective experience, not objective.
On my side, as I learned somewhere back in 1994-95, that I should first define purposes (objectives). There are different methodologies, I use that one with objectives and subordinate tasks. No wonder militaries are using same methodology.
to be continued…
So what is the right way?
I understand the right way for him is to write less to-do items, more notes, take extra care of agenda, write precise, atomic tasks.
Where bzg explains:
But do not blur the line between what you want to remember and what you need to do3. Your to-do list should be a list of things to do, not to remember.
True it should not be just something to remember, should be to-do. It is somehow logical, but hard for me to correlate it. I have worked with large organizations and project planning and execution, and just nobody ever had problems, maybe because we learned how to write projects, and never got opportunity to get caught into bzg’s described situations.
I just don’t get it, is hard to understand how somebody can blur the line between something as a note for remembering and something as a note about action to be done (TODO). Such person is doing something fundamentally wrong.
He may have so much more experience with people who got into that kind of confusion from Org mailing list.
My side, we don’t have that kind of confusion. I am assigning projects all time to people, every day they are finishing their tasks and reporting back. And I, relaxed, can track their progress. The to-do lists are well written from objectives, purposes, down to subordinate tasks, where each task is doable on its own. Only doable tasks are included. Any necessary information is part of task instructions. There are no notes that are to confuse neither me nor the assigned person.
Things to-do are things to do. A general advise to write less to-do and more notes does not help. Person must be in the same specific situation as bzg to correlate to that situation.
To-do lists should describe what you must do, not what you want to do, which belongs on the “remember” list until you really must do it.
Article is not clearly defining things, from the first principle involved there is not much practical use.
If TO-DO task is to install Androzic application, it is both something I must do, and something I want to do. We know why, because we have to measure areas on the field, or send geographical way-points to each other. We all want it, we all must do it.
IMHO, things that one really has to do imminently will not be even written in planner space, be it paper space or digital files. You have to take a kid from kindergarten and that is something you have to do imminently, it is in your memory, and you simply do it.
Planning papers or software is used almost always for things that are not imminent, not close to occur. Note by definition is any brief written record, could be a task like TO-DO and could be just note to remember. But both of those types belong to “something to remember”, as that is why TODO items are written down, as not to lose track of it, thus to remember them. Expressions in the articles are not clear, but I can understand that author had problems and confusion.
to be continued…
On 2nd principle, take care of agenda, I agree with it, but I just don’t agree or cannot see objectively why author expects public to have same problem as himself.
I have not get ever problem with agenda. Sometimes I had 180 appointments in a single year, all over the year. I cannot correlate his troubles to me personally.
Write precise, concise, atomic tasks. Notes can be loosely written, but tasks need to be efficiently described. Make them short and self-sufficient. If you need contextual information, link to it, don’t include it. Because context can change and tasks will move.
Not that I can agree to it for the sake of communication and understanding. If I am writing task specifically for myself, like “deposit 100,000 into VISA card” then I need not describe that the bank is UBA, neither where the bank is located, as it is just a short reminder, while majority of information as a context remains in my mind.
However, if task has to be repeated, or if task has to be assigned to another person, such task has to be completely self-contained. There are few ways how a task is delegated: it may be printed on paper and given to person or group of people, it may be sent by email, or SMS, even spoken out on the phone by assistant or me personally.
A task in that sense, has to contain all the context necessary for understanding and execution. A task written in Org mode can be printed and given to person who is in remote mountains, and hyperlinks there don’t help. IMHO, context has to be in the task description unless person is using a note or task item as personal reminder where all of the context is in the mind of individual.
For any repeatable tasks and tasks in projects assigned to multiple people, all relevant context has to be described and known from the project papers.
If a task is too loosely described or contains too many details, it probably belongs on a “remember” list.
Well, if task is too loosely described, it probably has to be well described. Lossely described task by that terminology does not change itself into a note to remember. If you have to repair your car, but don’t write specifically which parts have to be repaired, that will not diminish the need to repair the car. It has to be repaired, it is not just a note.
A task could contain too many details, but that could be subjective, as people with experience of doing same type of tasks may have more context in their mind, while some other people may not. The context has to be described in full for full understanding to take place. It is very easy for the one who already knows much of the context to skip reading whatever is deemed already understood.
Now I suspect we are all very bad at using to-do lists. Why?
Let me conclude with it, the article is very subjective.
I have currently about 97 people doing the project, each project having 105 tasks to do, each of them reporting back, none of them using TODO marks as all tasks are actionable items, it is clear from context what is to be done and what is description, each project produced by Org mode; those who finish faster become a good candidate for our business and we learn about each other. From my experience I cannot share the bzg’s feelings.
IMHO, he has to learn various planning methodologies as Org mode does not dictate any of them.
@louis @bzg Wow, what a response.
"So what is the right way?" I think that bzg did not write a self-contained full set of todo management tips. He just noted one thing you might do wrong. This one thing may be related to Org in a way because Org is one of the tools that technically "allow" users to do this wrong. At least I have fallen into this trap multiple times.
@louis @bzg In business context, tools are usually only able to deal with concise(?) tasks and not intertwine them with any sort of knowledge management. In those cases, you won't find yourself falling into the said trap. In this light, this is an advantage. From a different perspective, the lack of freedom to accomplish this mistake is a sign that the tool does not allow to do other things that may be a good thing when used in the right way. And for many things "the right way" is subjective.
Mastodon ist ein freies, dezentrales soziales Netzwerk. Diese Instanz hat einen Fokus auf den Grazer Raum und Österreich. Jedoch sind alle willkommen!