Getting unstuck when you hit the wall
It is not uncommon in problem solving to get stuck, and sometimes you get stuck many times. Problem solving is not a linear process (not usually). You go down a path using knowledge, thinking about what needs to be done, how it can/should be done, evaluate it (or someone else evaluates it for you) and you have to retreat or fix one or more issues before you can proceed. You can iterate and go back forth from almost any point in the journey to another point. The more challenging and more ‘unknowns’, the more back and forth. Here are some techniques for dealing with problems you are stumped by.
In some cases, there is no going forward and it is time to retreat or take a step back (you need to learn when to do this). You might be working on the wrong problem. You might have missed something, did not pick up appropriate assumptions or requirements. The retreating will vary - in some cases, you have to retreat a little and in some, you might have to start again from scratch. Moving forward, you might have a bunch of things ‘to do’ before you actually move forward. You might also find that a bunch of new tasks or future problems to solve were created. This is problem solving.
Things to consider when problem solving
Re-read the requirements, specifications, and understand what you are supposed to be solving or doing. Have someone else read the same material. Compare notes. Often (surprisingly often), you might find that you are trying to do the wrong thing or solve the wrong problem or do it with the wrong expectations.
Consciously stand back and reflect on what the constraints are. It is possible that some constraints can be relaxed.
Think about what assumptions you are implicitly and explicitly using - are you part of the problem?
Stand back and identify the Zen aspect of the situations - all that makes it what it is and no more. Can you take something away and it is still what it needs to be? This simplification process can help isolate issues and what must be addressed.
If you have a ‘continuum’ or a large problem, do a binary-search on the space - divide the problem in two if you can - is it in the left or right. Divide again. This can work for concepts as well as things like debugging code. Sometimes the problem is just too big to comprehend and if you can break it down into encapsulated and isolated ‘modular’ bits, it is easier to think about and solve.
If you are trying to change or do a bunch of stuff at the same time - slow down. Do one change at a time, see the effect. Understand the cause/effect.
Try to do a sketch of what you are dealing with - can be a process model, or a conceptual representation of the components - try at different levels of granularity - see if any patterns exist.
Just talk it through with someone - take it from the top and try to explain the problem or what is happening to someone. Often this can unlock an idea.
If you are stumped by a specific aspect, write down everything you know about it.
If you can, do what is called anthropomorphism projection - try to be what you are designing or debugging and use your imagination to be the electrons, or the user. Think it through from turning on the power, starting it up. Become one with the problem. Sometimes this helps (really).
Take a break, a nice walk - move away from the problem and think about something else. This can also (we do not know how) help you ‘see’ the solution.
Questions to ask yourself
What is it similar to? In structure, form, construction, process, method, purpose? What happens if you think about the similar object/problem?
What have you seen or done that is similar? Talk it through - what did you do, what did you think of, why did you do something, what happened when you did it?
Sometimes look for repeating patterns or themes - what is the same. Sometimes look for how two bits are the same with respect to their differences. For example, you are looking at something involving students and a solution is evading you because people keep saying that ‘all students are different’. Usually there will be some things the same (that is the easy bit). Next, look at how they are different and the differences. Any patterns there?