= 27d567bc2d48d9f40e9ccc20ea370b15)
DanArmak comments on The First Step is to Admit That You Have a Problem - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (86)
Short summary:
As far as I understand, all the rest is examples. Did I miss anything?
I didn't see the post as being about plans at all. Planning is vastly overrated anyway. Planning is solving the problem in your imagination, and the more steps, the less likely they are to all proceed as imagined.
Ask a car mechanic how often a repair can be completed by first planning out each thing that needs to be done, then executing the plan. My experience of doing occasional work on my car has been that it never goes exactly as described in the Haynes manual, and that's not a criticism of the manual.
While I would say that it is more common for people to plan too little than to plan too much, I think that point one here is worded so strongly I would disagree. Most plans don't even consist of entire sequences of actions, even for very small simple tasks such as writing this comment, during which I took multiple unplanned actions including noting that I took them, none of which would have been worth planning for.
Plans have a level of granularity beyond which you don't plan in advance. As I said in another reply, stopping at the correct regularity is important and sometimes difficult.
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.