When I first started programming, I always fretted about finding the best way to do things. I didn’t want to waste any computation, declare extra variables, or even waste characters in the code. Anyone who has done any amount of real coding knows that this is all baloney—otherwise, we’d all be writing in assembly. (Not entirely true though).
I’ve found personally that finding the dumb solution almost always provides value, insofar as, I consciously try to think of it. (Brief aside: I just used the word “insofar.” Holy Cow!) One of the best reasons for a dumb solution is that a correct but dumb solution is infinitely better than a broke-ass clever solution.
During interviews, I always work out the dumb solution first. It’s always good to throw it out. You never know, sometimes its good enough. (This actually happened to me once! And actually, in areas like geometric algorithms, often the dumb solution kicks ass.) For me, I sacrifice the chance to look like a genius and instead show that I’m practical and can ship something if I need to. Also, it’s great for getting a handle on the problem. It shows you understand the problem correctly, and that you know how to plug things in and verify solutions.
It’s not just for interview questions though. I think it’s a great practical and methodical approach to problem solving. You understand something, in a semi-naive way. You study the problem, and start asking why it is inefficient. You gain intuition on where you can cut corners, where you may be doing redundant work, and whatnot.
One thing that sucks about my current research is that it deals with performance on a real-time system. This has been a huge source of frustration for me because I can no longer think of a dumb solution. The dumb solution is never good enough. And no iteration from the dumb solution seems to converge on the right solution.
Leave a comment