There's a 4th way, but it works least often. Maybe Method 2.5 fits better: Wait for the problem to fix itself to your level of risk. Ex: This road is blocked. I have a good news it won't be blocked in X days/months/years. Let's just wait until it's a little better for us to travel down and do something else for a just little while. It's a hybrid between waiting for the path to open up for everyone and forcing your way through. Taking a stepping stone between changing the world and changing your solution to the problem.
My experience in trying to build AI tools has always been the 4th way :) Let’s build a coding agent in 2022, procrastination takes over, and then came along Aider, Cursor, Roo, and others. Same with AI observability tools. Wait just enough time to see the tools built themselves.
That 4th way is a nicely realistic but very toxic (in my experience) way to solve problems.
Not when it’s applicable in the situation but if you use it in your toolbox it’s very easy to overapply, if you’re a hammer everything looks like a nail style.
There's way number 1.5: Solve a different but related problem, which gives you like 80% of the benefits of solving the original problem, but at 20% of the cost. This allows you to experience much less pain without an investment of resources you can't afford.
Two methods I have found useful. If it seems an intractable problem, you've made two goals equal. Figure out the conflicting goals and decide which will give way, such as once I think about it I realize the unspoken goal is I don't want to challenge Mom, M-I-L, Boss, etc.
Second method is 6 steps:
Intel, intel, intel, always be gathering intel.
Clear mind, set aside emotions.
Clear vision of what I want, the more clear and detailed, the more likely I'll get the result I want.
Detailed plan to get from current reality to vision.
Execute plan.
Debrief: what worked, what mistakes, etc.
I do this with emails I'm not even angry about. Wait for your audience to come to you wherever possible. It's a lot cheaper to leverage the momentum of other people than to get them started from zero every time. I find the desire to author angry emails is often a side effect of trying to go too fast.
A favorite of mine: assume a sub-problem has a solution (even though it doesn't), and solve everything else assuming that solution holds.
I find that after I do that, once I have a solution for everything else, a less-general solution to the sub-problem is often sufficient to keep the global solution valid.
To try to come up with an example, let's say we set as our goal to completely automate a process X, which consists of 10 subprocesses. Let's say we fairly quickly automated steps 1-9, but the 10th is tricky.
But we now realize the 10th step was only really necessary for certain edge cases, which we now realize we are fine not handling. So we "if" them away and now have a process that is 100% automated, even though it is different from what we originally wanted to achieve.
The site's text is medium blue on a gray background with a font-weight of 300. I'm all for a bit of visual variety and personal expressiveness but this is pushing the boundaries of accessible legibility on some systems and screens.
(Yes, I realize there are various browser accessibility tools, reader modes and even custom CSS overrides, but I'd prefer not being forced to force those things on for all sites - because it means that "bit of visual variety and personal expressiveness" no longer exists for increasing numbers of visitors.)
There's a 4th way, but it works least often. Maybe Method 2.5 fits better: Wait for the problem to fix itself to your level of risk. Ex: This road is blocked. I have a good news it won't be blocked in X days/months/years. Let's just wait until it's a little better for us to travel down and do something else for a just little while. It's a hybrid between waiting for the path to open up for everyone and forcing your way through. Taking a stepping stone between changing the world and changing your solution to the problem.
My experience in trying to build AI tools has always been the 4th way :) Let’s build a coding agent in 2022, procrastination takes over, and then came along Aider, Cursor, Roo, and others. Same with AI observability tools. Wait just enough time to see the tools built themselves.
That 4th way is a nicely realistic but very toxic (in my experience) way to solve problems.
Not when it’s applicable in the situation but if you use it in your toolbox it’s very easy to overapply, if you’re a hammer everything looks like a nail style.
Use it critically
There's way number 1.5: Solve a different but related problem, which gives you like 80% of the benefits of solving the original problem, but at 20% of the cost. This allows you to experience much less pain without an investment of resources you can't afford.
Aka "quickfix" or "hack".
Rinse and repeat
Two methods I have found useful. If it seems an intractable problem, you've made two goals equal. Figure out the conflicting goals and decide which will give way, such as once I think about it I realize the unspoken goal is I don't want to challenge Mom, M-I-L, Boss, etc.
Second method is 6 steps: Intel, intel, intel, always be gathering intel. Clear mind, set aside emotions. Clear vision of what I want, the more clear and detailed, the more likely I'll get the result I want. Detailed plan to get from current reality to vision. Execute plan. Debrief: what worked, what mistakes, etc.
It's very interesting that he's talking about start-ups.
I worked for one of Fragner's start-ups and it was an unmitigated disaster in all ways.
He secretly recorded a meeting with myself.
This is why you schedule angry emails to be sent the next day. Maybe you’ll wake up and realize it’s not a problem at all
I do this with emails I'm not even angry about. Wait for your audience to come to you wherever possible. It's a lot cheaper to leverage the momentum of other people than to get them started from zero every time. I find the desire to author angry emails is often a side effect of trying to go too fast.
Where does "Make the problem worse so someone else fixes it" fit?
It's in own category for higher level beings who make pot holes bigger until it gets fixed.
I’d add a fourth option: not over-trusting the methodology itself.
The world isn’t a perfect-information game, and many “problems” are defined under uncertainty.
A favorite of mine: assume a sub-problem has a solution (even though it doesn't), and solve everything else assuming that solution holds.
I find that after I do that, once I have a solution for everything else, a less-general solution to the sub-problem is often sufficient to keep the global solution valid.
I wonder what a specific example of this approach would be.
I'm intrigued and would appreciate further examples/explanations too.
It's an interesting approach.
To try to come up with an example, let's say we set as our goal to completely automate a process X, which consists of 10 subprocesses. Let's say we fairly quickly automated steps 1-9, but the 10th is tricky.
But we now realize the 10th step was only really necessary for certain edge cases, which we now realize we are fine not handling. So we "if" them away and now have a process that is 100% automated, even though it is different from what we originally wanted to achieve.
I wrote this up as the four disagreements.
https://blog.onepatchdown.net/philosophy/2023/10/03/four-pil...
This misses bad faith, lack of good will and assume an aligned objective (i.e. lack of selfishness)
be first, smart, or cheat.
The site's text is medium blue on a gray background with a font-weight of 300. I'm all for a bit of visual variety and personal expressiveness but this is pushing the boundaries of accessible legibility on some systems and screens.
(Yes, I realize there are various browser accessibility tools, reader modes and even custom CSS overrides, but I'd prefer not being forced to force those things on for all sites - because it means that "bit of visual variety and personal expressiveness" no longer exists for increasing numbers of visitors.)