Ask HN: How do you approach a problem you are not sure has a solution?
How do you battle against (self-inflicted) anxiety/paralysis when you are attempting to tackle a problem you are not sure has a solution? I have a very open mind to solving problems but it can make it difficult to come to conclusions. Anyone know what I'm talking about here? Have any advice?
299 comments
[ 2.7 ms ] story [ 317 ms ] threadThe point here is just to get moving in some direction, get familiar with your data and start testing some assumptions. I learned a lot about my problem from doing this and eventually came up with some testable theory.
Forget architecture, "elegant code", time complexity, "does it scale" etc - just write things that give you answers or allow you to gain some insight and do so with the minimum of effort spent on design. If you ever find yourself onto something you can refactor then. For me the main thing is to get the learning process started.
Break the problem up into pieces and solve the pieces.
Problems: Analyze, break down, examine from all angles and add details. Then try solving.
I spent my career trying to teach this exact concept to my engineering teams. I agree with you 100%.
If I'm approaching the problem first and not the solution, I try to classify if the problem is technical or organizational. If it's technical, I try to identify each of the barriers, and search endlessly for something that looks like it would get me a little further along in getting insight into how to solve the problem. It its organizational, I look at how I would restructure how I am approaching the problem or work or communicate with others in solving the problem.
Sometimes, I need to redefine the problem, scope of the problem, or what a successful outcome looks like. For example, I wanted to find a way to verify that the reports I was entering in PDF forms were being filled out properly. I spent forever trying to find a tool or program the PDF form to be verified. After a while (several months), I realized that verifying a spreadsheet would be a lot easier, and that I could generate the same report from the spreadsheet. Once that perception changed, I was able to tackle the problem I had: not being able to ensure that a procedure was filled out properly.
Same as for problems I am certain have solutions.
For me, it's all about the work, not the fruit.
But the caveat, I focus on projects that are going to bear fruit because most problems that might bear fruit probably won't and I'd rather be productive than important.
YMMV and that's aOK.
my advice is to do something without worrying that it might not be the right thing.
https://en.wikipedia.org/wiki/How_to_Solve_It
https://en.wikipedia.org/wiki/TRIZ
Lots of good tactics here, but ultimately I think everything boils down to understand the problem better.
Your solution will only come from superior understanding of the problem, if there is one. It probably won't come from testing different solutions.
Almost all software starts with "what is the intput and what is the output" and then understanding how the input leads to the output. If you don't know the input and the output to your system, then you don't have understanding.
Even in your text, you have a "solution" based frame to your statement. Subordinating the problem to the solution rather than the solution to the problem puts so much focus on the solution that the problem itself gets defined in terms of the solution. I have seen feature developers play this out time and time and time again. When the problem gets redefined in terms of the solution, often the original problem remains resulting in increased complexity at little additional value.
So I would start by understanding that not being sure a problem has a solution means you don't understand the problem and its context enough to even be asking if it has a solution which means you should be asking "how do you better understand problems?" or "when do you stop investing in understanding problems?" or "what is a good time trade off between 'understanding problems' and 'directly handling business concerns'"?
When you understand the problem, you'll probably come to the realization that you were asking the wrong question altogether. There are so many times someone came to me with a problem with a system I understood that they did not and it was clear they were asking the wrong question. Frequently, I could tell them what question they were trying to ask because I knew things they didn't know they didn't know.
You may find Bloom's taxonomy interesting as a frame for thinking about how to achieve better understanding: https://en.wikipedia.org/wiki/Bloom%27s_taxonomy
Minimise work on problems with an obvious solution and identify working on the ones that are more mysterious as the most valuable work there is to do. Make a habit of extracting the most from the process, even if it didn't end up in a solution. For example: writing down (and sharing with others) what was learned.
Psychologically, you need enough repeated positive reinforcement, where you work on a problem, end up not solving it, extract the most learning, get recognition from yourself and from others that it was worth the effort. After enough itterations it starts feeling better.
One thing I would add is the perspectives and ideally the participation of other people. Absolutely essential if the challenge has any kind of social dimension.
I once explained this to an audience using a riddle: "How far can you walk into a forest?" That type of riddle has no method or algorithm for solution. The answer usually "comes to you" or doesn't. But knowing that riddles depend on a play on words or different meanings of words in different contexts, I suggested that one can analyse each word at a time: e.g. "you vs. someone else?", "walk vs. some other way of moving?", "into vs. out of?", "why specifically a forest?" etc. The answer, of course, comes from "into vs. out of" -- you can only walk into a forest till the mid point. After that you're walking out. Not an ideal example, but I always remember it when I'm faced with an intractable problem.
The method also helps stay motivated because there's a sense of progress: you're racking up a count of things that are definitely not the cause of the problem.
That problem has neither a theoretical nor a practical solution.
That what I was talking about in my first sentence, but my post wasn't clear, I admit. Thank you, it helped me clarify.
NP=P? There are many other famous math problems. No one found solutions yet and it is also unclear whether one is able to find a solution. And it's unclear if there is even a solution.
Surprisingly often this method works.
I find that this kind of first principles approach gives me a much better understanding of the nature of the problem. I may still not know how to solve it but it usually gives me insight into how to attack it most effectively.
Cutting the Gordian Knot [1] When solving impossible problems, ask yourself:
* Is there an easier way?
* Am I solving the right problem?
* Why is this a problem?
* What makes it hard?
* Do I have to do it this way?
* Does it have to be done at all?
[0] - https://en.wikipedia.org/wiki/The_Pragmatic_Programmer
[1] - https://github.com/HugoMatilla/The-Pragmatic-Programmer#cutt...
Over the past few years when I have had problems that pop up or what really happens is that I go looking for problems, the most often solution has been to literally do nothing.
And having that as an active option when I first start looking at the problem and listing solutions ends up having far more options to me for the problem than if I was like "I MUST SOLVE THIS".
It could also mean "wait" is the best possible action I can take now. And instead of being perturbed by waiting it is an active decision to wait.
E.g. mulling for weeks over optimizing some code until you realize to measure it as-is and it isn't even slow!
Or maybe there's room in the underlying design to shift the weight off the problem, thus "solving" it laterally (by solving some other, easier, problem instead).
> Il est urgent d'attendre
which loosely translates to:
> waiting is of utmost urgency
The french quote can be traced to a translation of Asimov's Foundation, but I can't seem to find the original version :/
It's actually much older than that, I read it already in 19th century books; no idea when it first came out.
As an example: I worked on a PhD in applying machine learning to certain tasks in programming and mathematics. I ended up burning-out and had to quit.
When I started in 2014, most cutting-edge ML research was on image processing like convolutional neural networks. That's a very bad fit for the sorts of tree-structures and text sequences I wanted to use. The state of the art for the latter were RNNs which are notoriously slow (hard to parallelise), suffer exploding/vanishing gradients (needing e.g. LSTM), etc.
Transformers and LLMs solve the issues I was facing; so in hindsight it would have been better to wait a few years (I believe the Attention Is All You Need paper came out in 2017?)
The story from math is that of a student who fell asleep and was late going to his final. He walks in, sees three problems on the blackboard, and works frantically to solve them in the time he has left. Valiantly, he manages to solve all three, turns it in, and just hopes for a passing grade.
Later he gets a call from the professor who asks "do you know what you did?" The student's heart drops, thinking he's failed miserably. The professor continues: "You were only supposed to do the first two problems," the professor explained. "That last one was an example of an equation that mathematicians since Einstein have been trying to solve without success. I discussed it with the class before starting the test. And you just solved it!"
Note that this story is actually (approximately) true! George Dantzig, a UC Berkeley PhD candidate at the time, solved an unsolved problem in math as homework, and the plot was later used in Good Will Hunting. Dantzig was later awarded National Medal of Science by President Gerald Ford.
https://www.snopes.com/fact-check/the-unsolvable-math-proble...
> A year later, when I began to worry about a thesis topic, Neyman just shrugged and told me to wrap the two problems in a binder and he would accept them as my thesis.
The "two problems" being referenced here are, of course, the two unsolved problems he solved as homework.
Imagine the global boost in productivity and knowledge-sharing...
That being said: Consider that sometimes there are problems where you yourself will be unable to judge the problem you're in, because you are in it. It can be a bit of a bootstrapping problem: If you were the person who could see the solution, you might not have ended up in the situation in the first place. So the logical solution can be to get outside help so advice by a trusted person or actual therapy.
Getting out of a hole can sometimes be done by clawing yourself out, but sometimes having someone throw you a rope is the smarter move.