The First Step is to Admit That You Have a Problem

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.

Moved to top level post

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 hierarchical structure, in particular if we're aware we don't know all of the tasks.)

Sometimes too, perhaps more often than we think, the resolution involves bringing our desires in line with reality; or correcting our perceptions, so that the problem is dissolved rather than solved. Not all problem are solved by turning them into tasks, in other words.

An extremely common failure mode of human planners is to jump to solutions, and systematically these are task-solutions. If the first step is to declare that you have a problem, maybe the second step is to frame a problem statement.

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 potentially perform to attain that goal. You need some additional information so that you can understand what procedures will yield D as a result. Once you have this information, you no longer have a problem; you have a task, and you merely need to perform the series of operations and you'll have D.

I think this gets the central point across effectively.

Short summary:

1. To achieve a goal, it's usually best to plan the entire sequence of actions in advance.
2. Coming up with a really good plan is often much harder than carrying it out.
3. We humans have a common failure mode where we don't stop to plan, or don't think out a plan before executing it, or even feel a problem is insoluble without having tried to come up with a plan.
4. Therefore it's useful to plan explicitly, to recognize when we do and don't have a plan, and to have a good estimate of success for the plan and of each step in it.

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 problem, but I really don't know how to instantly fix my elbow. If the fridge is full, the problem isn't the fridge being full so much as my not knowing how to organize the fridge so that there's room for the milk. If there is some constraint such that I can't take anything out of the fridge, I have an unsolvable problem, but absent such a constraint, my problem is better thought of as a lack of procedural knowledge rather than a lack of fridge space.

Of course, not all problems are solvable; if I ask you to lug a cubic meter of platinum back to your house without any mechanical assistance, it really doesn't matter how toned your elbows are; you aren't going to be able to do it - that much platinum would weigh about fifty thousand pounds. It's a problem that cannot be solved, because no procedure exists (within the given constraints) to obtain the desired result. If I ask you to make yourself immortal, it is quite possible that no procedure will accomplish that end within the constraints of reality; i.e. you may have a truly unsolvable problem.

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 notions of task and procedure.

Nevertheless, even in improvisational problems, you can apply heuristics to inspire you, even though you can't define the procedure completely in advance. That's why I think we might be better off talking of a continuum of our ability to define problems into tasks. How would improvisational problems fit into your framework?

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 "Theory of Constraints" (used heavily in manufacturing and other types of businesses) includes a set of "thinking processes" -- semi-formal planning tools based on boolean logic, that have an excellent breakdown of these notions into a very-reduced form. A couple of good books on them include "Thinking For A Change", by Lisa Scheinkopf, and "Goldratt's Theory Of Constraints", by H. William Dettmer.

There are also a fair number of TOC tutorials online, but I can't remember the last time I saw one that actually explained the logical basis of the tools, or things like the Categories of Legitimate Reservation (which are used to validate the logic of your problem analysis and plans).

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 and probability of success in moving to a desired world state are pretty close to continuous. There's no reasonable threshold between tasks and problems other than "unwilling to proceed", and even that is an action plan - "do without the desired change".

For BOTH tasks and problems, there may be alternate paths with higher probability of success or lower cost. There may not be. There may be alternate acceptible (or preferable!) destination world states for which there are better or easier to find plans of action. There may not be.