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 encountered this over the Summit weekend. 1.5 hour lunch with a couple of people who could not stop solving the Friendly AI problem.
Out of curiosity, what is the most promising suggestion regarding Friendly AI that you've heard from someone who had probably spent fewer than 48 hours thinking about it?
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.