When you’re looking to solve an everyday problem, think through things just a little bit harder. I’ve been thinking about a couple of principles that could help with everyday problem solving. Of course, all this is retrospective, so you have some kind of hindsight bias built in. But the principles are: surveying a couple steps ahead, subsampling, decision tree logic/sequencing your actions, and expected value calculations, or cost to perform an action.
A couple of problems have risen in my life. A little bit of thinking in advance could have saved a ton of time and resources.
Case 1: Cold Pho
When you order pho, you get some raw meat. You put the raw meat into the bowl, and the hot soup cooks the raw meat But when you order take out, you get the soup in a to-go plastic container which does not guarantee hotness.
After you excitedly bring the take-out home, the natural course of action is - you take the noodles, vegetables, the meat, and pour the soup. If the soup doesn’t cook the raw meat, then you put it back into a pot, heat up the entire thing to make this process work.
This is dumb. This is what you could do instead. Take a spoon and taste one spoonful of the soup. If it’s hot, stop. If you’re still not sure, first, you put the 1 slice of meat in the bowl. Then you pour small amount of soup, and see if it cooks the meat. If it is good, then you can dump the entire thing.
The natural disadvantage of this is that temperature decays extremely fast. So while you are sampling, you could lose the temperature of the entire soup.
Case 2: Leak in an Apartment
This happened to a friend recently. cough
There is a leak in an apartment complex on the first floor. The plumber is summoned! The plumber decides to cut up the wall in the 1st level apartment, check for leaks. Nope. Goes to the 2nd level apartment, cut open the wall, then check for leaks. Nope, not leaking. Now he goes to the 3rd level apartment, and checks for leaks. Yup, it’s there. Thankfully he doesn’t have to open up the wall.
This is stupid if you think about it. You’re cutting up 2 walls before you diagnose the solution. Why didn’t he sample the problem range before taking action?
This is how it could have gone.
You ask the 2nd floor and the 3rd floor residents, “Hey, is there anything that happened in your bathroom recently that could indicate a leak? Can I come check?”
If they’re not home, you could call management: “Hey do you have number for unit 20X, 30X?”
You call them, and say, “Has there any leak of any kind, or change recently”? Looking breadth-first in this case is an optimal approach.
Maybe the plumber could have easily diagnosed the solution there, and finished up the job. But hey, maybe his incentives are different. Perhaps he wants to optimize for increasing his hourly rate! But if he is not mischievous or unethical, this is the wrong approach.
Anyways, if the plumber asked the resident on the 3rd floor maybe he could have spotted the issue a lot faster without wasting so much time.
The other thing is strategy and the sequence in your provide the options, as well as calculating the discount factor.
So the plumber finds the problem on the 3rd floor. He says he could fix it, gives him an hourly rate and everything. The thinks about it, has no information on whether or not it’s expensive or not, has no information on the rates of plumbers(thinks it’s high), and cannot do any research since he has to make the call now.
As the friend doesn’t have doesn’t have enough information, the friend declines the repair.
Now at this point, the plumber could say, “Hey I’m already here. Instead of charging you a rate $X, I’ll do it for $0.9X. “, or $X - cost it takes to get to another location.
I’m almost certain that if you mention the magic word, “discount”, the plumber would’ve had a much higher chance of converting my friend to take the plumber’s labor. Hell, he could have given a smaller discount and it still could have worked.
Notice how this is different from if the plumber gave a discount first. It’s better for him to save the discount for a rejection, since it will increase his expected value(if he does this move multiple times, there’s that assumption built in there…)
But the plumber didn’t make this move…
Case 3: Production Bug
At work, we had a bug in production. So 5 - 8 of us are on a call, we proceed to try to find why an api request is getting double called. An hour in, we find the most probable cause - a UI issue, but we are not certain. After we found the most probable cause, we proceed to spend another hour+ trying to diagnose all other possible problems.
This is where I’m dissatisfied with how it went. If the possibility of the bug we found being the root cause is 80%, and the prod bug isn’t mission critical, then isn’t it better to assign someone to fix it, and then come back to it? Why would you still be exploring for the other 20%? It makes no sense.
You fix the bug with the 80% probability first, then you explore the remaining options. Because finding the 20% is much, much harder. Just all marginal utility. Another advantage you get from this, is this. Ff the bug takes a day to fix, then developers have 1 night to sleep over it to let the brain parallel process.
To sum it up mathematically:
80% probability of bug is the issue * time it takes to fix it + time it takes to look for the other 20% + 20% probability * cost it takes to fix the issue.
Could have rearranged this to consume only the 80% probability of bug is the issue * time it takes to fix it….
In this case, it’s a bit opposite of the case of the apartment leak, except the cost to look for the other 20% is HUGE, while the cost to sample a solution at a higher overview before diving in is extremely low.
Summary
Maybe it’s the computer science in me, but for every action or a problem, there is some theoretical magical, optimal moves that will get you to the right solution. This is the Move of God. The steps that God would take are there in the solution space, except we probably don’t know… Instead of taking the first action that comes to mind, maybe we should explore more and think through alternative approaches.