Decision Routines When Stuck

Situation

I'm stuck. I face a hard problem and can't decide how to proceed further. I can think of ways how to proceed, but I like none of them.

I like the list below, but find the labels distracting. I've removed some replication from the labels, and I'm tempted to remove the labels entirely.... --

This list reminds me of HowToSolveIt.

1 : Analyze further
- A : Discuss it with someone
  - a : Post to a newsgroup or mailing list
  - b : Discuss it with a good friend or a colleague
  - c : Discuss it with your pet, a sock puppet, a teddy bear, a fern, CardboardProgrammer or other inanimate object in whom you trust. (Believe it or not, this often works as well as the above.)
- B : Gather further information
  - a : Set a time limit and explore one of the solutions further
  - b : Think of other ways to proceed. Generate wild ideas.
  - c : Examine the methods that others have used to solve similar problems. Read patterns, source code, papers, ...
2 : Change the scope of the problem
- A : Break the problem down
  - a : Find a small, solvable subset of the problem, and tackle that.
  - b : Find a solution to a more general problem that your problem is a subset of (as Polya [what, no WikiName?] suggests in HowToSolveIt).
  - c : Refactor existing code (or reorganize the elements of non-software situations) so that it is closer to what you need for a solution. The solution may become clear.
- B : Redefine the problem or the solution space
  - a : Find out whether the problem really needs to be solved. Maybe you can ignore it, maybe it will go away, or maybe the benefit doesn't justify the cost. Or turn the problem into a feature. ("Wouldn't it be better to have people monitoring this process, rather than leaving it running fully automatically and unattended?")
  - b : Instead of solving the problem, change the conditions that have led to the creation of the problem. (James T. Kirk's 'KobayashiMaru'' solution is an example.)
  - c : Use a different tool, programming language, operating system, network protocol, ...
3 : Do something else (DisplacementActivity)
- A : Go for a walk or have a shower (UngarMethod)
- B : Let it rest and sleep over it
- C : Juggle (Massively underrated - learn MillsMess)
- D : Write something meta about how to be productive
- Creativity breeds more creativity. Create something else, and enjoy doing that. Maybe you'll be in a different mood when you come back? (Or is this just an excuse for further procrastination?)
- http://www.writethinking.net/Articles/Guerilla_WriteFare/change_context/change_context.html suggests, among other things, working on a different part of the same problem.
4 : Pick a card at random from an ObliqueStrategies deck or a CreativeWhackPack and follow its advice (which is likely to match one of the previous options.)

Find a small, solvable subset of the problem, and tackle that. Often, once I have solved the subset, I have enough momentum to let me proceed to the hard part. -- BetsyHanesPerry

Much of the value in this comes not from the momentum, but from the skills you have newly acquired.

[I hope someone proofs this for me, because I'm stretching: "Refactor the problem" ... something about how the specific presentation of the problem can foreclose and/or preclude potential solutions whereas another presentation can suggest and/or enable them. -- BenTremblay ]

The numbering scheme for these points suggests that they came from somewhere else. Anyone remember where?

Here's a simple trick: with pencil and paper make a personal "mandala" (rectangular instead of round) representing your week (time vertical, day of week horizontal). Like a Mandala Diagram but for the practical purpose below: Then Partition off sections at a high level for personal and work activities based on when you need to do them each week (however you subdivide them- Admin, Study, Leisure, various Chores etc) then color each section as you feel (markers ok). An entertaining exercise that sticks in memory no matter how busy you are. Like a time table but at a high level. helps make habitual an overall routine so even if you can't enter detail tasks in a HandHeld or paper planner you have a mental MindTool (similar to MindMap but not as spaghetti-like) to know what to do next at each moment. One could also tuck into their paper planner or scan it in or use drawing tool to put on HandHeld if desired.

This guide to daily routine decisions at a macro level then makes time to concentrate on the tough decisions (and apply more detailed unsticking routines) on the micro level. Also helps build momentum for your LifeGoals. Other technique if you are really swamped: What 3 things do I most have to do next? (don't need a planner or PDA for that either). Allocating a reasonable time then leaving a stuck task once time is exceeded for a while and moving on to the next priority sometimes allows the stuck problem to "ferment". Subconscious continues to work on it in the background. Easier to solve on the next conscious pass or sometimes answer comes in a flash "eureka" moment.

Mandala Diagram

In Tibetan Buddhism, a mandala is an imaginary palace that is contemplated during meditation. Each object in the palace has significance, representing some aspect of wisdom or reminding the meditator of some guiding principle. Tradition dictates the shapes, sizes and colors of these objects. There are many different mandalas, each with different lessons to teach. Most mandalas contain a host of deities as well as inanimate objects.

(from http://www.graphics.cornell.edu/online/mandala/)

For those who are religiously inclined, pray. When all else fails, pray to God. It will not only be a great emotional release, but if you sit still you will soon find the answer come to you--maybe not that day, but soon enough. God delivers.

If you're stuck and you're beginning to become committed to the completely random, why not make a ritual out of it? When reliable methods of decision making aren't working, why not go for broke and try the IChing? Why not go farther still and make it fun by turning the IChing into a dartboard?

Back in the late 1980s we did this at a small Unix & PC software development shop in the southeastern US simply because we were out of reliable (or even rational) options. We'd tried introducing other tools and methods, but most of our CowOrkers were suspicious veterans of CultureOfFear? organizations, so this one was easy to sneak under the radar. Managers thought we were relieving stress when we were actually doing serious planning work, so to speak.

The IChing dartboard itself was ridiculously simple to create -- just take a reasonably large sheet of poster board (75x75cm is probably big enough), draw an 8x8 grid using big permanent markers, draw each hexagram in a grid square (hopefully distributed randomly instead of using 1-64 in order), and mount the finished poster board on something reasonably durable for repetitive dart abuse (really thick corkboard and gypsum board worked well).

Reading the IChing using the dartboard seemed to work best with blowgun darts that weren't all that accurate. We took a small piece of straight, non-corrugated electrical conduit and used it to launch blowgun darts that we made out of pieces of paper, thumbtacks (metal ones worked best, of course), and lots of tape, the kinds of things you'd find in your average office. Well-made darts tended to give consistent readings that were often suspect, but hastily made darts loaded with lots of chewing gum, tape, slightly charred paper, and even the occasional Gummi Bear or two were usually the best.

Applying the ritual was simplicity itself. When you're presented with a LargeUnmovableProblem? or someone's just decided to test out ManagementByCrisis using their newly minted ExtremeFearMethodology? ("Fear Rapidly. Fear on Schedule."), whip out your trusty IChing dartboard blowgun, aim in the general direction of the IChing dartboard, and let 'er rip with a reasonable yet nonexcessive blast of lung. If the dart lands close to another hexagram, read the hexagram it hit as the primary reading and the other hexagram or hexagrams near it as "changed line" readings. (Obviously this method of IChing has some drawbacks in terms of accuracy compared to the coin and yarrow oracles, but it does seem to work reasonably well in this context.)

When we used this technique for determining the eventual outcomes of some highly dubious projects coming our way it worked without failing. "Your endeavors will fail, but there will be no blame" was a classic involving an ill-fated attempt by middle management to force a reasonably large Sun-based X11R3 solution written in the late 1980s onto an IBM RT running X10 (mostly without regard to the action's merits). Other readings led us to change our methods slightly, avoiding both managerial scrutiny as well as long-running ventures into the unlikely to succeed.

Unfortunately for the organization that helped give birth to this technique, some readings later on were interpreted by software developers as an opportunity to ChangeYourOrganization, which caused some BlameStorming about who would be responsible for bailing everyone's collective chunks out of the fire.

Of course, the developers who decided to ChangeYourOrganization also kept the ritual, preserving it as a last-effort attempt to decide the undecidable. Many of them have chosen to work for SkunkWorks organizations since becoming attuned to the pathologies of CultureOfFear? organizations. Many of them still duck when they hear someone taking in a lung full of air.

Those of you who have read and understood Theodor Adorno's "The Stars Down to Earth" (ISBN 0415271002 ) can perform this ritual for your own amusement. The rest can use it as a backup to more reliable methods of decision making when rationality is completely out the window.

Any connection between this technique and FortuneCookieDecisions? is, of course, coincidental.

See NextList, ListYourWayOutOfStuckness