I thought that everything in this article was obviously both true and important - enough that I promoted it as soon as I saw it, instead of waiting for it to be upvoted further. To clarify: It's not about low-level versus high-level goals. It's not about what you can do immediately versus later, or with or without further resources, or with or without breaking it down further.
It's about what you know how to solve, versus what you don't know how to solve; and the feeling of internal panic when you confront something you don't know how to solve; and the worst possible thing you can do to deal with that internal panic, which is to instantly propose a solution that turns it into a "task" but one that won't work. And HughRistik has an incredibly good point about the external converse, when people who are already good at something give advice that completely fails to turn a problem into a task. Alicorn's post is true and important because making the explicit distinction may help people on both the internal and external problems.
I encountered this over the Summit weekend. 1.5 hour lunch with a couple of people who could not stop solving the Friendly AI problem.
I suggest there's a third major way to fail, especially among smart people: crunching the problems into tasks and stopping. Not actually doing the tasks.
If you follow your intuition and good things never happen, it's time to take the Romantic view and put it on a rocket ship and fire that rocket ship into the Sun.
If eight of your friends are involved in massive unpleasant social drama
... then my first step is to admit that they have a problem. In times past, I may not have noticed that distinction, to the detriment of my decision making. I say this to emphasise just how important the step of identifying the problem is. If I neglected this step I may jump straight into 'dramatic' tasks without thinking.
Once I realize that my problem is "something is getting on my nerves" I can begin looking for solutions. Whether that be quashing social conflict or reassessing my personal boundaries.
I like the definition given in Gause and Weinberg's "Are Your Lights On", a book I'd recommend to anyone thinking about the topics in this post: "A problem is a difference between things as desired and things as perceived."
Sometimes the resolution involves bringing "things" (i.e. reality) in line with our desires, after we (correctly) perceive it to be different from the desired reality. This will normally involve tasks. (We usually speak of a "project" if we envision many tasks, in particular if they have a hierarch...
This is an interesting idea, though I'm not sure if it's terribly useful.. Here's a summary that may make more sense for some readers. The examples are entertaining, but they may obfuscate the central point a little.
-A "task" is where you have some goal, D, and some series of operations, A, B, and C that will result in the attainment of this goal. All you have to do is actually carry out those operations and you should attain your goal.
-A "problem" is where you have goal D, but you do not know any series of operations that you could pot...
Short summary:
As far as I understand, all the rest is examples. Did I miss anything?
The second sentence of the article should answer, why is it a critical faculty to consciously distinguish tasks from problems. The answer comes much later ("Because treating problems like tasks will slow you down in solving them.") and still isn't satisfactory. My first reaction is "never happens".
In other words, I've never thought about it like that before, but I'm not convinced I should have.
This was originally part of my summary, but it didn't make sense there.
I take issue with "lack of resources" having its own category. It seems like a special case of a lack of procedural knowledge.
If I don't have bread, it's only a problem if I don't know how to get bread and I don't know how to figure out how to get bread. If my elbow is broken and I need to get milk home, the problem is not my lack of working elbows so much as my lack of knowing how to get the milk home without using the elbow. Having a working elbow would also solve the probl...
Even if you know of possible solutions to a problem, it doesn't become a task until the solutions are good solutions.
That is, if you have all the knowledge to complete a task, you still have a problem if your actions will lead to negative side effects.
What I'm wondering is whether the problem-task distinction represents different categories? Or different points on the ends of a continuum?
Some types of problems may resist being completely taskified, particularly unstructured socializing and other improvisation-heavy tasks. Successful execution in those areas requires being more in-the-moment rather than following pre-defined procedure. You could say that the end of the procedure is to "be in the moment," or "act on your feelings," but that's still awfully general and would stretch the...
But for every task, person wants to perform it as efficiently as possible, thus rendering that task into a problem in the sense that it was used in this post. This is why I think distinguishing the two like that might be misleading.
1) Problem X
2) Task "Think on a solution to the Problem X until it taskifies to some Task Y" + Task Y
Is (1) -> (2) a valid transition?
I think lot of people indirectly follow the things written in the post--I certainly do. What we actually try to do all the time is: Not try to control things which cannot be, we have to accept certain things are beyond us, and we deal with things which we think we can deal with, isn't it?
This an amazing paradigm that can be used in project management.
Take a problem break into tasks and sub-problems, keep breaking until sub-problems can not be reduced into tasks. Then we can measure the risks involved, etc.
I think the terminology that's familiar to many LW readers calls "problems", "goals", and "tasks", "subgoals". Framing it that way, there isn't a difference between tasks and problems as such - a task/subgoal is merely what you get when you break down the problem/goal to smaller parts.
It seems to me you can move between the two framings by simply changing the way you describe the top-level objectives. If the top-level objectives are undesirable things that you want to change, they're problems. If they're desirable things you want to see happen, they're goals.
Thanks! I'd been contemplating a post about "The unreasonable importance of procedural knowledge", now I don't have to write it. Eagerly awaiting the sequel. Also, thanks HughRistik for the examples.
I think it might be more useful to use the term "goal" instead of "task", since task implies a series of steps -- a sequence of operations that change the state of the world, whereas a "problem" is a state of the world.
IOW, task = goal state - problem state. (Except it's not really subtraction, because there are potentially an infinite number of task sequences that will get you to the goal state from the current state... which is another reason why I think that maybe "goal" is a better word here.)
Goldratt's "T...
I'm not sure I agree with this distinction as any more than one of degree. Both tasks and problems are differences between the perceived state of the world and a desired state of the world.
As you describe it, "tasks" tend to be plans of action which you expect to have acceptible cost for their probability of success in moving the world state to the desired one. "problems" are just situations where the cost of the actions you're considering are too high for their probability of success.
I believe that both cost of planned actions an...
This is part 1 of a sequence on problem solving. Here is part 2.
It is a critical faculty to distinguish tasks from problems. A task is something you do because you predict it will get you from one state of affairs to another state of affairs that you prefer. A problem is an unacceptable/displeasing state of affairs, now or in the likely future. So a task is something you do, or can do, while a problem is something that is, or may be. For example:
Problems are solved by turning them into tasks and carrying out those tasks. Turning problems into tasks can sometimes be problematic in itself, although small taskifications can be tasky. For instance, in the peanut butter sandwich case, if your only missing component for sandwich-making is bread, it doesn't take much mental acrobatics to determine that you now have two tasks to be conducted in order: 1. obtain bread, 2. make sandwich. Figuring out why you're sad, in case two, could be a task (if you're really good at introspecting accurately, or are very familiar with the cousin-missing type of sadness in particular) or could be a problem (if you're not good at that, or if you've never missed your favorite cousin before and have no prior experience with the precise feeling). And so on.
Why draw this distinction with such care? Because treating problems like tasks will slow you down in solving them. You can't just become immortal any more than you can just make a peanut butter sandwich without any bread. And agonizing about "why I can't just do this" will produce the solution to very few problems. First, you have to figure out how to taskify the problem. And the first step is to understand that you have a problem.
Identifying problems is surprisingly difficult. The language we use for them is almost precisely like the language we use for tasks: "I have to help the exchange student learn English." "I have to pick up milk on the way home from school." "I have to clean the grout." "I have to travel to Zanzibar." Some of these are more likely to be problems than others, but any of them could be, because problemhood and taskiness depend on factors other than what it is you're supposed to wind up with at the end. You can easily say what you want to wind up with after finishing doing any of the above "have to's": a bilingual student, a fridge that contains milk, clean grout, the property of being in Zanzibar. But for each outcome to unfold correctly, resources that you might or might not have will be called for. Does the exchange student benefit most from repetition, or having everything explained in song, or do you need to pepper your teaching with mnemonics? Do you have cash in your wallet for milk? Do you know what household items will clean grout and what items will dissolve it entirely? Where the hell is Zanzibar, anyway? The approximate ways in which a "have to" might be a problem are these:
So when you have to do something, you can tell whether it's a problem or a task by checking whether you have all of these things. That's not going to be foolproof: certain knowledge gaps can obscure themselves and other shortfalls too. If I mistakenly think that the store from which I want to purchase milk is open 24 hours a day, I have a milk-buying problem and may not realize it until I try to walk into the building and find it locked.
Part 2 of this sequence will get into what to do when you have identified a problem.