How I solve problems

I'm not really sure how I solve problems. What I'm betting though, is that I could improve my problem solving ability by paying attention to the process as I bumble through it. Maybe we all could. So let's define this with a touch of formalism.

Where I'm at

I have a problem to solve. I've got an existing program, and I need to make some changes to it to enhance its functionality. I must think that this is a hard problem, because I have procrastinated significantly on it, and every time I go to start it, I get a little lost.

The sense of being lost comes from a few directions.

1) There are multiple ways to solve the problem - some easier than others, but with hard to quantify costs of later complexity and code to rework.

2) The existing program is a hacked together mess.

3) I haven't really solved this problem before.

4) There are technical tools which would help with some of my possible plans for moving forward, but I am not certain that those are necessary or, more importantly, allowed.

Knowing this, I see my primary boundaries (and solutions to them) as:

1) I have a goal and a starting point, but no real hints about a transformation function to arrive there. I need to choose what path I'll walk along.

2) The existing program may be useful later, but for now, it must be disregarded. I'll see what I can salvage once I know how I want to do this. Note: this is easy, because the existing program is only a few hundred lines of C/C++ in a single file.

3) This just makes me a little less sure of myself.

4) I do not know enough about the limitations on the assignment to make good assessments for technology to use or to not use. It is unspecified in the design document which technology I cannot use. So, I'll just assume it's allowed unless we're told it's not. Within reason.

What next?

I need to choose a path, and that would be easiest to do if I just start working along a hypothetical path. I've been bogging myself down in the different possibilities at the start and not wanting to commit - well, I'll just start thinking my way through the beginning (and then the rest) in as high level a manner as I can. This is a problem well suited to a top-down design, and I know (from up above) that I don't have to keep much of my existing work.

So the next step is: draft out some plans.

Depending on the sort of work I'm doing, I like to make plans a variety of ways. I tend to work well by expressing things verbally, which means I like to talk through them. This is why I'm writing this blog post.

Next up, I want to do some more specific planning. Like code planning. But rather than pop open vim (where I'm fast when I know what I'm doing, and slow when I don't), or MSVC++ (where I'm constantly trying to think of how to do things better), I'll work on paper, with a pen. This will make diagramming (should I want to do it) faster, and help to free me from thinking about technical details for the moment. Right now I don't want technical details; I want high level organization, overall understanding, and to work through some math. Paper is the perfect technology for this.

But what I really have to do right now, is mark some students in a class I'm TAing, for the next three and a half hours. It'll be hard to work during, but hey, it's a living. :)