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.Originally Posted by Bubba
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.
See you in 13
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:
where x is the problem you want to solve. It works wonders!Code:with Difficulty { problem.Solve(x); }
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....
I cheat as much as possible everywhere I can.
The world is waiting. I must leave you now.
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
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.
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
My best code is written with the delete key.
Wow, I didn't know the linux kernel developers frequented this boardMy 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
