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

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.

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.

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

This sounds exactly how Starship is being built. And this is why the first prototype not making orbit is not "a failure" but rather another step in the path to success.

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.

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.

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.

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

I think that Good Reads version is a slight misquote. Adam said "the only difference...".

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.

Communication is key in this scenario, You've got to be explaining an under estimation as soon as you know it is.

This is more important than you think. To expand on the parent, when communicating keep in mind several extremely important goals: - you are able to organize your work. If a problem is potentially without a solution, you're likely not going to be able to hold all of that info in your brain at all times. - when you bring someone in to help, they could get all the context they need by reading the materials - emails, documents, comments, etc, that you already created and organized. They will likely not have all the context you have, but they will have information available and digested. - it helps keep stakeholders up to date on the progress and risks. Maybe you are able to just talk to your boss, but you don't want to repeat all of that each time you tell someone new. You don't want to setup a meeting just to update your stakeholders - in case you are able to solve the problem, the materials you write while solving the problem will serve as a staring point for the documentation of the feature/product

Deliver an approximate or good-enough solution to buy yourself time.

Which then immediately gets thrown into production and becomes the bedrock upon which further bad decisions are irreversibly built on every time, of course. Now the time pressure is even higher because people are actively complaining about the issues that cannot be solved with the hastily jerry rigged implementation ("should be simple right, just do..." is a bane of my existence).

This comment reminded me of something I read about laymen estimating the difficulty of technical problems. IIRC the two examples were:

a) Given a quality photograph, detect if it's of a bird.

b) For the same photograph, detect if it's taken in a national park.

The first problem may seem much easier if one does not know about EXIF geodata, assuming it's available in this scenario.

This is an inversion of the originating XKCD, which possible shows how far machine learning has come in the intervening years: https://xkcd.com/1425/

I’d start by not telling my boss it’ll take two weeks to solve a problem that might not have a solution.

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.

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

> The french quote can be traced to a translation of Asimov's Foundation

It's actually much older than that, I read it already in 19th century books; no idea when it first came out.

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

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”

Maybe re-formulate the problem from different perspectives, find the intention behind the problem, go "one step up". Find the space where "the problem" is only one of many ways to solve the intention. Doesn't always work, but sometimes.

I tell my brain there is a solution, you will figure it out, you always do. I then walk away from it but periodically return. You need to force it back to your subconscious mind that is more in touch with asking the entire universe to help you manifest a solution.

This may sound like a lot of woo but it usually works. One particularly hard problem took me eighteen months to solve. I should note that I'm stuck on a real bad bad problem right now though, been at it for nine months. It's not technical, more spiritual. I did get a solution but I am not sure I can follow through with it.

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.

Nearly for any subject I try to always think with two opposing voices: one that says there's a solution and one that says it's impossible, and I always explore both sides of the argument.

If at some point some position sounds more plausible than the other, I try to put into words why is that. Either I convince myself of some position, for example that it is impossible, or the hardness of getting convinced at one position encourages me that maybe it's the other position that's true.

Either way I don't have anxiety because either I'm confident in some direction and making progress, even if it is at proving something is impossible, or the doubt from failing to prove it is impossible makes me more confident it is possible.

Even if you're making progress at the direction you didn't prefer, you should still see it as progress, and if you're confident in one direction you see it as an indication that you can make progress.

Anyways, it's not enough to just hold a general feeling that something is impossible, you need to put it into words and see if it's truly convincing. When it's just general intuitive unspoken feeling you can't change it, but when you make it concrete, you can understand what's possible.

The two opposing voices is reminiscent of game theoretic proof methods. Terry Tao has a great answer on mathoverflow that puts it in personal terms about how he solves problems [0]:

> One specific mental image that I can communicate easily with collaborators, but not always to more general audiences, is to think of quantifiers in game theoretic terms. Do we need to show that for every epsilon there exists a delta? Then imagine that you have a bag of deltas in your hand, but you can wait until your opponent (or some malicious force of nature) produces an epsilon to bother you, at which point you can reach into your bag and find the right delta to deal with the problem. Somehow, anthropomorphising the "enemy" (as well as one's "allies") can focus one's thoughts quite well. This intuition also combines well with probabilistic methods, in which case in addition to you and the adversary, there is also a Random player who spits out mathematical quantities in a way that is neither maximally helpful nor maximally adverse to your cause, but just some randomly chosen quantity in between. The trick is then to harness this randomness to let you evade and confuse your adversary.

[0] https://mathoverflow.net/a/38882

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.

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

Zero trust, you have to unit test, run what it gives you, tell it in a separate session a co worker gave you this solution, it doesn't work but explain why.

Imagine that GPT is just another person you communicate with. When they give you new information, how do you guard against them being possibly wrong? You verify the information by other sources.

The "quality" of the wrong information you get from GPT-4 is very different from a human who is wrong. For example, I wouldn't expect a human to give me a long list of books that don't actually exist without hesitation.

Sure, but still, if you ask GPT/person "What are the best books about teaching dogs to sit?" you'd still look up each book individually, read reviews and figure out if they really are worth the time reading, before starting to purchasing the books. And you'd find out if the book exists or not as soon as you search.

So even if the "quality" is different, the way to verify the information is the same.

Both AI and humans can be wrong, but in different ways. Humans often mess up due to bias or memory slips, while AI usually stumbles due to data gaps or misunderstood context. AI misinformation isn't 'worse,' it's just different. Understanding this helps us use AI more effectively.

Googling. Just today I asked Chat-GPT (not 4) for papers or books about some topic, and it gave me five pointers. Two of them contained useful information, the rest was hallucinated.

Use the GPT4 with web browsing mode enabled or Bing Chat if you want links to real articles. Bing Chat has come a long, long ways. Impressive capabilities. Much less hallucination.

Bing chat? You mean having to use Edge, aka Chromium without any extensions? I'd sooner go to Firefox.

GPT 4 with browsing isn't quite there yet either, usually takes at least two or three attempts to not have it fail somewhere in between. Should be pretty good once they iron it out though.

https://github.com/dice2o/BingGPT

You don't need to use Edge to be able to utilize Bing Chat :)

https://github.com/sunner/ChatALL

This one let's you send to 9 models simultaneously and in parallel. Interesting the differing responses for each.

I usually tell it to add confidence score of whether it's real and to prioritize real stuff

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.

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.

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

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

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.

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.

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.

What kind if problem?

- Mathematics/physics textbook problem: can you prove it has no solution? E.g. you can start by assuming it has and then find a contradiction. That also works for finding a solution.

- Programming: can it be done by a series of pen-and-paper operations? If yes, then it has solution and you must keep on trying. Can you find an equivalence between your problem and and a well known problem? This last point is true also for math/physics.

On equating your problem with a well-known one: there are not so many new things under the sun. Try to formalize the problem statement, then you might come to conclusions of the form:

- This is equivalent to solving the traveling salesman (bad for you) - This is essentially a system of linear equations (good)

When you do this you can take advantage of all existing literature, i.e. the knowledge of smarter people.

Change the representation. Work small, simple examples by hand until you see the pattern. Try to start at the smallest simplest Most reduced example of the problem you can come up with and work your way to the next one. Once you see a pattern, try to change the representation and how you write it down invent some language for the problem it’s important parts of relationships aspects or dynamics of the problem come up with some terms are some symbols to represent those parts.

Celebrate the small wins find enjoyment in the process and motivate yourself with peptalk’s imagining how great it will be when you solve it, or how close you are. get a feel for the problem and believe that it has a solution. I just keep trying to get there, enjoy the uncertainty and the excitement of discovery.

Remember, you may be the first person to tred these paths. So don’t forget to stop to take it all in once in a while. Even if you’re not The first person to do so, you’re doing the first time you’ve been there, so still stop to take it all in because it’s important to you, and that makes it important.

If it doesn't have a solution, then find out why it doesn't and document that.

I have spent the past couple of years solving problems that, evidently, no one else is trying to solve (or else everyone else finds it easy to solve).

The evidence is that I spend a lot of time searching for error messages of which I am apparently the first recipient in the world.

I’m working with systems that are opaque and hostile to developers. I’m using platforms in ways that are very removed from the mainstream, provided by enormous companies.

I know a solution exists but what I don’t know is if a business viable solution exists.

The way I deal with it is to focus at each stage on what I do know, what I need to find out, and whether it is worth trying.

The “worth trying” part is often subjective but metrics such as revenue can help in the decision making process.

I would think about different aspects of the problem a lot. How they manifest themselves, which of them I could possibly tackle and which are beyond my comprehension at the moment. Eventually I get enough resolve to approach and make an attempt on those that seem reachable. This almost inevitably clears up just a bit of the nature of other aspects, so that after another period of contemplation you can in turn tackle on them.

So basically, look hard at the problem, chisel it a bit and back off for a moment. If you can't solve it right away it's a substantial task that has to be treated with respect. Naturally this process is poorly suited for meeting deadlines.

(assuming math-ish problems) Try to solve a simpler version of the problem. Keep making simplifying assumptions until you get something you can handle.

Often you realize that some parts of the original problem statement were adding complexity with no real benefit. And the techniques you use for the simple version are likely still relevant for the big version.

If the simplified version is still hopelessly difficult, it might be a good starting point for a counterexample/lower bound to convince yourself that the full problem is hard.

The inverse of this strategy also works well sometimes: try to solve a more general (i.e. "harder") version of the problem. Examples:

* https://math.stackexchange.com/questions/899109/problems-tha...

* https://mathoverflow.net/questions/21214/particular-problem-...

The second link has the neat particular example of showing that something is nonzero by showing that it is odd, which I quite like.

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.

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.

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

Divide and Conquer.

Break your problem into a set of smaller problems. Then partition this set of problems into tractable and intractable subsets. The definition of tractable and intractable can change over time, but must be precise and computable.

Start addressing the tractable problems and show progress. For intractable problems, research effort is required and the costs must justify benefits.

Let us say 60% of your customers are facing issue type A, 30% are facing issue type B, 10% are facing issue type C. Issue type B has a workaround/known solution whereas issue type A and C don't have obvious solutions. Instead of getting stuck with working on issue type A, you and your customers will be better off if you worked on and deployed the solution for issue type B. That is better than the status quo.

It depends on the problem. There are different approaches that I like to try:

- break the problem up into smaller parts which are easier to grasp, plus some framework to combine the individual parts. If this is possible, you might be able to solve all easier parts and thus the mother problem

- start with a problem that looks like the original one but which is easier. Once you have been able to solve it, you can clean up space in your head to focus on the step from the easy problem towards the final one. Also, during the process you have probably gained some experience and understanding of the mother problem

- just start with the problem without expecting to solve it. Then do something else. E.g. have a good night sleep, do some household chore etc. When you're not focusing on the problem, your brains continue to work on it so when you look at the problem again the next day, it can well be that your are able to link parts together that you were overlooking the day before

- talk about the problem with someone else. It could be of course that the other person has some hints that you didn't think about. But the main thing is that while talking and explaining the problem, you often get a better understanding of the problem yourself as well.

The title and the first question are two different things.

If the "anxiety/paralysis" is the real issue here, then it is a completely different topic that probably needs external help.

For a "problem you are not sure has a solution", if it's related to job/technology, I search for a workaround (if applicable which, most of the times, it is).

Definitely know what you mean. I often end up feeling anxious about things I’m working on, feeling like they might not matter even if I solve them, or that I might not be able to solve them.

So, at least for me, there are 2 sources of this anxiety:

1. Does it even make sense to solve this? - Best thing is to try to validate the problem. Find people to talk to, get feedback. Or think about alternatives and constraints. Every now and then, I start feeling like “what I work on makes no sense, I should just abandon it”. Only to then analyse it, walk through the different options and decisions and realise I’ve done this decision making exercise previously when starting the project and I still agree with the outcome. But I guess it’s good to recheck the assumptions every now and then.

2. Can I solve the problem? - I often get discouraged when I realise things are a lot more difficult than expected and I start to doubt myself. Usually results in me procrastinating and taking a break. Things that help me are: taking a deep breath, doing some searching for similar problems, breaking the problem down into smaller tasks, finding a smaller, yet similar problem to address first. Again, talking to people and reaching out for help can be great. People are often happy and flattered when you come to them with well-formed questions and acknowledge them as someone you consider an expert in a field.

Hope this helps. In general, when working on very hard problems that might not be solvable, try and break them down, find the riskiest piece that seems solvable, and try to tackle it. If you fail, at least you fail fast and you can rinse and repeat :)

Not all problems are solvable, not all are worth solving. Not all need to solved fully and not all of those even need to be done automatically.

You often don't need to solve the problem to provide some business benefit.

So. Can you break it down at all? Is there some part of it that has a business benefit?

Can you do it manually, what's the trade-off of time and cost? Can you document it to make it a manual task for a lower level employee?

If not worth doing manually, often it's good to do some of it manually a few times so you get an idea of what's the same / different for different situations.

Can you automate the same parts?

Can you find a way to deal with some cases where it differs?

Can you now solve any of the remaining pieces?

This process can often be done with manual scripts, I forget the right term, where you create a script that prints out what the user should do and asks them to press enter when they've done it. You can then automate parts of it over time.

This kind of process helps have a useful output at all stages whenever a higher priority problem comes along. It's also easier to come back to it in a few months.

And if not, if you can't even do it manually it pushes it more towards unsolveable.

For problems that don't fit this kind of process, I often leave the problem to settle in my mind and talk it through while walking somewhere. Explain to imaginary people what we're doing what we can't do etc. Kind of like rubber duck debugging.

Prototypes, just trying can be good.

Most of all if you can, get an idea of the value of solving it and the value of your time. That helps put an upper bound on how long you should ever spend on it. A problem that causes a £10/mo extra aws charge a month is fundamentally not worth solving for almost any developer salary.

Finally, it's ok. It's ok if the problem can't be solved. It's ok if it's not worth it. It's ok if someone else sees the answer easily.

Come up with a list of potential approaches, order them by roughly how promising you think they are and then try them all in that order. Obviously limit this by how much time/energy you can offer it somehow.

When you're done, see if you can think of more approaches. If you can't, you probably can't solve this problem and it's time to call it a day.

But that's ok, because there's almost certainly some higher level goal you're aiming to achieve. So think about other ways that you could achieve that without solving your original problem. Maybe there's a way to solve a similar problem that has looser constraints which is easier.

The simple way to solve the problem, of course, is to not know it's unsolvable. Then work at it, tirelessly, until you come up with the solution.

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

The best part of that story is this quote from Dantzig himself, IMO:

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

Recently I just started asking ChatGPT.

It does a very good job guiding me in areas where I'm less familiar.

That's assuming we're talking about technical problems. For non-technical problems I'd reach out to friends (or even better - a therapist). But asking on HN and/or Reddit might be a good idea too, depending on the context.

I see multiple ways of what you are experiencing.

* There is no known solution or path to the solution

  * There might be none
  * There might be one
  * There might be multiple
  * These might be approximations
  * The solution will be so complex, it will not be sustainable

All these are possible ways of having no solution and lots of real world applications fall into the area of having lots of solutions, but sometimes it's just not sustainable. Theoretical research of course is different.

I usually just try to solve it with my current knowledge, as practical as i can (implementing it). Even if i cant solve it that way, i will have learned something and i can try again another time or using another approach. Looking for similar topics and approaches helps. Mind-Map thinking can help broadening the field and see adjacent topics which help finding a solution. Very often the knowledge from other fields help me solve something i could not without the broader knowledge.

Further option

    * You might be bought-in, eg emotionally, to a situation that prevents solution

For example, you used something in the project you made, and that part needs to be ditched; or maybe you're not working in that team; or you consider yourself the best person to do something when really someone else is and your pride is getting in the way ... et cetera.

I have this quite often (most of the stuff my company has not been done before, or at least not properly/usable; for good or for bad) and I get this paralysis sometimes (more in the past than I do now). My mental way of solving it, is to imagine a product that does something similar to the actual 'perfect' solution, but does it far more crappy. Simply put; I make a shitty prototype first (with the thought that the perfect thing will come 'some time' after) that is not perfect. Often will transpire that this shitty prototype is as close to what we set out to do as we can get without unrealistic spending and effort and we leave it at that (we refactor it before launch though). This takes away my anxiety about 'finally doing the perfect' thing.

It would help quite a bit if you were able to give a good example.

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

I know exactly what you're talking about I think. My problems are solved by code such that code will have something to do with the approach. With that in mind I tend to write lots of little one off programs to test a particular idea or see if a particular phenomenon exists in a set for example. In building these I'll version them in the filename ( XXX_Test_V1.sh ) such that I can compare runs and later maybe chain some runs together.

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

First, make sure you understand the problem. Look at some particular examples of your problem where the solution is clear, understand the components of the problem. When your have a more or less complete image of the problem in your head, make a list of potential solutions/approaches. Think about the list that you made until one particular approach or solution appears to be the most fruitful and then pursue that. If/when you get stuck, go back to earlier steps of this process.

I have just started to read another his book and I'm sure that George Polya's ideas is the best source for topicstarter. The second-best I can recommend is TRIZ:

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

This is quite common in scientific research. The typical algorithm I follow is to reframe the problem in the language of different fields and see whether there is a more useful way of tackling it in that framework. There are always some leaks in the abstraction/translation but often by reframing the problem you find a good-enough solution.

A thing I've often fantasized about is some sort of mega-conference where top luminaries from every academic field get together and hammer out a global namespace of jargon, resolving all collisions so that no longer can a term mean eight different things in eight different fields.

Imagine the global boost in productivity and knowledge-sharing...

I fantasize about this sometimes for scientific purposes. Part of the challenge is how to keep the barrier to entry low enough that people stay excited and creative, because the opposite is the world of regulated industries where your way of thinking is heavily influenced by the legal framework. Periodic synchronization helps and the best I have seen in person at the Gordon Research Conferences (GRC) since these tend to be narrow enough to have consensus but still broad enough to get a little bit of perspective

Often unsolvable problems can be decomposed into a set of solvable problems and hopefully just one or a few unsolvable problems.

By narrowing the unsolvable problem it can help to communicate the issue to others (e.g customers or management) or help to find a solution. If that fails it provides some solvable problems to work on. Often solutions, workarounds, or compromises become evident over time.

I stare at the problem for hours until it's suddenly dark outside, then if necessary I repeat the following day and the next until I see a solution. I mean this in a quite literal way, and it's in no way not meant as a joke answer.

Surprisingly often this method works.

I think you don't provide enough information for anybody to give you good advice.

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.

Without knowing the problem or context, I will take this on the basis of a "coding problem" where I may be tasked to create a piece of software/code/webapp to solve the needs. I take things a bit differently to most, I find the best way (for me) is to start tackling the problem with the tools I have, and then when I get stuck, see what I can do to fix it. I don't believe any problems I face have no solution, its just how long it takes/much it costs.

This may not be helpful, but I think about it really hard for a long time :-) No joke, I've spent weeks thinking about a single problem whenever I had downtime. It works for me, but I don't think a lot of people want to think about something that much.

I focus more on the outcome I would be okay with and my progression towards it over the problem. As I learn more, I can get a better sense of what the outcome should be.

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.

Keep smashing my head against the wall until I make progress. Accept that it can take days to get an in.

As a general answer I like to take sort of "5 whys" approach. Try to list all the contexts and constraints to the problem so that I can see potential conflicting/circular dependencies. This sometimes results in conflict identification something like "X is blocked by Y, but Y is blocked by Z". Maybe there is additional "Z is blocked by X", maybe it results in problem restatement to "solve Z".

When I have an open-ended problem without an obvious solution, I often start by systematically questioning all of my assumptions. Why do I believe something is true? We often smuggle in beliefs about the problem that are of questionable provenance or are not actually true on careful inspection.

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.

> How do you battle against (self-inflicted) anxiety/paralysis when you are attempting to tackle a problem you are not sure has a solution?

Prove that a solution does not exist. This removes any form of doubt. It guarantees that no one else can find a solution either. Attempting to prove it may also help to more clearly understand what is required and what isn't, which may simplify the problem.

I'm aware that I could fail to find a solution even if there is one, but I don't let that stop me exploring the space and learning as I do. The fact that there might not be a solution doesn't change anything.

Ask somebody from a different branch of work, who has very bad understanding of that problem.

They often have a bizzare idea somehow leading to the right track. They solve it in a completely different way or know that the problem does not matter to begin with.

Its like rubber duck programming with a smart duck.

I once had some weird data problem and complained about it to a sales guy. He called the customer to not enter certain things,and the problem was gone.

Every problem has a solution, otherwise it would not be a problem. If you get stuck, reframe the problem. Ask yourself why, what, where, whom.. in other words, figure out the true nature of the problem and why it exists. Is it really a problem or did your expectations for the result changed? There is no single answer here but keep asking questions and you will figure it out eventually.

Many problems provably don't have a solution. OP didn't specify a problem domain but in both maths and computing the possibility that what you are trying to achieve is mathematically impossible is a real one, and distinguishing the absence of a solution from your own lack of ability to find the solution that does exist is a real challenge with no easy answer.

Real-life problems always have a solution, but sometimes it isn't a technical one. Or a technical solutions exist, but is too expensive. To take your math example, e(x) = 0 have no solution, but in real life, taking x = -100 could be close enough for your purpose.

In real life problems often have multiple solutions and we don't like some of them, possibly the simplest ones. This is much like exceedingly expensive solutions to technical problems. In my experience customers faced with a costly solution reframe their problem and accept to do their business a different way. Their customers won't notice.

We lost the secret key for this bitcoin in the incinerator, can we get the key back?

That problem has neither a theoretical nor a practical solution.

There is a human one though: accept the loss and add processes to not repeat the mistake.

That what I was talking about in my first sentence, but my post wasn't clear, I admit. Thank you, it helped me clarify.

It's not clear that _every_ problem has a solution.

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.

It may sound profound, but "Just do it!" Don't look too far ahead and take the first step.

Involving others could help. See if they have a solution, if not, maybe not to worry? I wonder what problem you speak of.

I find the principles of Dynamic Programming very helpful in these situations.

  - separate the problem into aspects that are well defined
  - if aspects are not well defined, assume the most common case and revisit them later
  - break as much of it as you can down into smaller problems that you can solve
  - revisit assumptions, can you "cheat" by solving for a subset of the domain?
  - can you transform sub-problems into something that is more tractable?
  - resist the temptation to come up with a generalized solution where a more specific one would suffice
  - try to minimize what you're actually solving and how much work needs to be done
    what's the stupidest, simplest thing that could possibly work?

That being said, it might help if you shared what you're trying to solve ;)

i feel like this is just the research process. My solution is to just try something that seems relevant. Soon you will realise it may not work because X. but maybe Y will work. Then you keep going, learning more about the area, the data, whatever. Stop when it works, or you have convinced yourself it wont. This is one of the reasons I think research code is always so trash, rarely did the researchers know where it was going to go at the start. And thats ok. Refactoring for production only happens well into the future.

my advice is to do something without worrying that it might not be the right thing.

I continue as if there is a solution, but when I see an avenue suggesting it doesn't have a solution, I try to take that. Generally the info from trying to show the problem is unsolvable will help understand the problem better anyway.

Every problem has a solution. When it is hard take a step back and return to the problem. Eventually you will find a solution or a quick hack

Don't aim for the perfect/absolute solution. Sometimes a solution that solves a chunk of the problem (big or small) is just enough. Try to break the problem down, see where you can start, where you are going to need help and what will be for later.

Just accept that in many scenarios all you can hope for is to get close to a solution.

Depending on the domain you work in, close may be perfectly ok.

Then walk away knowing you did your best.

This sounds easier than it actually is, particularly if you have an obsessive compulsive personality.

It took me years to "let go".

What worked for me:

1) Experience. I am much better at prioritizing tasks today than when I was younger and I can focus on things that matter instead of going into rabbit holes with stuff that doesn't.

2) Running every day at lunch break and avoiding big meals. I believe my mind works better when I return to my desk, I'm awake and energized. I have a small snack usually fruits but definitely no carbs or refined sugar.

3) Having a "manual" hobbie. I got into film photography and directed my obsession to it. There's something about the almost totally manual process of film photography that has a calming effect on me. I know people that described a similar effect with painting, analog music production and writing.

4) Walk away. When I'm working on an issue and get stuck I say F this and leave, then come back to it later that day or even days later. It's almost like it is a totally different problem and usually appears much easier when you see it after a break. Call it a day and go home, go for a walk or work on other stuff.

I assume that there is a solution, that the solution is already known, and that it's my approach that prevents me from seeing it.

Sometimes “there is no solution to this” is the solution to the problem. Often it may: “the solution to this is beyond us/me” - which is an equally suitable solution.

I call my difficult experimental software projects names like Calm and Peace. Just looking at those words helps with any anxiety.

Reduce the problem to a simpler one you know how to solve.

Taking long breaks and let the mind wander. Learn from failures. Understand the problem and possibly rethink what you are trying to achieve.

I just let it roll around in the back of my mind for a few days or even weeks. Eventually some new perspective will present it's self. Something will unlock it.

That doesn’t work very well when you’re an employee and the project manager asks: “when it will be finished?”

Talking to others about the problem and or the situation will help both in a rubberducky way and as the saying goes a problem shared is a problem halved.

Perhaps you will find inspiration in Dave Snowden's framework "Cynefin"

I focus on the process.

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.

I find assuming that there IS a solution helps focus the mind.

Relax the problem - remove one constraint and try again.

Deconstruct and aim to solve a lesser subproblem first.

Divide and conquer.

Break the problem up into pieces and solve the pieces.

Wow, I can’t believe this is at the bottom of the comments. This is exactly the approach regardless of whether the problem is at work or at home.

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

And if you think it's atomized enough, yet you still have problems then it's not atomized enough. You might have to get deep into first premises and axiom-land.

I've been wanting to work on networking for multiplayer online browser games (but not io style more traditional game style) but it just seems like a ludicrously challenging problem for the kinds of games I want to make. Some are real-time, some are turn-based, all would definitely want an effective system for handling disconnects and latency and data persistence.

Trying to work through these is like far harder than any "hard" problem I've seen on leetcode. It actually makes me feel like sick to my stomach when I spend 12 hours on it without making a lot of progress

Context matters. Why you're there matters.

In a business context, there's always an itching problem or a potential value creation and you can frame it in those terms and timebox it (drop it after X time working on it and write about the results of your tests).

As much as possible, you should have a plan B that is workable even if suboptimal.

On the "problem solving itself". Just break down the problem as much as possible to ensure you're slowly removing risk and learning early if there's a problem. That helps with the paralysis since tasks should feel tryable.

If you can't even think about the problem then you clearly don't know enough about the domain and some separate theory and practice should help.

On problems that might not have a solution? Not much chance with the current (chat)gpt. There are many technical problems that have currently no solution and chatgpt will just keep repeating, over and over again, ways to attack the problem. Helpful, maybe, at first, but after 2-3 prompts, it'll just be more of the same as it cannot help solving it further.

Change the way you perceive the problem, see the solution as the opposite of the problem.