PDA

View Full Version : How Do You Solve Problems



manofsteel972
12-01-2004, 10:27 AM
I noticed recently a lot of people posting that just don't understand how to solve problems. I am not really that great at it so I did a search on google and came up with a few sites that gave some pointers and good tips so I added them to my signature. I just thought it would be interesting if anyone had any other tips that they use when they are solving problems that might help the rest of us?

VirtualAce
12-01-2004, 10:29 AM
I solve problems through research and some through trial and error.

Govtcheez
12-01-2004, 10:32 AM
Prayer.

Sang-drax
12-01-2004, 10:49 AM
Do not try to understand the problem.
That sounds a bit strange. :)

GanglyLamb
12-01-2004, 10:49 AM
When i need to solve a problem and i dont see the answer within 15 minutes of thinking about it and another 10 to 15 minutes trying some things out, i just go for a nice walk around the block ( if im home that block becomes the forrest ).

Usually the answer to it will just pop into my brain when going for that walk .. if not keep on walking ;).

manofsteel972
12-01-2004, 11:18 AM
I am like that too GanglyLamb. I stay up late trying to code stuff and then when I get stuck I just go and take a rest close my eyes. Sometimes it works. I research as much as I can as well. I read constantly. And when I am not reading I am trying to code something. I am teaching myself so it is slow going. Yeah Sang-drax it is a bit strange but it made some sense at least to me. I am sure there a many strategies for how to solve a problem. Sometimes you just aren't sure how to aproach it. It still boils down to breaking up a large problem into many smaller sub problems and solving each of those. My problem is that I have too many choices on how to solve it. I spend way too much time trying to find the best solution instead of just solving it.

Hunter2
12-01-2004, 12:12 PM
Solve a problem?..

Start typing and hope the random characters will form a usable program. If inspiration hits you during this 'seeking' phase, implement ideas on blind faith that they will work. Begin typing random characters again and hope that compiler errors will go away. Repeat, for linker errors. Then, pray and hope to God and Intel that your CPU doesn't melt. On failure, buy a new CPU and repeat process until program runs without CPU meltdown. Now, begin the debugging process: Type random characters and repeatedly compile, link, execute until runtime errors are resolved. Go back to previous steps as required, until desired result is achieved.

Not the most cost-effective method, but it works if you have enough time and money to blow :D

manofsteel972
12-01-2004, 12:20 PM
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

major_small
12-01-2004, 12:29 PM
here's how I do it:

1- Identify the problem
2- develop an algorithm
3- test the algorithm
4- evaluate the test results
5- find another n00b to help

</sarcasm>

mostly I just sit on it and think for a while, but if I start getting fustrated, I drop it and come back later. or I look up the answer somewhere. but for bigger things or things that I know will get compilcated, I try to think it out first and put together an algorithm that should work in theory.

Brian
12-01-2004, 01:28 PM
I drill into my skull and extract the knowledge using a vacuum cleaner

axon
12-01-2004, 01:50 PM
this is actually kind-of related: today in my software engineering class we talked about design issues...and about the whole design process and such. I'm posting some interesting links below. Have you guys ever heard of Deming and his "14 points" ? good stuff.

Deming's 14 Points
(Excerpted from Chapter Two of OUT OF THE CRISIS by W. Edwards Deming )

1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.

2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.

3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.

5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.

6. Institute training on the job.

7. Institute leadership The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul as well as supervision of production workers.

8. Drive out fear, so that everyone may work effectively for the company

9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.

10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.

11a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.

b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.

12a. Remove barriers that rob the hourly worker of his right to joy of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.

b. Remove barriers that rob people in management and in engineering of their right to joy of workmanship. This means abolishment of the annual merit rating and of management by objective

13. Institute a vigorous program of education and self-improvement.

14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.


links:
http://betterproductdesign.net/maturity.htm

there is a chart there describing the Maturity levels and process areas of the Software CMM...I wish I knew this detailed chart at my first interview. One of the questions i was asked was "why should I higher you vs a level 5 programmer from India?" - seriously, the question was a bit more refined then that, but thats the jist of it. Anyways, a level 5 programmer from india "follows" all the criteria on that chart.

ober
12-01-2004, 01:53 PM
I tend to be a visual thinker. If I can't figure out why something isn't working, I flowchart how it should work. I then compare that to my current code and that works out most of the bugs. For stubborn bugs, I check all my variables and set counters and such to make sure that things are where they should be.

Failing that, I post on boards like this.

I can often visualize the code too in more of a 3d view. I can move through it in my head and put myself in various positions in a program. That tends to help.

quzah
12-01-2004, 01:58 PM
I just post it on the C board, because I know if I wait long enough, some one will come along and DO THE WHOLE THING FOR ME. :mad: :mad: :mad:

Quzah.

axon
12-01-2004, 01:58 PM
>>I can often visualize the code too in more of a 3d view. I can move through it in my head and put myself in various positions in a program. That tends to help.<<

One of my weaknesses is that I can't think well in abstraction...I have to write things down :(

-KEN-
12-01-2004, 02:19 PM
When i need to solve a problem and i dont see the answer within 15 minutes of thinking about it and another 10 to 15 minutes trying some things out, i just go for a nice walk around the block ( if im home that block becomes the forrest ).

Usually the answer to it will just pop into my brain when going for that walk .. if not keep on walking ;).

When I want to lose weight I try to cure cancer.

Darkness
12-01-2004, 02:57 PM
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.

Driver
12-02-2004, 07:13 AM
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:



with Difficulty {
problem.Solve(x);
}


where x is the problem you want to solve. It works wonders!

vasanth
12-02-2004, 07:58 AM
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....

Shadow
12-03-2004, 01:04 AM
I cheat as much as possible everywhere I can.

Philandrew
12-03-2004, 02:41 AM
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 :)

Prelude
12-04-2004, 07:38 AM
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

nickname_changed
12-04-2004, 10:25 AM
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 ;)