The Five Types Of Problems
Joshua Mitchell / August 07, 2020
8 min read
Most problems you have will fall into one of the following 5 categories. From most defined to least defined: Bacon, Faucet, Maze, Password, and Blizzard problems.
If you’ve ever seen this meme:
Then you know what kind of problem this is. There are no iterations or tries needed— you just say the word or “do the thing” and the problem gets solved.
Example: Wanting a side of bacon at a restaurant. You put in the order and it shows up.
Everyone has their individual water temperature preference when it comes to showering. What we have in common is how we find it.
We step into the shower, turn the handle to start the flow, test the temperature, turn the handle slightly, test it again, turn the handle just a tiny bit more, and finally— it’s just right.
Problems like this are iterative (i.e. not just solved in one swoop), but every step gives you feedback in the right direction.
(My math people might recognize this as a convex optimization problem, where you’re trying to find the minimum (or maximum) output of a function and any input you plug into it is guaranteed to give you good information.)
Example: When the people with the orange batons help planes land. The plane is constantly shifting its direction based on feedback until it docks safely.
If you’ve ever been in a maze or done a Sudoku, then you know what I mean. You try a few things. It seems promising. But then, you run into a dead end.
Maze problems are problems where each iteration gives you new information, but there’s no guarantee you’ll understand it nor that it’ll be helpful. Fortunately, when you’ve solved it, you’ll know it.
Example: Trying to solve a Rubik’s cube.
If you’ve ever used the internet, you’ve made an account with a password. Chances are good that you’ve also forgotten that password.
If you’re like me, sometimes you’re feeling broody and you refuse to submit to the “Forgot Password” process. You’ll keep trying to guess your password but you eventually realize the futility of your ways. Fortunately, the service will send us an email to get back in.
Unfortunately for everyone else trying to get into our account, they’ll just have to keep guessing. Each iteration gives a binary "correct" or "incorrect" - that's it.
Information about one iteration does not generalize to other iterations (which is what separates Maze problems from Password problems). The only way to find the answer is to keep trying stuff until something sticks.
This is the spirit of a password problem. If you know the answer, it becomes a Bacon problem, but if you don’t, you have to exhaust all possible answers by brute force in order to find it.
Example: When your friend hands you a controller for a game they’re playing and you’re pressing all the buttons to figure out how to move.
If you’ve ever been caught in a blizzard, it’s extremely hard to see. You can’t see your hand in front of your face. The worst part: you can be exactly where you want to be, but you’d never know.
This is a Blizzard problem. The iterations may or may not provide useful information, but even when you’ve stumbled upon the optimal solution, you won’t know for sure! The solution space isn’t well defined.
You can still find a “good enough” solution. Lots of important, real world problems are like this. We know we have a problem but, unlike school, there is no page in the back of the book that tells us we got the right answer. We just have to use what we have and do what we can.
Example: Drafting “fair” laws, creating useful products, and writing good software.
Two interesting observations about classifying problems:
- The level of complexity for solving a problem can be subjective and depends on the person’s existing expertise.
Figuring out how to checkmate someone might be a Bacon problem to a chess grandmaster, a Maze problem to me, and a Password problem to someone who knows nothing about chess.
Passwords themselves, like mentioned earlier, are an example of this. Entering my password, assuming I remember it, is a Bacon problem to me, but a Password problem to everyone else.
- Problems can be seen as sets of less complex problems.
Let’s say you’re trying to run a profitable lemonade stand. You have no idea what the best lemonade stand looks like, so this is a Blizzard problem - at least, to you.
You could set some goals for the stand and turn it into a Maze problem.
You could turn it into a list of tasks, such as
- searching online for the cheapest lemonade stand (Faucet problem),
- ordering it once you find it (Bacon problem),
- constructing it once it arrives (Maze or Faucet problem - how good are you at furniture assembly?),
You could even hire an entrepreneurial middle school kid and have them take care of everything, thereby turning your Blizzard problem into a Bacon problem.
All companies have problems in each of these categories. The Blizzard problems are where you establish your competitive advantage: establishing the vision, creating the best product, hiring the best people, etc. In fact, if you’re in the C-Suite, often your job is to turn your complicated problems into Bacon problems by hiring someone smart to take care of them and having him or her report to you when finished!
The administrative work tends to be composed of Bacon problems (like picking up a package) and Faucet problems (like filling out an online form).
If your company needs software written (a Blizzard problem), chances are that they have too much on their plate to learn to code, so they’ll hire software engineers. Writing good software is hard, so engineering processes like Agile were invented to reduce complexity and move it out of Blizzard problem territory. Ideally, the engineers write some needle-moving code, the business gives them useful feedback, and the cycle repeats.
Unfortunately, since writing software is hard, it is often hard to reduce the problems past Maze territory. Hidden complexity is unearthed and proposed solutions turn out to be ineffective. It appears that breaking complex problems into sets of simple problems reliably is a Blizzard problem itself.
If you’re a professor doing academic research, then you’re probably working on what looks like a Blizzard problem to everyone else but is a Maze problem to you.
If you’re a student, particularly in undergrad, all the problems you’re learning about have been solved. You will never run into Blizzard problems.
In fact, the 4 stages of competency line up pretty well with the 4 most defined problems:
Your problems are Password level to you. You’re just flinging spaghetti against the wall and you can’t even tell what sticks. You have no idea what you don’t know.
Your problems are Maze level to you. You have a vague idea of what you’re doing, but you know there’s so much you don’t know and frequently get road blocked.
Your problems are Faucet level to you. You don’t have it down cold, but you know what buttons to press to get what you want.
You’re at Bacon level. You could do this in your sleep - the problem all but solves itself.
My Own Life#
When phrasing expertise in terms of what problems I can solve and how proficiently I can solve them, these definitions fit nicely.
I love learning, but with certain caveats.
I don’t like memorizing facts or details (which feels like a truck full of unimportant Bacon problems), nor do I like being completely in over my head (like trying to solve a Password problem).
I prefer to be straddled between a Faucet Problem and a Maze problem. I love the constant cycle of creating a mental model of the problem, verifying whether or not it’s correct, and receiving feedback for how to improve it.
If I’m always right or if my hand is held too much, I become complacent. If I’m not right frequently enough or I don’t receive enough feedback, it begins to feel like an ordeal and a source of unwanted friction. When it’s just right, that’s when hours can go by in the blink of an eye.
I think that’s why video games are so addicting. They’re designed to dynamically adapt to you so that you’re always facing Faucet-Maze problems. Real life is dynamic, but the problems themselves seem to be fairly static. As they say - life doesn’t get easier, you just get harder.
I’m not prepared to offer a general strategy for solving each type of problem, but I think labeling problems this way helps pull them closer towards tangibility.
They say that stating a problem precisely is half the battle - I find that to be true, sometimes. The more you can transmute your problems into a suitable complexity, the more motivated you become to solve them - whether that means making a game out of washing dishes or making a plan to launch a company.