How Do You Solve Problems

Show 80 post(s) from this thread on one page
Page 2 of 2 First 12
• 12-01-2004
Darkness
Quote:

Originally Posted by Bubba
I solve problems through research and some through trial and error.

I agree with this about 1000%. I believe understanding concepts at a very fundamental level via doing research, then trial and error, is the way to solving problems.

Of course, this assumes you've already clearly defined the problem you are trying to solve, which can be a difficult task in and of itself.
• 12-02-2004
Driver
It all depends on the kind of problem.

If it's an algorthmic issue, I'll draw diagrams and write the code from the diagrams. Very rarely do I ask someone for assistance because by the time I've communicated the exact requirement I could have worked it out anyway.

If it's a thing such as confusion on how to use a specific command (e.g. the command doesn't appear to do what the documentation says it should) and I can't get an answer by reading help, Googling, or forum-searching, then I'll ask a question.

Generally speaking, I always try to get an answer myself before involving others.

Other problems are simply solved with difficulty:

Code:

```with Difficulty {   problem.Solve(x); }```
where x is the problem you want to solve. It works wonders!
• 12-02-2004
vasanth
I usually imagine problems to be blocks of diagrams composed of various smaller blocks.. But when I see the problem for the first time.. I only see the bigger blocks.. I decompose them, only when I reach that particular part....
• 12-03-2004
I cheat as much as possible everywhere I can.
• 12-03-2004
Philandrew
I do a couple of things.

If its possible I build a shell of a program, and then slowly upgrade it until it does everything I want it to. (for example....take in one input at the first stage and act on it, second stage take in next input, third stage its fully ready).

If it isn't really possible (or worth it) to do that I often just sit down, write on paper what I want to do and some ideas...and then start typing. If I come up with a problem I can't solve, I get annoyed by it, if I still haven't found it in half an hour I probably won't find it...so I talk to some friends on MSN, and just relax....then the answer comes to me :)
• 12-04-2004
Prelude
The first thing I do when solving a problem is figure out what the real problem is. Most of the time, what you're asked to solve isn't what you end up solving. So you turn your wheels without going anywhere if you try to solve the first problem that arrives at your door. Next, I try to simplify as much as possible so that I don't do any unnecessary work. It's all about laziness, really. :) If I can minimize my coding time by molding the problem to something I know I can get right then I'll also minimize my debugging time.

The next step is to prototype the hell out of the problem. With a trashy prototype I gain valuable experience in the implementation of the problem without the burden of being forced to throw away nice code when I reach a stumbling block. I've found that several big prototypes and a lot of small prototypes followed by a final version tends to end up better and gets written faster than trying to put Band-Aids on good code using bad assumptions.

So I guess my three biggest rules for design are
• Understand
• Simplify
• Prototype
• 12-04-2004
nickname_changed
Quote:

Originally Posted by manofsteel972
My pet monkey is hard at work on my other system. I decided to do away with the compiler and just create the binary directly. He is busy flipping a coin for a 1 or 0. He almost has a working os kernel :D

Wow, I didn't know the linux kernel developers frequented this board ;)
Show 80 post(s) from this thread on one page
Page 2 of 2 First 12