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:
- If you want a peanut butter sandwich, and you have the tools, ingredients, and knowhow that are required to make a peanut butter sandwich, you have a task on your hands. If you want a peanut butter sandwich, but you lack one or more of those items, you have a problem.
- If you are sad, and you know that this is because you have not seen your favorite cousin in a while, and you have the wherewithal to arrange to have your cousin over, then arranging to have your cousin over is a task. If you are sad, and you don't know why, then the sadness is a problem.
- If eight of your friends are involved in massive unpleasant social drama, but you have a forty-three-step surefire plan to calm down the angry and smooth over the ruffled and chew out the misbehaved and bring back the normalcy, you have forty-three subtasks of one big task. If you have no clue what the heck is up with the drama but it's on your last nerve, problem ahoy!
- If you are a mortal creature, you may already be a problem-haver.
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:
- Lacking resources. Resources include tools, materials, cash, space to operate, cooperative other persons, time, physical capacities, and anything else that will contribute directly to the bringing about of the outcome. For instance, if you can't afford the milk you need to buy, carry it home once you've bought it because you have injured your elbow, or fit it into the fridge because the fridge is full of blueberry trifle, that's a resource problem.
- Lacking propositional knowledge. For instance, if you don't know where Zanzibar is, that's a propositional knowledge problem.
- Lacking procedural knowledge or skill. This overlaps somewhat with propositional knowledge, but roughly, it's data about how to go about applying your resources towards your goal. For instance, if you don't know how to best approach your exchange student's learning style, that's a procedural knowledge problem.
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.
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.