Problem solving is fundamental to all the work we do, but it’s not a skill that’s taught or talked about explicitly all that much. This can be a major barrier for people in their day to day work, and also in their career development. I want to address that a little by talking through some classes of problem, and problem solving techniques and strategies.
Formal problem solving
The term “problem solving” has two distinct uses in IT. When we’re talking from a computer science point of view, we consider “problem solving” to be a question of identifying an algorithm to solve a given problem. There is a huge amount of material from both mathematics and computer science about this side of problem solving.
HINT - if this is the kind of problem you have, AI/Google/Design Patterns will provide you with a good answer. “go get a predefined answer from the GoF book” is a heuristic, which we’ll talk about in a minute.
The most important thing to know about an algorithmic problem is the size or complexity of your problem, and hence how long it might take to solve.
Size and Complexity of problems are a factor of the number of possible permutations - if you need to perform an operation on every one of 10 elements, that won’t take long. Every one of 10**100 will take… quite a bit longer.
There’s a famous problem in computer science called the ‘Travelling Salesman Problem’:
Given a list of cities and the distances between each pair of cities, what is the shortest possible route that visits each city exactly once and returns to the origin city?
In simplistic terms The Travelling Salesman Problem can’t be solved without (figuratively at least) trying every permutation - there are no computational shortcuts. It’s classified as ‘NP-Hard’, and we see many variants of it in e.g. iterating over sets.
So when choosing how to implement program logic, always think about the size of your data sets and whether your chosen approach will work with the amount of data you’re likely to see, especially with nested loops.
Heuristics
In problem solving terms, a heuristic is a ‘near enough’ approach. Most of the time it works, but it’s not guaranteed to work. Design patterns are a kind of heuristic - they’re a one-size solution to various common problems. You might need to tweak the detail of a design pattern for your individual use case, but the broad approach is probably right. Similarly, “switch it off and on again” is a heuristic for a lot of problems where finding and fixing the true cause is hard or impossible to find and not really necessary to overcome the immediate problem.
That’s as much as I’m going to say about formal problem solving because it’s not really what we’re here for. It’s useful to have a bit of background knowledge of it as we move into troubleshooting..
Troubleshooting
The ‘other’ kind of problem solving is sometimes known as trouble shooting. This is approaching a novel real world problem needing to find a resolution. If you google ‘trouble shooting’ you’ll find a number of variants of:
Gather Information
Describe the problem
Identify probable cause
Create a plan
Test the plan
Analyse the result
Document the process.
All of these are much easier to say than to do. Gather which information? Identify the cause how? They’re good sensible steps but they assume too much.
So, things that you can do to identify and solve a novel problem:
Heuristics
We talked about heuristics in the previous section, but if anything they’re more applicable here. Have you seen this kind of problem or something similar before? What worked on that occasion? Watch out! It can be really easy to convince yourself that you’re seeing exactly the same problem - be on guard against heuristics pushing you in a particular direction. It’s really easy to think that it “must” be the same problem you saw once before, and that can trap you in a blind alley. Very often experience of similar symptoms can be an indicator and may enable you to find a quick solution, just remember to keep checking whether you’re spending too much time on a single approach.
Break it down
The absolute number one strategy for solving problems. Most of the time the problem is difficult to solve because there are too many variables. So… eliminate some. Simplify the situation by isolating the place where the problem occurs. Break the failing process down into pieces and test each one in turn until you find where the problem lies.
It’s often productive to eliminate parts of the system from each end until you converge on the problematic section.
Read around the problem
The more information you have about the problem domain, the more likely it is that you’ll understand what’s going on. It’s really easy to solve problems in something you understand really well, but much harder with something you have less knowledge of.
Watch out! You can spend days digging through documentation and getting nowhere. Don’t make this your first step - learn something about the symptoms before you start researching.
Two heads are better than one
Find someone to talk through the problem with. It doesn’t necessarily have to be someone more experienced, and you’re not necessarily asking them to come up with a solution. But simply expressing the problem in words will often force you to think about it in a systematic way and lead you to the solution.
See also Rubber Ducking
Minimal Test Case
This is the big hitter of problem solving. It’s the same approach as Break it down from the opposite direction - build the most minimal model you can of the problem that still displays the same behaviour. This is an approach often used for bug reports with public APIs etc: creating the most minimal case you can will often tell you exactly where the problem lies. Hint: write it using a test framework if you can.
While it’s primarily a software technique, nothing prevents you from creating minimal test cases in other classes of problem.
Breadth of knowledge
This is Read around the problem but pre-emptively. If you have a broad range of knowledge of tech, very often things you’ve learned in other contexts will help you to solve the problem. The number one topic of background knowledge that will help you is networks. Understanding how applications talk to servers - the network protocols, infrastructure and addressing standards they use is the most valuable non-dev tech skill you can have.
Number two is Testing. Understanding test techniques and frameworks will help you to build minimal test cases and break your problem down.
Practice makes perfect
Just solving problems is good practice for solving other problems. There’s nothing quite like experience to help you get better at it. Even just solving logic puzzles can help you develop problem solving skills.
AI
Problem solving is something AI is really quite bad at. It’s great for finding possibly related information, but you’ll need to review and compare those cases with your own example. Think of it as a tool for “reading round the problem” or “rubber ducking” rather than a problem solving approach in it’s own right.
Staying calm
Very often problems crop up under difficult circumstances. We’re often called on to solve problems under time pressure, or with direct impact on end users, or more often both. There can be pressure from clients to find a solution, and when a problem is high impact sometimes senior stakeholders will make their presence felt.
Stay calm. Rushing to fix will cloud your judgement and often lead to mistakes that can make the whole situation worse. Sometimes much worse. Writing down what you need to do next can help, work slowly through things that could go wrong, and if possible get someone else to check you as you go along. If there’s someone who can keep the stakeholders at arms length while you work, get them involved too.
Take a break
The biggest danger in troubleshooting is getting yourself stuck in a blind alley. You can spend too much time pursuing one particular approach and convincing yourself it “has” to be a particular cause. Then once you finally get a solution you’ll beat yourself up for not realising sooner. Keep stepping away from the problem every once in a while to get some perspective. Maybe ask someone. If you’re really really stuck, go for a walk - getting some space and relaxing a little will often help.
Putting it all together
The trick to effective problem solving is to use the right combination of techniques. In some cases it may be that the best way to solve the problem is to create a minimal test case, but a heuristic approach might shortcut that and get us to a solution quickly. A typical problem might involve:
Use your experience to try out a few possible solutions (heuristics), but don’t spend too long on this approach.
Break down the problem to try to isolate where it’s happening.
Talk the problem through with someone.
They might have heuristics to try, so try those.
Break the problem down further, try to isolate the exact cause and maybe create a minimal test case.
Do some reading based on your minimal test case.
Step away and take a break, then come back fresh
Evaluate your progress and see if you need to change tack
You don’t necessarily need to do all these steps or in this order but these will be the kinds of steps that lead you where you need to go.
Above all, don’t panic! If you can’t fix it, you can always find someone to help.
No comments:
Post a Comment