I’m a computer science major, and I do research in AI/Machine learning. I think the biggest thing I learned from these fields is the notion of a subproblem*. Oh sure, I understood it in theory before, but I realized when writing code for certain things that subproblems make everything easier, even for us meatbags.
Now math and physics (and even other disciplines) are a lot easier, because my question isn’t “how do I set this problem up and what do I do?” So much as “what do I need, and what smaller problems give me that information?” Which I suppose is more or less asking the same thing, but I find it easier to reason about. It’s almost the notion of a checklist, where you make a list of what you need to complete, and then it’s structured so you can know you didn’t miss anything and not flail around doing random unrelated things but rather only do what’s necessary and know your milestones.
So, as the title says, what are the most valuable problem solving techniques you acquired?
Though in comp sci, sometimes “subproblems” gets lumped in with “problems we know the answer to” and things get silly. There’s a joke that goes that a computer scientist is asked to move a vase from one room to the same stand as a lamp in another. Since he now knows the answer to that problem, when he’s later asked to move a vase from the same room as the lamp to that same stand he figures out how to move it to the other room, and then uses the solution he already knows from the first time to get it to the lamp stand.
Years ago I took a course offered by Kepner and Tregoe called Problem Solving and Decision Making. It was a very methodical approach to general problem solving. One thing I still use is their formal definition of a problem. It’s different than a mathematical-type problem, which is something like: Given A and B solve for X. Their definition of a problem is something that deviates from expectations. This is very useful in tackling general, real world problems because often the key to finding the solution is having a clear definition of the problem.
SMART goals. State the problem as a goal to be accomplished. The goal needs to be:
(S)pecific. What do I want to accomplish?
(M)easurable, or manageable. Must be concrete criteria used to judge success.
(A)chievable or attainable. Must be important to you in order to expend the effort
®ealistic. You have to be willing to work to achieve the goal.
(T)ime-based. Must have a deadline.
Example: Joe is a high school student. He sets a goal of: I want to be rich.
He first has to define rich. For the sake of argument, we’ll assume he settles on a definition of rich as having a net worth of one million dollars. He also decides that he wants to hit this early in life so he can enjoy it. He therefore redefines his goal into a SMART goal: I want to have a net worth of one million dollars by my 30th birthday.
Now all the bases are covered. The goal is specific, his net worth is measurable, it’s a realistic goal that can be attained in the next 12 years (assuming Joe is now 18), and it has a deadline of his 30th birthday.
He can then break that goal down into smaller SMART goals that he needs to accomplish in order to achieve the long-term goal. When he has a list of short-term goals (90 days or less), then he can start accomplishing them, just like eating an apple one bite at a time instead of shoving the whole thing in your mouth.
Basically, break a big problem down into a series of smaller issues and start chipping away. When, in meetings on the problem, people start rehashing the past or just talking to talk, let this be your mantra: “that’s great, but what specifically are we going to do?” Assign tasks and due dates and then follow up.
This is extermely important if you are trying to fix something. You have to have a thorough, detailed understanding of the expected behavior.
For solving unknown problems, the first step is to see if an existing wheel will do instead of inventing a new one. If it doesn’t, see if a modification to an existing wheel will do the job. After that, move to abstraction, is there a similar problem in a different field that can be fitted to the issue. Most problems I have to resolve come to me after the conventioal, intuitive approaches have failed. In that case, a wild, free ranging imagination is invaluable. Dismiss all conventional wisdom and see what you can come up with.
Here in biology there aren’t many formal problem solving techniques. Everything is such a completely tangled mess. So, on the reductionist side of things, we pin down variation as much as possible. Then, include as many controls as is feasible, to rule out the possibility of artifacts. Finally, we need a good working knowledge of statistics to extract anything useful from the mess we call results.
First confirm that you know what the problem is. Most problems are composed of a group of smaller, solvable problems. See if you can identify what small problems can be solved, and solve them, then you can focus on the unsolved parts. In other words, simplify the equation as far as possible down to the real question that needs an answer. Use the same approach that you would use to solve a classic ‘story problem’ in math.
Most people try to confront the problem in a holistic way where the answer must solve the whole issue. The answer will be found while you are confronting all the little parts that make up the larger whole.
Donnie Darko Rumsfeld was trying to say something similar, it just didn’t come out right.
I chunk it down, as has been said by others. I break the problem in to its smallest simple things, then I just do the first small thing that I have to do.
The importance of this cannot be overstated. Equally important is defining what you are trying to accomplish. I do tech support, and this is more than half of my job. It’s extremely common for someone to come to me saying ‘I need XYZ’, only for it to turn out on questioning that what they really need is ABC. In fact the more certain they are that they need XYZ, the more likely it is that they’re wrong.
Here’s how I like to approach people’s computer problems:
What are you trying to accomplish? (Trying to log in to this website)
What is actually happening? (The computer brings up a 404 error when I try to navigate to the page)
What is supposed to happen? (It should display a web page with a place to enter a user name and password)
Especially with computers, you have to define the problem thoroughly before you can fix it. Often once the problem is well defined, the answer becomes obvious, even trivial. Next time you have to work with technical support, start by giving them the above information - it’ll cut the time it takes to resolve your problem to half or less.
Learn how to prioritize. You should treat problems like patients being lined up for triage. What is the most immediate, or important issue? Treat that first. Then move up the line until everything has been resolved. On the converse side of it, learn to accept when a portion of a problem is beyond control or addressing at the moment and file it aside for later. This is especially useful in situations where the “problem” is really composed of a myriad of small issues.
Semi-Saucy Answer: Sleep on it. After working on a problem in the usual, reason-based ways, I find I get remarkable insights from letting the old unconscious mull it over for a while.
One way of doing this is to plot issues into a 2 x 2 grid. The X axis is “ease of completion” going from “hard” to “easy” and the Y is “urgency” going from “not urgent” to “urgent”. The top-right quadrant (urgent/easy) are the things you should devote about 30-35% of your time to, the top-left another 35-40% (urgent/hard). The bottom-right (not urgent/easy) 20% and the bottom-left 10% (not urgent/hard). That final 10% is important otherwise the stuff in it will never ever get done.
My best technique is to just solve it as soon as possible. A lot of problems that come up in daily life, like a bill that needs to be paid, a paper that needs writing or a cavity that needs filling can be solved right away, but a lot of people spend quite a bit of time ruminating over the problem first. I cut out the ruminating and just move straight to the solution.
I can spend a week freaking out that paying for car repairs will empty my savings account, and then pay it, or I can just pay it today and save a week of stress and worry. The result is the same in the end-fixed car and no money, but I’ve spent that worry week on other things instead.
Dimensional analysis. Do you multiply or divide when using a conversion factor?
1 inch = 2.54 cm.
1 inch/2,54 cm x 50 cm = 19.7 inches. You have inches in the numerator and cm in both the numerator and denominator.
I have used almost a trivial example to illustrate a powerful tool. Set up your equation using all the units. If all but the units you want cancel, likely your answer it right.
I hate and despise SI because they have replaced real units with some 19’th century physicist’s name.
Sometimes things make more sense with the shortenings, a Pascal (to use your example) is 1 kg/(m*s[sup]2[/sup]) which, while you could divine a meaning without too much trouble, I don’t think it’s really intuitive. Even though I know a Joule-second is also a Newton-meter-second (angular momentum), I find it hard to divine precisely what a meter-second is, much less what a kilogram per that is, much less what that means per second. Yeah, I probably could figure it out in not too much time if I had to, but I think it makes much more sense as Newton per square meter, meaning for each square meter, there’s enough force to accelerate a one kilogram object at 1 meter per second per second.
I think both make sense, but I think using the dead physicist’s name as a shortening generally makes things more, not less, intuitive. In this case, allowing the Newton to be around is a simpler mechanism of grasping what, physically, is happening.
My approach is pretty simple. At first, I fully concentrate on the problem weighing the possibilities of potential solutions. Failing to identify a viable solution, I move on to something else unrelated to the problem. Periodically, my mind momentarily returns to the problem as if to say, “Why not try X. Would that solution work?” More often than not, I usually have a “House” revelation and come up with something that works.
Breaking problems down usually works well. Sometimes you need a top-down approach. My current workplace is full of processes and procedures. Not much gets accomplished ultimately, because the ball has to go through too many wickets, and whenever a project makes progress someone changes the croquet field to an ice hockey rink. :rolleyes: Somebody need to know what the goal is, andd make sure everything else serves that goal. But that’s another thread. Anyway, keep your eyes on the prize.
When I was in a personal crisis, I had to divide my life into 2 categories: “Things that HAVE to be done RIGHT NOW!”, and “Bullshit”. It’s amazing what you can cram into the second category. It’s extreme prioritization.
One possible way to prioritize under more normal circumstances is to ask “Will this matter in a year? In two? In five? In ten?”.
A genius approach to problem solving is turning your problem into your solution. You need to really understand what’s going on, but sometimes you can take aspects of the thing that’s blocking your progress and use it to make progress in a new direction. I knew a scientist who realized he could get a publication out of the work he did trying to fix a problem with his experimental rig. He got several papers out of his “problem”, which turned out to be interesting to study on its own. Sweet! The most famous concrete example of this I can think of is the (probably apocryphal) story of when Flemming saw that some mold had ruined his staph culture. He (supposedly) was about to wash out his glassware when he noticed that this mold wasn’t just growing on the culture, it was killing the staph bacteria in the culture. Thus was pennicillin discovered, so the story goes.
I’m known as a good troubleshooter. I few things I apply regularly:
Postpone diagnoses as late as possible. Focus on collecting data first, then work out what could cause all the symptoms. Early attempts at diagnosis often cause one to ignore data that rules out that diagnosis.
Second hand data is dubious, and third hand data is worthless. People unconsciously distort and filter the data.
Try to test the diagnosis before fixing it: “If I’m right, then I would expect to see X.” then look for X.
Sherlock Holmes’ violin: When you start spinning your wheels, go to lunch, go for a walk, work on something else, surf the Dope. Let your unconscious mind work the problem for a while…not like you were making progress anyway.
If something was working and then stops, probably only one thing is broken unless it was a cascade failure. On a new something that has never worked, don’t rule out multiple problems, and it may not work until you fix them all. In this case it may seem that fixing a problem had no effect. Try to figure out a way to test parts individually, so you can rule them out as a cause.