Michael Heilemann over at Binary Bonsai asks how programmers code around a tricky problems. Heilemann describes his own technique — to write out a problem step-by-step, in English — and asks others what their process is.
Speaking for myself, I like to analyse the code of others first. I like to tear that code apart and play around with it until I understand completely what it’s doing. Then I can write my own. I also create volumes of flowcharts (I’m old school) and reams of pseudo-code when I’m developing a program.
Now I’m curious. What do other programmers do when faced with a coding problem that’s difficult or outside their comfort zone?
So, like Heilemann, I’m asking, “what’s your secret?”
Last Revision: November 7th, 2009 at 09:32
Short URL: http://wp.me/phEOu-FU (Tweet This!)
Over the years I’ve used many methods to solving programming problems and have found the following to have stuck with me.
1) Talk to the bear. Seriously. Explain the problem out loud. After talking for less than 30 seconds I’ve often found myself going “oh, never mind I’ve figured it out”. Don’t know why saying it out loud helps jog my brain, but it does. If there aren’t any other programmers around to listen to you, get a stuffed animal. Anything. But just say it out loud.
2) Take a break. Force your brain to focus on something else for a while. Can’t see the wood for the trees? Go watch TV and then come back to it.
3) See if it looks different on paper. After staring at code in my editor of choice, sometimes printing it out on paper seems to make my brain look at code differently.
Kevin you’re right on the nail with all three of your methods. I do exactly the same at one time or another.
I also find that basic flowcharting on a whiteboard supplements the “talking to the bear” technique - talk it through, out loud, while diagramming the program’s flow.
If I get really stuck I’ll put the computer to sleep and go for a walk, or a swim, or to the gym… anything to take my mind off the problem. I often find that a solution will just occur to me when I do that.
Another technique that I return to again and again is to pepper my code with print statements, dumping variables and comments on to the screen so that I can see what’s happening with the program. I guess this is the same principle that computer engineers use when they sit in front of an oscilloscope - a sort of digital voyeurism.