So I have been thinking about “stuckness”. You know, where you just feel like you are bashing your head against a wall trying to come up with a solution. I’ve been thinking about it in terms of debugging, but it could be anything really. It all stemmed from a troubled team I was asked to visit a few years ago. They had great technical knowledge but some of them seemed to find the whole “meta” thing tricky. They didn’t think about their problem solving and whether they could change tack, so it took them a long time to come up with a solution. Like, a REALLY long time. Here are six thinking modes (if we include mode 0) that I have been playing around with for a while that might help:
When you “just know” what to do. Maybe you can’t even remember how you know. It’s just so easy you don’t even need to think about it. In fact, if you do try and think about how to do it, it becomes harder. Like if you think too hard about breathing or riding a bicycle and then it feels like you are suffocating or you forget how to pedal. Beware though, because this tacit knowledge is hard to unpack, and hard to change but still open to error. Anyone who has ever tried to change their running gait can confirm how hard it is to tweak these.
Step-by-step problem solving – like long division in maths or a bubblesort. Logical. I want to say Algorithmic. This kind of problem-solving is helped by self-explanation (talking to oneself) or writing down our workings along the way. Keeping track of which step you are on.
Where we decompose the problem top-down. Like back in the days when we created Jackson Structured Diagrams before writing COBOL code. Like nowadays when we split a complex problem into smaller solvable parts. Formal (or informal) representations of structure help us here. They can stop us from getting stuck. And enough has been written about splitting user stories elsewhere that I am not going to repeat it all here.
This is where we need other tools in our kit because the problem just has too many sides to it. We can’t step through. Breaking it down isn’t enough because then we lose the inter-relations between some parts and others. We have to cheat these to beat them. Use our cognitive skills like chunking things up, naming them so their meaning screams out at us, recognizing common structures and patterns. Filtering.
OK, on to the tricksier ones. These are the kind of problems that are so big and wicked that our mind has to jump about the problem space a bit. Seemingly at will. We will be working on one bit of the problem and then suddenly something more related to another bit will pop up. We can help with lists, informal representations and maps. What I think of as “coverage” type tools.
This is where we actually need to completely step away from the problem space to come up with a novel solution (or sometimes just any blooming solution at all). The part of the creative process known as “incubation”. The reason we can sit at a screen all evening and not make any progress, then go home for a sleep and have the answer there, almost waiting for us, when we awake. Things that help with incubation include a change of scenery; a repetitive physical activity (like walking or juggling or – in my case – going for a run); listening to music or going somewhere totally quiet; laughing or play.
I’m hoping this provides a kind of “cheat sheet” for getting unstuck. I’d love to hear your thoughts.