Ask HN: How do you approach a problem you are not sure has a solution?

[peteradio]

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?

[gms7777]

One thing that my grad advisor used to emphasize is “failing fast”. That is, for every problem of the form “Is it possible to do X?”, there is a dual problem of “Can you prove it’s not possible to do X?”

Before spending far too much time on the first question, it’s worth it to spend a little bit of time on the second: what’s the quickest way to show that this can’t possibly work? Often this takes the form of looking for statements such as “If X worked, then Y would work too”, and then you go test Y. Just because Y holds, doesn’t mean X does… but if it doesn’t, you know X doesn’t.

It can feel like a bit of a diversion in the moment (“why am I wasting my time with Y, when I really care about X?”) but it has saved me months, possibly years of going down rabbit holes in my career. Likewise, it definitely helps with that anxiety you mention, because it means I at least have some motivation that my idea isn’t completely crazy.

[bbertelsen]

Love this comment because it translates so well to any mentally taxing endeavor. Writing a long-running program? Set a few assertions up front so that it fails immediately before wasting your time. Think about those "failure" condition assertions up front and save your time on practically any experiment. Even chess players do this by surrendering early when they know a game has reached a conclusion.

[bell-cot]

+1...but this may be better advice when you don't have any anxieties/paralysis about the problem than when you do. Turned-out-that-it-was-overconfident approaches to problems have probably wasted far more time than anxieties/paralysis has.

[hinkley]

Peripheral to this, some of my best refactors have come from trying to document why we can’t do X, explaining that we can’t do X because of Y, and realizing that Y does not need to exist.

There comes a point where explaining why we can’t have something is more painful than just fixing it.

[kqr]

This is also a useful technique to validate a new product before committing too many resources building it. Imagine that you have built it technically flawlessly but it's not selling copies. Why might that be? Draw up a list of reasons and test each of those as hypotheses before you build the product itself.

[muzani]

Something similar we do at work is write a quick document on why something isn't possible.

A bug can't be reproduced? Take a video of it working fine, and show the logical path for how the bug couldn't happen.

Can't build X in 3 months? What's the minimum for X? What's the missing component that takes 2 months? We can't have a partnership with A, but why wouldn't it be possible to have a partnership with A's competitor?

[tbihl]

A risk to this approach: if you (or someone working for you, who is trying to tackle a problem) starts to externalize the motivation to solve the problem, optimization may start to favor 'failing fast' rather than pursuing best approaches (e.g. there's only one chance to try something per day, and you/they develop a pattern of pursuing the simplest possibility because it takes the least research and thus makes for the easiest increment of work day.)

[srcreigh]

Can you share a story about this?

[cliff_badger]

I sorry, but I am truly confused at the logic here.

If X, then Y.

To test X works you first you start on Y?

If Y succeeds then you don't know if X failed or not && if Y fails then you know that X failed too?

[alberth]

Isn’t this the Scientific Method?

[ants_everywhere]

There are lots of great answers from a problem solving perspective. But anxiety and paralysis are also psychological and shouldn't normally be involved in problem solving.

Anxiety about problems often leads to rumination, which causes more anxiety. It can be a bad feedback loop. In a rumination cycle, people generally don't seek out new information, so their mind spends time analyzing and re-analyzing the same incomplete information. Lots of tricks on this thread really come down to ways to trick yourself into systematically getting more information.

But I think it's also worth taking a step back and looking at the anxiety as a "problem" in itself that can be solved. And as a psychological problem it's amenable to all sorts of treatments like exercise, therapy, etc. So don't forget to take care of your brain!

That said, one of my personal favorite strategies when I find myself ruminating is to put the problem aside and do some curiosity-driven learning that's adjacent to the problem. It both gives me more information and makes my brain feel less antagonism toward the topic. I usually find this is enough to get unstuck.

[phkahler]

>> Anxiety about problems often leads to rumination, which causes more anxiety. It can be a bad feedback loop. In a rumination cycle, people generally don't seek out new information, so their mind spends time analyzing and re-analyzing the same incomplete information.

I once got in that cycle, ruminating on possible interpretations of a situation. It can really bring you down. I noticed that each of my possible interpretations produced a different (strong) emotional response and concluded that was driving a "need to know". There is a thing in psychology called "intolerance of uncertainty" and for me the emotional uncertainty was driving the rumination.

So when ruminating, ask yourself "why is this so important to me?" If you can't answer that, get some distance from it before the rumination bring you down. In my case I knew that the answer to "why is this important to me?" was itself very important to understand so I kept at it until I had my answer to that.

[m463]

"analysis paralysis"

https://en.wikipedia.org/wiki/Analysis_paralysis

[bell-cot]

Congratulate your anxiety/paralysis on being right, and do not try to overtly solve the problem. Instead, try moving the situation forward in one or more ways:

- Documentation: Write up the history of the problem, when it occurs, which users are affected, what previous work has been done toward solving the problem, etc.

- Reduction: Only look for limited solutions - proving a few of the "easy" cases for some difficult mathematical theorem. Patches or work-arounds that only reduce the impact of a computer program failing. Chemical synthesis of a less-tricky part of a complex organic molecule.

- Counter-example: A counter-example can be literal - the problem was to prove a mathematical theorem, and your counter-example proves that the theorem is wrong. Or, it can be a proof that the problem is impossibly difficult. The mathematical theorem you were told to prove is equivalent to the Axiom of Choice. The computer programming challenge is equivalent to P vs. NP. The physical theory/device you need to create would violate the laws of thermodynamics.

[dmn322]

I'd also add:

- Define a very clear target. Include quantities. If the goal is "speed up the api endpoint"... measure the current performance and define a target. The goal must become tangible and measurable in an objective way. Otherwise, it's just up to someone's opinion whether the goal was reached.

- Get stakeholder buy-in on that target. Also communicate your estimate of the probability of success.

[soupflavor]

These are really solid suggestions with great examples. The only thing I can think of to add at the moment are a few quotes:

- “The difference between screwing around and science is writing it down.” ― Adam Savage (via Good Reads)

- "Divide and Conquer" ― Many

[moffkalast]

Meanwhile...

Boss: "Hey how are you getting on? You said this'll take two weeks tops, we've got so many clients asking for this thing."

It's most problematic when something looks simple and easy at first glance but then ends up with corner cases upon corner cases and the damn thing refuses to work properly while you sink into a pit of despair amidst calls to deliver already.

[kamphey]

This might sound like an easy out but I consider that there is a choice of doing nothing. Sunsetting a problem can be as simple as forgetting it exists in the first place. This is not merely "giving up" but rather deciding the best action take at the moment is do actively do nothing about the problem.

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.

[hypertele-Xii]

I've observed this as well. It's very satisfying to finally realize you don't need to solve it in the first place, because your assumptions created a problem where there was none.

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).

[lloeki]

In such cases I've seen (and used) a saying in french that goes:

> 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 :/

[chriswarbo]

> 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.

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?)

[2devnull]

Are you Microsoft?

[bakul]

Not sure what kind of problem you are talking about but there are a few things you can try:

Look at it from different angles to understand the problem better. Understand its properties better.

Look for its underlying causes. That is, may be you need to solve different problems!

Nibble at it. That is, solve sub problems so that you are left with a smaller (but possibly harder) problem.

Work on them subconsciously. That is, when you learn something new, let it sink in by walking away and doing something else.

Conversely, focus on the problem 100% when you are working it. If necessary, block out all distractions, including mental ones.

Look at it from a potential solution point of view. That is, if there is a solution, think of what properties it must have.

Never give up! Assuming the problem is worth solving.

Conversely, try to prove it is unsolvable so that you give up on it ASAP!

Keep notes and review them often. You may find clues in something you have already noted.

Try to explain the problem, what you have learned and your attempts to an interested person who can act as your sounding board. The process of explaining will force you to organize your thoughts and the other person can ask questions that will force you to think about cases you may not have considered. Without a sounding board and without writing down your observations you may end up going in circles.

[hliyan]

When the solution is blocked by the diagnosis of the problem, and there is no methodology or algorithm for the diagnosis, I usually resort to a sort of "grid-search", i.e. brute force through the problem space. I once had a weird off-by-one pointer problem in circular buffer in a C++ multi-threaded environment (it was almost 20 years ago), and I had to systematically eliminate code block by code block as possible origin, until I got to a block small enough for me to throw my entire intellect at. I solved it.

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.

[Reflecticon]

Great explanation of divide and conquer for any situation. Thanks!

[resiros]

I know exactly what you mean. I worked for years in research in a problem I was not sure it could be solved. Here is the advice I could offer you:

- Determine what is the problem. Easier said than done. You most likely don't understand the problem. Finding the right abstractions to understand what is the problem is half the work. Focus on that a lot early on.

- You will not solve the problem by sitting for two hours and trying to think of a solution. Accept that. If it is a hard problem, it will take you months of thinking, writing prototypes/solutions, trying different angles. And then, at a random moment it will click, and the solution will feel obvious.

- Iterate a lot. Start with something small, solve it, and do it again and again. Accept that you will fail hundreds of times until finding the right solution. Try to make the process enjoyable. If it is a research project, break it into parts, where the solution of each small part provides value (a paper), so that you can enjoy some success that keep you working. If it is a startup, build products that provide value and are in the road to solving the big product.

- Some problems can be solved in a phd, some in a career, some in a generation. If you are targeting poverty, accept that you will spend your life on that with the hope of making small progress.

[xorvoid]

Oversimplify until you can solve a toy version and then try to see if it has an extension to the full problem or if there is some reason it can’t be extended. Sometimes you’ll learn the core reason it’s unsolvable, other times you’ll solve it. Other other times, you’ll be right back where you started but with just a little more wisdom.

The human brain is usually quite adapted to iterating on some existing thing vs summoning a novel solution from the void of unexistance. So, just find Some starting point.

Polya even talks about this in his famous book “How To Solve It”: “If you cannot solve the proposed problem”

[abhayhegde]

Maybe you are aiming at a different audience, but this conundrum is similar to how most research problems in pure sciences go -- problem might seem interesting, but finding the solution is hard and sometimes we don't even know if a solution exists. Mathematicians often use the words "existence" and "uniqueness": Does a solution to the problem exist and if it does, is it unique? George Polya's How to Solve It consists of essays on how to approach problems in general (not necessarily exclusive to mathematics in my opinion). You can find an excellent summary at https://math.berkeley.edu/~gmelvin/polya.pdf.

Essentially, the advice boils down to:

1. use the defining features of the set up

2. give things/variables meaningful names

3. leverage symmetry

4. try describing one object in two different ways

5. draw a picture, flowchart to visually represent

6. ask a simpler version of the problem by removing some constraints or considering very specific cases

7. read a lot and think about problems a lot

[gzer0]

Nowadays, I utilize GPT-4's API for nearly every problem I encounter. By inputting all the relevant information and applying different prompts, I gain a clearer understanding to make informed decisions. Despite being released less than a year ago, I'm astounded (to say the least) at how integral GPT has become to my thinking process.

Prompts that I use that significantly aid the process:

  * Provide a concise definition of [specific topic or concept] and explain its key characteristics.
  * List three advantages and three disadvantages of [specific technology, method, or approach].
  * Explain the step-by-step process of [specific task or procedure] in a clear and logical manner.
  * Compare and contrast [two different approaches, methods, or models] in terms of their strengths and limitations.
  * Predict the potential impact of [emerging technology or trend] on [specific industry or domain].
  * Describe the main challenges associated with [problem or issue] and propose possible solutions.
  * Summarize the main findings and conclusions of [research paper or study] in three concise points.
  * Create a comprehensive list of resources, including books, articles, and websites, related to [specific topic].
  * Provide examples of real-world applications or use cases for [specific technology or methodology].
  * Offer insights and recommendations for optimizing [specific process or system] based on industry best practices.

[tazjin]

For cases where you get "new" information from it, what's your verification process to guard against hallucinations?

[talkingtab]

Play. We often use that word to mean "not serious" or "not work", but children's play is an effort to do exactly what you are talking about - to understand what is possible. Humans are among the most adaptive creatures known. We adapt by trying things, not being successful and then playing with possibilities. If you have anxiety/paralysis about that process then I suspect that is not self-inflicted but inflicted by other people or the institutions you participate in.

There is another factor that causes problems for many people. They don't really give a <insert-obscentity-here> for what they are doing. Bad jobs, stupid ways of doing things, senseless tasks. Just say no. :-)

And finally, we often forget how physically competent we are. Humans can run and walk for hours and hours once they get use to it. Go walk 10 miles. Or better yet run. It helps.

[ghoshbishakh]

The original post does not specify the nature of the problem. The problem might be something objective like scientific research. Or something deeply personal like an illness of a friend or family. Depending on the problem, the approach will of course be completely different.

In case of scientific research also, it depends on the situation. A PhD student's approach to a difficult problem with apparantly no solution would be and should be different from someone who does not have a deliverable. If you are a student, you need to deliver some result for a degree. So after some time it would be better to forget about a seemingly unsolvable problem and focus on a new problem which you can solve in perhaps a better way.

A senior researcher however in my opinion should persistently try to solve the harder problems. As I feel it is their job.

Coming back to different problems than scientific research, I can only think of one approach. Ask the question, how important is this problem to you and your life? If it is as important as the the well being of you, or your close ones, then you have no choice but to focus and fight to find a solution.

[intellectronica]

Flip it around: the only really interesting problems to work on are the ones where you don't know if there is a solution.

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.

[politelemon]

I feel an obvious solution many are missing is simply to ask your colleagues for help. They can either listen to your rambling or they can offer answers when ones you've thought of before or novel strange ones you had dismissed but bear rethinking. If your paralysis is due to you working alone, then your open mindedness should make your amenable to asking for help.

[hliyan]

I can attest to this. Fresh inputs are often the only way to get out of a mental feedback loop.

[fernandohur]

Assuming the context is for solving real-world problems, not textbook problems:

1. Try to solve the smallest (but similar) problem you can think of. You'll learn a lot along the way and might figure out if it is doable or not. As a reminder, just because a problem is solvable doesn't mean it's solvable at an acceptable level of cost/time/effort. Solving a similar, but smaller problem will help you estimate the feasibility of the larger problem.

2. If the problem is worth solving, it's probably affecting people who in turn have tried to solve it before and are using either approximations or imperfect solutions. Talk to them, understand what they've tried, what works and what doesn't. If the problem affects enough people It's very likely that a solution exists already, it just hasn't been generalised, productised, or automated yet.

[fallous]

Here's my general process for problem solving when operating with incomplete information.

Evaluate the severity of the problem first. This usually falls into a bell-curve with the X axis starting at "not a problem" to "armageddon." Attempt to gauge the timeliness of the problem. This tends to fall between "already happened" to "years in the future."

Comparing the severity with the timeliness will give you a good idea of the urgency of the situation, which is then compared to current priorities.

Gather the information you can given the urgency constraints that can give you the best understanding of the problem and accept that this information may necessarily be incomplete.

Recognize that many times you don't have to solve a high-urgency problem but can instead pursue a partial course of action that increases the timeliness, which reduces the urgency as well as provides you more time to gather information to reduce the unknowns.

When deciding a course of action with incomplete information you need to commit to that decision strongly, but always be looking for evidence that the decision is incorrect. Until you have such evidence, stay with your decision. If you find such evidence, re-evaluate since you have the ability to make a more informed decision now. This is generally referred to as "strong opinions, weakly held."

One thing I very much try to do when executing a plan that is based on incomplete information is to have an exit strategy. Try to make choices that give you the ability to roll back changes and restore to the previous state if things go wrong. This will give you more confidence in committing to action.

Always remember that discovering a choice you've made is incorrect is valuable because it increases your knowledge and often leads to greater understanding in an environment in which you lack sufficient information. Don't fear learning this way, it's too valuable to avoid.

[didgetmaster]

Some of the world's greatest inventions were created only after much trial and error by a very persistent person. They were often told that what they were trying to do was impossible and to just give it up. Only after they succeeded were they recognized as a genius instead of as a fool.

Today's mantra of 'fail fast' discourages the kind of steady work required to solve some problems. If a solution can't be found in a very short time, they tell you to give up. This can be beneficial in some cases, but some problems are just not easily solved.

How you deal with this, really is dependent on what kind of person you are. If you are patient and willing to stick with something over a long time, then you could create something truly unique. If you get too anxious when a quick solution eludes you, maybe go with the fail fast method.

[evanwise]

Worth pointing out that sometimes things really are impossible. If an MBA tells you something is impossible, it is probably just really hard. If a physicist tells you your idea violates conservation of energy, it is probably not worth wasting your life chasing it.

[dumpHero2]

Survivorship bias at play here. World's greatest inventors who happened to work relentlessly at something important. Although I am sure they had their own good reasons to believe in it.

[Vanclief]

1. I try to break the problem into smaller problems. 2. Pick the hardest one from those smaller problems and apply step 2 until it can't be broken into smaller pieces. 3. Once I have a "constrained" hard problem, I just try to solve it however I can.

If I solve that problem, that normally allows me to build from there, otherwise I may have to re-frame the problem. But by just starting, I get more information and ideas on how to tackle it.

[blisterpeanuts]

This is my approach as well, and I think it's generally considered a best practice in engineering, at least on the software side.

When faced with what sounds like an insurmountable,"where the heck do I even begin?" type of challenge, I like to slice it up and get the obvious bits working, just to build confidence & domain knowledge, while my brain autonomously digests the main problem.

[hinkley]

Your question is my argument against puzzle questions in interviews.

When you see a seemingly impossible question in an interview. You know there’s a trick. You’ve been handed a riddle to be solved.

When my boss hands me a seemingly impossible problem, it might actually be impossible. At best it’s a mystery, at worst an enigma, or a paradox. It’s a very different skill set to go searching for a solution that is not obvious and not found in the literature (because nobody wrote it down or they used jargon nobody else knows).

I have a coworker who says things like, “we can do anything in software” if he says it again I’m getting him a biography of Claude Shannon, because apparently he did not learn about Information Theory in school.

[geocrasher]

It's easy: Expect failure. That doesn't mean you stop. It means you stop worrying about success and just play around with the problem. Poke at it from as many different directions as you can, and keep note of what does not work. Eventually you'll either stumble onto a solution or prove that it is in fact impossible, and your experiments were a success.

[ly3xqhl8g9]

"Expect failure" sounds very motto-y. In Latin, so you can use it for your coat of arms, would be: expecto defectum. I suppose one could even operationalize it further: deploy failure, displicare defectum.

[asplake]

This. Keep probing until you’re able to form hypotheses, and keep testing those. Worst case you learn; best case, with each experiment you change something for the 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.