When I was a kid I had a few interests in art, particularly pencil drawing, where you typically start with a light pencil – easy to erase and manipulate – to emphasize your basic shapes and outlines, and then continue to fill in further detail using darker pencils.

I recently discovered that I suck at problem solving. Quite ironic, since I have so many years of coding projects in my history. Most problems I’ve come across have been worked out in my head. I never considered this as a skill that needs discipline.

I’ve been really tackling this weakness for the past week in the event that I want to pass a coding exam. One interesting thing I’ve observed is my newfound appreciation for psuedocode. I never considered psuedocode as a fundamental step to solving problems before – just figured it was a way to describe logic in a basic, freeform language.

Solving relatively difficult problems with a semblance of technique shed some light on the value of it though. It’s not just about describing what you’re going to do; it’s about the ability to put logic on paper without caring about semantics. I don’t need to describe the tediousness of swapping two variables using a temporary; I can just write “swap them.” I don’t need to specify what method I’m going to use to read an array; I can just write “iterate over array.” I don’t need to think about the many caveats C++ has. The less semantics the better, and it can be easily revised and further detailed with more relations to data structures and practical implementation as I progress.

So, one thing I need to work on is undoing is my tendency to write real code before I have a strong understanding of it, especially if said problem is very complicated. We should be sketching it out first, see how it all looks, and then implement it.