I think there’s an overemphasis on planning in more and more detail. Some things are opaque at the point of making the plan. For example, some parts of a plan may require you do to things you don’t know how to do. That breaks down into (1) find out how, and (2) do it. But you don’t know what you’re going to find, and what acting on you find will look like. (2) is opaque at the planning stage, and may not even exist if the answer to (1) suggests a different way of going about the parent goal.
Also, things can go wrong during execution. No complicated car repair ever goes exactly as the Haynes manual says, and for all the convenience of satnavs, you sometimes have to notice that it’s sending you along a stupid route.
I recently had the goal of taking a piece of software I wrote in 100,000 lines of C++ and getting it to be callable from a web page, returning results to be embedded into the same web page, and running on a web server that it had never been compiled for before, starting from a position of knowing nothing about how to do dynamic web pages. It got done, but a plan would have looked like “1. Find a suitable technology for doing dynamic web pages. 2. Use it.”
You raise some good points about other things that can happen in planning, and your point about opacity in plans along with learning new skills is also something I hadn’t considered.
The general idea of “getting things done” doesn’t seem to vary, but there’s definitely much more room for variation than I’ve implied.
I think a large part of that is caused by my:
1) Inexperience with applying planning skills
2) Using them only on a very narrow range
3) Extrapolating from my personal experience.
I think there’s an overemphasis on planning in more and more detail. Some things are opaque at the point of making the plan. For example, some parts of a plan may require you do to things you don’t know how to do. That breaks down into (1) find out how, and (2) do it. But you don’t know what you’re going to find, and what acting on you find will look like. (2) is opaque at the planning stage, and may not even exist if the answer to (1) suggests a different way of going about the parent goal.
Also, things can go wrong during execution. No complicated car repair ever goes exactly as the Haynes manual says, and for all the convenience of satnavs, you sometimes have to notice that it’s sending you along a stupid route.
I recently had the goal of taking a piece of software I wrote in 100,000 lines of C++ and getting it to be callable from a web page, returning results to be embedded into the same web page, and running on a web server that it had never been compiled for before, starting from a position of knowing nothing about how to do dynamic web pages. It got done, but a plan would have looked like “1. Find a suitable technology for doing dynamic web pages. 2. Use it.”
You raise some good points about other things that can happen in planning, and your point about opacity in plans along with learning new skills is also something I hadn’t considered.
The general idea of “getting things done” doesn’t seem to vary, but there’s definitely much more room for variation than I’ve implied.
I think a large part of that is caused by my: 1) Inexperience with applying planning skills 2) Using them only on a very narrow range 3) Extrapolating from my personal experience.