No, I Will Not Fix Your Computer (Or How to Solve Any Problem)
I recently discovered a wonderful little book I wish I had known about when I was still a student: How to Solve It by G. Polya.
It's intended for secondary school math teachers to help their students think through problems on their own. But it's really a manifesto for how to think. The 'it' in the title is 'any problem'.
Why hasn't anyone written this down before? Why haven't I? The fundamentals of analytical thinking are rather basic, but not frequently expressed.
This is the version of Polya's four points I've unknowingly been using for years:
- Understand the problem
- Devise a plan
- Carry out the Plan
- Examine the Solution
Be skeptical! Don't assume that any of the facts you have are actually facts until you can verify them yourself. Whoever wrote that bug report is probably an idiot. (Especially if I'm troubleshooting my own bug report.)
A fact that doesn't support your guess is still better than wrong information. Just getting enough information so you know what problem to solve puts you halfway to a solution.
You can always ask yourself "What would Sherlock do?", but it doesn't help much since Sherlock is a fictional character. That toaster you're trying to debug, the one on fire, is very much real.
But Sherlock does one thing that can help solve a problem: work backwards. When I'm handed a complicated system that isn't doing what it's supposed to, it helps to split it into smaller pieces. What do the individual parts do? How could they fail? If the whole system is busted, you have a rare guarantee that one or more of its components are busted as well.
Steps 1 and 2 often overlap, so I write my hypothesis in pencil. And remember that hypothesis is just a fancy word for guessing.
If I've made it to this step the solution is merely mechanical. Much of the time I can just outsource it to someone else. Either way I'm bored now ...
I often neglect this step. Far too often I solve a nasty problem and forget how I did it later. Documenting my code is often the only thing preventing me from starting over from scratch.
Polya points out that if you give a student a problem they find too challenging, or worse turn the process of finding the solution into rote memorization, even the most promising student will turn away from mathematics and related fields for the rest of their life.
Perhaps this is the source of the learned helplessness expressed by so many end users of technology. They don't remember that there's a "secret" checklist they can deploy to take back control of the tablet, dishwasher, or whatever appliance happens to be ruining their day.
A question I ask all the time now (of myself and others) is "What problem are you actually trying to solve?" That simple question always gets results: it forces the synapses to fire again by demanding a thoughtful response.
Otherwise you miss out on a rich, inner world of mental struggle. There is a reward in getting it wrong, and then getting it wrong, until you finally get it right. It can only come from the anguish of learning the method, applying it, and still getting the wrong answer until the right one appears. Debugging a kernel module, rewriting a paragraph, it's the process that brings its own reward.