How to learn to break a problem down into manageable pieces and analyze a challenge logically and think under pressures?

November 20, 2006 3:34 PM

How to learn to break a problem down into manageable pieces and analyze a challenge logically and think under pressures?

What really works for you, beside taking deep breaths and hoping that you don't miss something you should not miss and making assumptions you should not be making?\


This is a skill important for many jobs, including management consultant interviewees.

Any recommendation for a great book , articles, etc?


Thank you very much.

posted by cluelessguru to education (12 comments total)

You might take a look at some books by Edward de Bono, whose emphasis is on the creative solution to problems. He suggests a variety of specific techniques.
posted by LeisureGuy at 3:37 PM on November 20, 2006

Talk it through. Play the part of the algorithm/solution/actor: "OK, I'm the parser, and my input string is...., and so I read the first token and..., so then I have to do sub-problem . So I'm sub-problem A, and I have a ...."
posted by orthogonality at 3:59 PM on November 20, 2006

This is something that happens all the time - so much so that people write entire books about problem solving. I'd suggest one, except that I do this level of work naturally, so instead I'll try to give you a quick sum of how I do it, at least when approaching software problems.

First, make a list of assumptions - things you can count on always.
Second, make a list of givens - things that you can count on to be true or within a reasonable set of givens. (for example, there will be between 0 and 20 customers in the shop or the input file will end in .txt)
Third, make a list of goals to be met.
Fourth, start listing out resources that you have access to.
Fifth, make a list of constraints - things that you can't exceed
Sixth, start trying to map out paths to get from your givens to your goals using the resources, obeying the constraints.

It's OK to write things like "to meet this goal I need a magic machine that can do <blah>" because once you have a list of magic machines, you can figure out what it takes to make those magic machines. You can always build a magic machine with more magic machines, but eventually, you want all your magic machines laid out in terms of real things. For any given machine, you should be able to assign a cost estimate in terms of resources (money, time, people, hardware, power, etc).

When I get into the estimation phase, I also add in what I call "complications". These are things that are partially or totally unknown to me, but I have a sense that they might present an issue. I keep a tally of complications which is an indication of risk. Complications also increase how much SWAG I put into time estimates.

Depending on the nature and scope of the problem, I can usually crank out a solution pretty quickly. For me, there's no pressure because this process is so natural to me. I can and frequently do a lot of it in my head. Since my role is primarily architect, it's not uncommon for a colleague to pose a design question, I'll ask a few pointed questions, think about it for a few minutes and then fill a white board with class diagrams, modes of operation, block diagrams, etc. Most of the actual time is spent covering the design details with my colleagues and trying to clear on the communication and overarching goals. If it makes sense, I try to design for at least next year and not for today. In other words, if I can find away to solve both todays problem and anticipate solutions for next year, it ends up being a huge win.
posted by plinth at 4:02 PM on November 20, 2006 [6 favorites]

You'll prolly get a bunch of votes for Getting Things Done, by David Allen ... excellent stuff there ... run, don't walk.

I've been implementing GTD to varying degrees of success for over 3 years.

The best meta-advice I can offer is to allow yourself to follow the simplest process that works for you and resist the urge to tweak your system. The only way you're going to be able to utilize these tools under pressure is repetition.
posted by likeSoy at 4:04 PM on November 20, 2006

This is a skill, and like many skills the only way to master it is to practice.

So though this sounds like a strange suggestion, I mean it seriously: play real time builder strategy games (e.g. Age of Empires).
posted by Steven C. Den Beste at 4:27 PM on November 20, 2006

It's not easily learned, this process. Your description is pretty much the definition of the art of engineering. AFAICT, it takes a good amount of practice and plenty of mistakes and a lot of natural ability to take hard problems and restate them as easy problems.

orthogonality's idea is a good one: Talk to someone about a problem. It doesn't even have to be a person. The need to organize your thoughts differently in order to present them well in speech tends to force us to see them differently enough to be able to solve them. You often won't even finish your description.

"Why is that guy explaining two-phase commit to a giant cardboard Wooikee?"
posted by cmiller at 4:30 PM on November 20, 2006

You guys are awesome with your awesome advice ! :)

Thank you very very much.

I used to read some books full of puzzles and pretty soon my inability to solve many of them took the fun out of reading that kind of books.

Ever since then I have been looking for an interesting angle to develop this essential skill and I really really like the computer game angle (i.e. playing real time builder strategy games by Steven C. Den Beste ).

Does anybody have reservations about this angle?

And if you also think the computer game angle is great advice, please suggest more computer games.

Thank you very very much once again.
posted by cluelessguru at 5:05 PM on November 20, 2006

cluelessguru writes "Ever since then I have been looking for an interesting angle to develop this essential skill and I really really like the computer game angle (i.e. playing real time builder strategy games by Steven C. Den Beste ).

"Does anybody have reservations about this angle?"

Only this: if I play a game intensely, I tend to see the world through the lens of the game. Years ago, I played SimCity a lot for a while, and found I was not only noticing architecture/city planning layout, but was seeing the world partitioned in SimCity city blocks. lately I've been playing DefCon and find I'm thinking in terms of how I maneuver six bombers to drop nukes simultaneously on the same location to nuke a nuke silo.

Be careful the game doesn't become your paradigm for everything. ;)
posted by orthogonality at 7:50 PM on November 20, 2006

That's why there should be several different ones, rather than only one.

The Sim games are also good for this, but not as good because they don't tend to incorporate perverse adversity. Bad things occasionally happen, but they're not the result of competitors who are deliberately trying to louse you up, which is a factor in real life situations such as the OP describes.

Another possibility is Galactic Civilizations, which is famous for the very high quality of its AI opponents.

And you could do much worse than to choose Civilization IV.

However, these are not games you will pick up and master in an afternoon. They're intended for people who enjoy doing exactly what it is you're trying to learn to do, and they're intended to give such people a challenge. They can usually be played at an "easy" setting, but they're still conceptually very complex.

One of the best aspects of all the good ones is that they teach you that you have to make compromises, that often there is no perfect solution, and that no single solution applies to every situation.
posted by Steven C. Den Beste at 8:05 PM on November 20, 2006

There are some very good books on the topic of efficient problem solving, some geared specifically toward mathematical problem solving, and some toward other types of problems:

- "How to solve it: a new aspect of mathematical method" by George Polya
- "How to Solve Mathematical Problems" by Wayne Wickelgren
- "How to prove it" by Daniel Vellemann
- Perkins' book "Eureka Effect"
- Some parts of "Mind Hacks" by Tom Stafford and Matt Webb
posted by lunchbox at 8:57 PM on November 20, 2006

Take a moment to understand both what the actual problem is, and the environment in which it exists. I know this may sound obvious, but I often feel like a large part of my job is walking people through finding the correct problem to solve. Once the problem is well defined, it is much easer to see where you need to go to start solving it.
posted by nalyd at 9:20 PM on November 20, 2006

This is ever-so-slightly OT, but I remember a computer game for the Apple II series that would present you with a shape on the screen, say a square, with certain holes and stripes on it. Your job was to position a number of simple machines that could rotate, drill, or paint stripes in such a configuration as to produce this result.

Damned if I can remember the name though...
posted by Wild_Eep at 7:37 AM on November 21, 2006