While I agree with what you have said here, it’s not quite what I was getting at. I was trying to introduce some terms and point out difficulties identifying the members of the two sets, not just talk about plans. If I include anything about plans in particular in this sequence, that’ll be part 3.
Because I have multiple clever titles that I want to employ, not just one. Also, one really long article would annoy certain people and take longer to write than two or three brief ones.
Let’s add the terms to my summary: we generally start with a problem, something we’re not happy about; then we design a plan to solve it; executing the plan is a task.
A plan can only have so much detail. Doing sub-tasks I didn’t plan in sufficient detail, or which turned out to be unexpectedly difficult, are the remaining sub-problems. We should seek the best balance between pre-planning and deferring until a problem is encountered, and this is not trivial. Is that what you’re talking about?
Otherwise, your list headed The approximate ways in which a “have to” might be a problem can be simply restated as “the cases where there is no obvious plan”: when I lack procedural or propositional knowledge, or resources, which (I believe) are necessary to solve the problem. And then I can come up with a plan for when I’ve acquired them and go solve the sub-problem of getting what I need.
As I understood it, the purpose was to sharpen the boundary between what would otherwise be relatively fuzzy concepts, by going through the edge cases systematically. The individual facts given are all obvious, but consolidating them into a single crisp distinction is not so obvious and enables that distinction to be used elsewhere.
Don’t question your clarity too much. With so much prior knowledge about decision making schemes it is easy for your readers to match your words to other similar frameworks.
While I agree with what you have said here, it’s not quite what I was getting at. I was trying to introduce some terms and point out difficulties identifying the members of the two sets, not just talk about plans. If I include anything about plans in particular in this sequence, that’ll be part 3.
Why did you serialize the articles?
Because I have multiple clever titles that I want to employ, not just one. Also, one really long article would annoy certain people and take longer to write than two or three brief ones.
Let’s add the terms to my summary: we generally start with a problem, something we’re not happy about; then we design a plan to solve it; executing the plan is a task.
A plan can only have so much detail. Doing sub-tasks I didn’t plan in sufficient detail, or which turned out to be unexpectedly difficult, are the remaining sub-problems. We should seek the best balance between pre-planning and deferring until a problem is encountered, and this is not trivial. Is that what you’re talking about?
Otherwise, your list headed The approximate ways in which a “have to” might be a problem can be simply restated as “the cases where there is no obvious plan”: when I lack procedural or propositional knowledge, or resources, which (I believe) are necessary to solve the problem. And then I can come up with a plan for when I’ve acquired them and go solve the sub-problem of getting what I need.
As I understood it, the purpose was to sharpen the boundary between what would otherwise be relatively fuzzy concepts, by going through the edge cases systematically. The individual facts given are all obvious, but consolidating them into a single crisp distinction is not so obvious and enables that distinction to be used elsewhere.
Yes, thanks—this is more what I had in mind.
That’s definitely closer. I’m now concerned that I haven’t made this nearly as clear as I would have liked, though.
Don’t question your clarity too much. With so much prior knowledge about decision making schemes it is easy for your readers to match your words to other similar frameworks.