Depends on the scope and nature of the problem.

Generally I'll think through a problem during the slow parts of the day (bathroom, shower, driving, boring tv, waiting for food) until I'm reasonably comfortable with the solution. Sometimes it requires jotting things down and notes, but that's rare. Then I'll implement things.

The key there is being sure to break problems down into ~3 hour chunks of work at a time.

I usually delve into programming first.Code a few hours like mad to implement what I want.Then after getting the result and messing everything up I start cleaning things up :)

I often make notes and sketches first - it's a habit I developed during my time as a level-designer. It works for programming too so I've kept it. Then, depending on the task at hand, I'll make a prototype, or if I'm familiar with the subject, I'll start writing production code right away.

I spend time thinking over problems and deriving possible solutions in my head then, once I think I've found one that's satisfactory, I prototype the solution in a project all of its own. The idea is that not only do I begin coding with a near-ideal solution in mind but I'm forced, due to the prototyping, to keep things modular and loosely coupled.

If the prototype fails initially, I either refactor it to make it work or go back to thinking up new solutions with the added knowledge of what didn't work from the failed prototype.

I usually try to split the task into several smaller ones, this usually results in modulate code that is far easier to test than a full blown class that does almost everything and due to the nature of modules it also makes for shorter compile times.

Before I start writing any code I try to fully understand what I am going to program(the algorithms, some potential pit falls...)
after this I examine the algorithms to get an idea about which containers to use ... and finally I try to get rid of redudant computations and if possible try to rewrite algorithms to make them suitable for parallel processing, you know the many cores systems we will have in a few years.


Some of these steps can t be thought of in advance, so you will have to refactor your code once its working.
The final result is usually pretty reuseable code and saves time on the long run.

Just a note: Never start to work on multiple modules of a task in parallel, finish one first, its far easier to debug one module, than to find bugs that are caused due to interaction of incomplete modules.
Just write some simple helper modules if you really need them to get the previous task done at all.

Quote:Original post by Telastyn
Generally I'll think through a problem during the slow parts of the day (bathroom, shower, driving, boring tv, waiting for food) until I'm reasonably comfortable with the solution. Sometimes it requires jotting things down and notes, but that's rare. Then I'll implement things.

I thought I was the only person who thought about programming in the shower! [smile]