On the Nature of Problem Solving

In my experience, development is roughly 20% planning your code, 5% writing your code, and 75% figuring out why the fuck your code doesn't work. Programmers are not painters, nor are they an infinite number of monkeys - they are problem solvers.

I would arrogantly consider myself an above-average problem solver. In fact it is one of the few disciplines in which I think I am in the upper quartile of the general population.

In general, when presented with a problem, assuming the subject is not far outside my usual outstanding, I have a handlful of immediate ideas about how to go about solving it. The interesting part of solving a problem is when those ideas have been exhausted - how does one generate more potential solutions?

The most obvious answer is to seek outside help, for example from a search engine or Stack Overflow. Sometimes doing so is unsatisfying, and sometimes even these seemingly omnipotent tools do not contain the knowledge we seek. The next step usually involves trying to state the problem as concisely as possible; take note of every single relevant piece of information individually, and attack it from first principles.

The most enjoyable, and hilarious part of attempting to solve a problem with one's code is the final step - the desperation play. At this point we are essentially trying to anti-fuzz the problem; we constantly feed it garbage inputs until something magically works. Comment out every modular piece of code. Add variables. Change variables. Delete variables. Run the code in a different environment. Run the code on the other environment a second time - make no other changes. Recompile the code. Restart your dev machine. Reinstall your OS. Try a different distro, upgrade your hardware, get a new job, relocate across the world - I don't know, something will work eventually.

Embarrassingly, I solve a lot of problems using the desperation play.