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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

"This problem is unsolvable" or "Approaches X, Y and Z are not solutions to this problem" are perfectly valid and useful contributions to science and society in general.

Or in the words of Thomas Edison: “I have not failed. I've just found 10,000 ways that won't work.”

The attainability of a solution is the product of a well-defined problem. So focus less on the "have I solved this" and focus more on the "have I made useful progress in defining the problem".

If you're talking about dealing with the stress of a problem unanswered, my counter-intuitive go-to strategy is to think of the worst possible outcomes of me not coming up with a solution. When I think of clear consequences and realize I can deal with them (even if they are unpleasant) and it takes the edge off so I can think more clearly. The consequences are rarely world-ending, after all.

As for strategies for finding solutions for complex/potentially unsolvable problems:

- Try to sketch it out. When thinking about complex problems, we tend to spiral and sometimes they seem too abstract when contained in our heads, putting them to paper makes them more comprehensible and less overwhelming. Even if you can't sketch out the whole problem, better understanding parts of it makes it easier to understand the whole

- Explain it to someone else. Aside from the benefit of the rubber duck approach, talking it out with people with different backgrounds and cognitive processes helps you look at it differently. Maybe you're a deep narrow thinker and someone who is a shallow wide thinker will help you se the whole picture or vice versa

- Can you break it up into smaller components? If yes, great! Even if you don't solve all the components, you'll still end up with a smaller problem then you started with. And solving some parts of it may change it all together.

- Review the context and everything surrounding the problem. My colleague recently mentioned that when they get a ticket for an issue, they often end up fixing or upgrading a completely different part of the system than the one where issue occurs, and that issue just falls into place

Paraphrasing Dune, fear is the mind-killer. It doesn't help to search for alternate points of views or approaches as you are fixed in one possible outcome.

Learning more about the problem and the system where it happens may give a different perspective, a broader point of view, another attack angle. Or, in the worst case, realize that is not that critical, that it can be redefined, or adapt around it.

Oh yeah, these are basically my job. I have a few ways:

1. Set a time budget and be willing to walk away if I'm not making progress. Sometimes "yep, sucks, but is what it is" is the answer.

2. If it looks impossible, be more willing than usual to reframe it. If it's a detail problem, zoom out and see if the bigger picture offers you a way around. If it's a big picture problem, challenge the assumptions. If it's still impossible, see 1.

3. Involve other people with other points of view early in the process. There are a bunch of different teams that work in sync to get anything out the door at my company. Getting any difficult problem solved will usually involve understanding the work of at least two of them. The challenge with potentially unsolveable problems is knowing which two.

4. I cannot reiterate number 1 enough. Sometimes a problem might have a solution, but I just have to be ok with the fact that I'm not going to be the one to find it. Maybe the next problem I tackle will present me with a nicely reframed version of this problem for me to go back and take on.

Are you talking about a technical problem, or a conceptual problem?

By technical, I mean something like "The service keeps crashing roughly once a week and we can't figure it out."

By conceptual, something like "How do I hire the best engineers within my tiny budget?" or "How do we get SOC2 certification even though we do this or that poorly?"

In either case, I always start with building an understanding of the problem. Gather what you do know about it. Write down why it is hard. Note any contradictions. Note things you don't know, such as terminology, concepts, or data that is not available.

Next, research the things you don't know. Look up the terminology. Read up on the concepts. See what you need to do to get the data. At this point, you don't need perfect answers. Anything that improves your knowledge and understanding is a step in the right direction.

At this point you should be able to talk about the problem in clear terms. It should be clear what you know and what you don't know. Tackle the unknowns now. Take steps to make them known. Read. Talk to people. Observe.

At some point you might run into contradictions. Think long and hard if they are really contradictions, or if you are making some assumptions incorrectly which are leading to a contradiction. What if you change some assumptions? Does the contradiction go away?

If the contradictions seem firm, see if you can redefine the problem ina different way that removes the contradiction. Solving this other problem might not solve the original problem, but it might make the situation better. It might mitigate the problem.

This is not a straight path. It's applying the learning loop iteratively. Assess where you are. Decide on a next step to change something. Take those steps. Repeat.

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.

I have taken on intractable problems and succeeded in finding novel solutions to them (with a team) Here's some advice.

Don't give up before at least you:

1. Prototype many solutions, and identify their "dead ends" through engagement with reality.

2. Share your progress as widely as you can - If at a company, share your progress internally once you reach a dead end / challenge you can't overcome. "Many minds make light work". Your challenge might not be the same as a colleague or leader has encountered before, but it may be similar in some way, and there may be a smaller piece of the puzzle that they have solved before. Have faith that creative solutions you could never have anticipated at first most likely will emerge, but maybe not first from your own mind. If a public project, share as widely as you can. When sharing, skip to the dead-end part quickly so you can spark the minds of your audience and engage them in the search for solutions.

3. Use true "design thinking" which is abductive reasoning and reframing. For more on what exactly that is, and how to do it, I recommend the writing of Kees Dorst in his book "Frame Innovation". "Universal Traveler" is another good resource.

https://www.amazon.com/Frame-Innovation-Create-Thinking-Desi...

https://www.amazon.com/Universal-Traveler-Soft-Systems-Creat...

Here's a good video of a talk by Kees Dorst that can help you understand what Reframing is: https://www.youtube.com/watch?v=j60jMV00kfk

I had this problem near the end of my PhD (physics).

Because of a sad conjecture of circumstances I ended up having a problem to resolve quickly. The more I was thinking about it, the harder it looked.

I then went to some people who were also physicists (not necessarily in my specialty) to discuss it, and see how it goes. It was confirmed that the problem was indeed hard.

So I did the only think which made sense in that context: I simplified it. And was crossing fingers to still have a more or less working model, with known limitations.

Which ended up not being that easy, but was ok-ish - and solvable.

I then want for dinner with a friend, and by main course she casually suggested a completely different approach. It flipped my depressed world around.

So to summarize the advices: see if the problem is really hard, then discuss with clever people to see if they feel the same, then simplify. Or take a few steps back and consider looking at it though a completely different perspective.

Good luck!

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

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

Will probably get down voted or ridiculed. There are many engineers/scientists here how will give the logic ways (divide and conquer, research etc).

But here are some non logical ways: - reframing - ignoring/delaying - accepting - praying - delegating

Or what the stoic/religion used to say

God, grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference.

P.s I ain't religious or superstition but there is some wisdom in those teachings.

Now in the context of a project if you really can't find any solution, then document and communicate your findings until the budget runs out..

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

An unsolvable problem in personal life is not a problem, but rather a condition. It is an experience that a person must spend time learning how to work with/through/around or how to accommodate.

If the challenge is something work related (i.e. I do a lot of math) then I timebox it. My journal, status report, and other docs will read upon failure: "I spent X hours reviewing Y problem. I assessed A, B, and C. Their shortcomings were Yada Yada Yada."

If the challenge is relationship related, it's dicier. More information would be needed.

Something is driving your anxiety. Pinpoint that, and a solution will probably present itself. It might be a general fear of failure, anxiousness about working on the wrong thing, more immediate concerns about the problem being necessary for a job and food, .... All of those have different solutions.

One slightly more generic tip is that your task isn't to to solve the maybe unsolvable thing; it's to do a number of sub-tasks, learn more about it, communicate expectations to those who care, still schedule other important bits of your life despite a workload of unknowable magnitude, work on any essential backup plans, and so on. You have intermediate thoughts and actions between where you are and where you want to be. Focus there, and the fact that you're working on solvable problems might help.

A tangentially related idea -- math students often mistakenly assume the point of the homework is to figure out how to get it right. Rather, it's an opportunity to think through all the ways you can get it wrong and ingrain those so that in the future the right path forward is obvious. Failing to quickly solve the problem is the express point of the activity, and approaching the homework from the perspective of figuring out how to learn from it rather that how to get full marks tends to overcome a lot of mental hurdles and give you that latter benefit as a side effect. You're similarly, at least in the very near term, not actually working on getting the final solution; you're working on learning about the problem.

I could argue that most tasks can be accomplished, but they may not be worth pursuing due to the cost and effort involved. It is astonishing to see how many global issues are political rather than technical, with groups often opposing or preventing the resolution or improvement of the problem.

Based on my life experience, I have learned that small actions can lead to significant outcomes, whereas starting with grand endeavors often leads to mental stagnation and lack of progress.

For instance, let's consider the challenge of addressing climate change and global warming. This is a complex issue composed of numerous interconnected problems. It becomes challenging to determine where to start, which aspect to tackle first, and from which angle to approach it. However, if we narrow our focus to a smaller component, such as plastics recycling, we gain more clarity. We can explore existing initiatives like the cleanup of the Pacific's floating garbage patch or the utilization of otherwise unrecyclable plastics in making blacktop pavement. This narrowed focus provides us with a direction to follow.

If we want to address emissions, a core aspect of combating global warming, the best technical approach would likely involve improving batteries that don't rely on rare metals. I've heard of advancements in saline-based and bacteria-grown batteries. By restricting the scope to batteries, we can identify specific areas to investigate. By avoiding broad and vague objectives, individuals can offer recommendations, share knowledge, and contribute effectively to the cause. If we remain with a large and vague goal it's very hard to make any progress at all.

I've found that the best solution for anxiety/paralysis in work is to come up with a small number of next steps.

You can always come up with a list of 3-5 next steps that seem pretty reasonable, and that you can reliably execute. That's the key, because if they're unreasonable or you're not sure of being able to execute them then they'll continue to produce anxiety/paralysis. But these steps aren't solving the whole problem, they're just progress towards it.

Any single step might be to find 5 relevant papers, to read the papers, to send e-mails to 5 people who might have ideas, to make a list of all the things you know you know and all the things you know you don't know, to spend 60 minutes writing free-association brainstorming, to test out 3 different solutions, and so forth. It's all going to depend on your situation.

But the point is that you can always come up with bite-sized tasks and then execute on them. And when you can't, the task is always to start going around to other people and asking them for help.

And of course some things don't have current solutions, which you need to accept to. Always look to identify the point where, after researching and reaching out to people and gathering a reasonable amount information, whether it makes sense to continue or to move on to something else entirely.

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

A classic guide is How to Solve it, from Polya

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

I know what you're talking about. For me, it was a show-stopper. I felt destroyed. Yet, here I am! That's the most important thing for you right now-- keep the problem in perspective. Hard times pass. This is the best news I can give you.

- Not all problems need to be solved.

- People can relate to your struggle and may be willing to share time with you to think about your problems (me included) if it would help

- Take a break. Go outdoors, into nature, for an extended period of time. Focus on the present, not your work.

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.

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

One exercise that I find helpful is...

Finding what the components of $Thing will do, where else they may be useful, and being critical on if they're needed.

Sometimes you find that it's not as big as anticipated, there's existing work, or the idea just doesn't hold water.

In general, it helps to break the problem down. Trying to bite the whole thing at once is overwhelming

Sometimes I find that if I do 20% of this, it fixes a much bigger problem than what I was even looking at

This may only suit situations where there is a clear starting and ending point, but I tend to think of things in terms of graphs. I'm at point A, I want to get to point B. If I take both small steps forward from A and backwards from B, I end up with a smaller problem. If I can repeat this numerous times (whether practically or merely in terms of thinking things through) I can end up with a smaller problem to which a solution is more obvious.

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.

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.

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.

    - Experiment as much as possible
    - Keep your feedback loop as short as possible between reading and doing
    - Visualize things (debug outputs, scratchpad of short lived diagrams, etc.)
    - When possible, envision what the finish line looks like and go backwards from there

The last bullet is especially useful for building tools or APIs where you can start with using your tool / API as if it does exist exactly how you want it in a best case scenario and work backwards to implement the solution you want. Break down the steps along the way.

I think with time comes desensitization to that initial feeling. It never really goes away, but as you slowly solve more and more problems self assurance slowly overrides that anxiety. One thing that really helps me is to break down a problem and its abstractions. It's so much easier to start with the more "obvious" or higher level facts, and slowly chip your way into the center.

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.

Oh god, I describe grad research as a series of existential crises.

"Is this work worth anything?"

"Am I wrong?"

"Does this path just lead to a giant brick wall?"

I find there are a couple of tips that will keep you sane when tackling problems like this:

- Don't try to solve the problem at first. Spend more time than you think you should characterizing it, and describing how you'd know you'd reach a solution

- you will lose motivation and start to doubt yourself if you dont achieve small, conclusive milestones. Embark on a problem, set an ambitious deadline, and if you haven't hit your mark, divide it up again, start with the most doable segment and repeat.

- don't take shortcuts. This will only feed the doubt you already have. The biggest antidote for the existential crises I describe is trusting yourself. That becomes easier when you convince yourself of your methodology before you embark on a problem. Shortcuts lead to wobbly assumptions which undermine conclusiveness and just makes all your work feel like it rests on a foundation of sand and regrets.

Pair with ChatGPT 4 to set up the project design.

I try to give as much context as possible. Stating goals and risks of the project. The more info you give it, the better it does at helping you. Around 500 words for an initial prompt gets good results.

Break down the project into parts and take on the most risky/uncertain part first.

As you work through the design, continue to refine the ChatGPT conversation by giving it more info. Keeping around 200 words is good. New articles can be summarized to get it up to speed on post 2021 info. Blog posts can also be chunked out and passed through to give it more info about the problem.

When the plan seems good enough, code through the steps to create the solution. Keeping things realistic and making some slow but steady progress is better than hammering it all out in a day. Discipline over passion.

I used it for a recent project and it completely exceeded my expectations. Not trying to hook onto the current AI bandwagon, it just brought me to solutions I would have never gotten to on my own.

It is the dark side of the engineer's mindset. The engineer thinks of neat problems and solutions.

However, that works only when you're dealing with certain types of contexts.

Many things can only be "improved", "managed" and "satisficed". For example, for many a politician, social stability, keeping the economic system going, maintaining peace can be considered "success".

Reading the biographies of people from different professions, and understanding their thinking seems to have helped me.

Another thing viewpoint is to see everything as a process, that just keeps running and evolving. Usually there is never a final solution to things. What's considered a "solved" problem pops up again in the future in some other form. Many problems are highly contextual, dependent on time/place. When the environment changes, the so-called "solution" no longer works.

Such flexibility of thought, that of questioning the limited paradigm of problem/solution may help as well.

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

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.

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.

Most problems I tackle by breaking them down to the smallest possible problem and then re-build from there.

Failing fast at a smaller problem is a lot easier (which is what my last set of difficult problems ended up failing at) ... turns out applying a LUT to a camera stream on Android is a harder problem than expected if you want good performance.

There are a number of ways you can approach any problem. A lot depends on the area you are talking about but you haven't provided anything to narrow the scope.

For example, Logic Mathematical Inference and a few other areas have formal methods which you can use to identify properties which can then be used towards or against proving something.

Computation for example has System's Properties that are required (such as determinism, time invariance, and step), and certain problems are derived from that which dictate some of the fundamental limits of computation.

When you know what the limits are, you know when you start pushing up against impossible problems.

Sometimes its useful to think of impossible problems as possible, and try to build a bridge, but these often require significant background knowledge and experience to avoid circular thinking of self reference.

I look on things from a game theory perspective. Is worrying about the problem helping you to solve it? Usually the answer is no, but what does help instead? I find that bisecting the issues involved is a good start. It's practically impossible to control for many different variables all at once. And you can't control what you cannot measure, so adding better means of measurement is good too. Adding extra logging of information to your system for example.

Also sometimes the problem that needs resolution isn't what you think at the outset, so keep an open mind. Maybe your implicit assumptions are at fault so you may need to go back several steps to identify and validate those first.

Indeed, the 'solution' may be to do nothing at all but rather to think about the world in a new way. The 'problem' to be solved might then disappear like mist.

Do you HAVE to tackle it?

Is it your idea, to tackle it or is someone else pushing for the problem to be fixed?

Is there anyone who knows for sure if it can be done or not?

Does it sound reasonable, within the known laws of physics/engineering that the problem is solvable?

Is that problem that unique that you can't just google it?

Make a list of all the possible attempts to solve it; ask all parties involved if they have other ideas or suggestions, and then time box each one of them.

Then start attempting each option.

If it takes you longer, document what you tried and either move on or ask someone else if it's worth it to continue that approach.

For the anxiety:

Why are you anxious about? In the worst case scenario where the problem is not solvable, what does that mean to you? Are you anxious you won't do it fast enough? Or you won't do it in the best way? Or that you're not capable to do it and someone else is capable of doing it?

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.

First and foremost - suspend any disbelief about whether you can solve it. This is hugely important. If it has a solution and you are going to be able to solve it, then it needs your full undivided attention and focus and motivation in order to make the best progress. The possibility that it doesn't have a solution and/or you aren't able to find one is the pathological case - you should only be concerned about the successful strategy and not be spending time on the pathological one. Secondly, be aware that difficult problems which haven't already been solved are unsolved for a reason. Be willing to be patient and dedicated to a long term investment of energy and time on your part to work on it

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.

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.

Team control and coordination is incredibly important when you don’t know if you can solve a problem. Inherently, if you don’t know if there’s a solution for your problem, your research will be very wide and your teams ability to adapt quickly to new directions is paramount.

As the leader, you may need to shut down directions of inquiry often. Every situation where “I wish I had pulled the plug on that sooner…” wasted time and effort.

Then you have to be willing to pull the plug for good. Whether you’re an employee or an external advisor, it’s always difficult to justify time and expense with no solution, but wasted/higher time and expense is worse.

This also applies to the individual, you still have to fight your own internal desire to push something to conclusion.

I work in fields where we usually deal with projects where we are not sure has a solution. This includes computer security, system programming, and research. I am in a management role now but have worked in all positions of the company, many times simultaneuously.

First, it is important that your customer and/or team know that you are in that problem context. If you are alone there is a big issue and you should communicate this immediately. There is a saying (Knuth?) about how to differente between an exercise or research problem: if you can solve it it is an exercise, if you can't it is a research problem.

Anxiety probably comes from a mismatch between the complexity of the problem you have in front of you and the expectations others have on you.

I take a huge project that could takes weeks or months. And try to break down the task into 3 pieces for delivery.

Then I take each piece to work on and daily make a list of 3-5 tasks i feel I could complete in the day towards the overall goal. Sometimes task #1 is super simple, eg put name on top of paperwork today, or cleanup stale files, etc. But the goal is to always be able to say I completed a task towards the overall current piece of the whole project I'm building.

The stress is still there but everyday I can say ... See how far you've come, little by little it's coming together; the "process" is reassuring.

Keep reviewing the overall project plan, and biting off little pieces. It helps to manage the anxiety in this way.

This situation used to be called neurosis. A person faces some hard problem, death would be the paradigmatic one, and unable to come up with a real solution, adopts some stereotyted behaviour of avoidance or denial to cope.

If it is unsolvable, the only strategy is to learn to live with it. Or of it's "just" very hard, you need to find dignity in fighting and losing. You might even win, but it's more difficult if you're anxious.

Also consider that concern and guilt are weapons that some organizations use to involve people in their agendas. Persons that struggle to have a minimally functional life feel as if it's their responsability to save the world. Sometimes the answer is: fuck the planet and live a little.

In the face of such problems, it is difficult to draw conclusions directly, and the solution to some things is often found in the process of doing.

If you're going to solve something like this, then a better way is to find the right way to do it first, but often this correct way is only discovered in the process of doing it.

Haha, it's like a paradox, if you don't do this then you can't find a solution, and as a result, this thing can't be done, and if you do it, then you will face an uncertainty.

So, you need to keep trying and trying and making mistakes, and then make adjustments, get closer to the unknown right direction, and finding the right direction is not a one-time achievement.

Divide and conquer.

Break the problem up into pieces and solve the pieces.

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.

Legendary maker Jimmy DiResta once mentioned in the Making It podcast (which I can recommend by the way!) how his process was with an example that I really liked.

He had gotten some new heavy machine, some 400 pound stuff, that he needed to put down in the basement.

He had no idea how he'd get it down the stairs, but he started pushing it closer, since that got the problem closer to a solution. He'd figure the stairs later, once the machine was on the edge.

It's simple, but I found it insightful.

When I'm faced with a problem and am not sure how to solve it or if it's actually solvable, I think of how a solution would look like and start making small steps in that direction, hoping to get elucidated later on :-)

You will be sometimes wrong and sometimes right. So don’t punish yourself when you are not sure.

Always be transparent over how confident you are in your analysis and what will be the consequences if you are wrong.

Try to always focus on the practical implications of what you are analyzing.

Always keep in mind what are you trying to prove/disprove. If you to dismiss a business idea for example, you do not need to analyze every possible aspect of you can rule out the opportunity based on napkin calculations.

I worked with pricing ML models for some time, and if a problem has a 40% irreducible error rate you shouldn’t account for uncertainties that sum up to 0.3% of it.

Try to find similar but easier problems.

Analysis is just an activity, and is not the whole job.

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.

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.

It depends why you think there might not be a solution. If you have enough experience and have a gut feel then do something simple and quick to prove the gut feel or put your hand up and say that you don't know how to approach it.

If you are not experienced then your battle is with fear and depending on the cause, a good way of getting past that is to work with others who can encourage you when you do well and help you understand when you are going awry and why.

And ultimately, don't bullshit. Be honest about what you think and how you might approach something and if the boss isn't convinced, let them give the job to someone else.

In my own experience, alternating between bouts of self-doubt, hopelessness and despair followed by episodes of excitement, mania (the good kind) and progress from the fire of a new idea all seems normal and unavoidable to me. You just have to slog through the rough times and keep going. Don't listen to naysayers and don't give up but be sure to take breaks. Keep a journal of what hasn't worked in the past and summarize what you learned. Just writing it will put it in your subconscious for later use and occasionally you'll want to go back and revisit an idea that did not work.

If no "good" solutions come to mind, I try to think of the dumbest, most irresponsible ways I could solve the problem. A silly solution is still a solution.

From there, the game is to take that silly solution and work it toward something that's not so silly. It's not easy, but it gives you incremental successes that are vital when struggling with anxiety/paralysis. Also, deliberately looking for bad ideas takes off the pressure to have a good idea. (You may even find that the "bad" idea you were avoiding wasn't actually all that bad in the first place!)

I reference the 'Cutting the Gordian Knot' section in the Pragmatic Programmer[0] when dealing with tough problems.

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

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.

Every problem has a solution.

The more relevant question is: At what cost?

For example, in layman terms we all consider factoring RSA2048 impossible. But, given all the computing power in the world or 10 years more on quantum research this becomes possible.

For sure you can split hairs about this all day, like adding cost constraints as part of the problem and formal mathematical proofs may be an exception here.

In the end, what really matters is, how much is it worth to solve the problem and how much is it worth to estimate this cost. Investigations to reach an accurate estimate also cost effort.

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

Given a complex problem, if there is just one part of it that I fear may not be solvable, then I will look into that part first to figure out if a solution exists and only later into the remaining elements of the problem.

If instead the uncertainty comes just from the "size" of the problem, then I split it into smaller parts that are easier to face, and I look into each of them the bare minimum to be able to confirm that a solution exists. Once I am confident a solution exists for all of the smaller parts and therefore for the whole problem, then I start the actual work.

I have been working on my fair share of problems that may or may not have solutions. Two pieces of advice that helped me:

1. Choose your battles. There are important problems out there, but our time is limited. If it is important and in my domain, I will pick it up. 2. Is it developmental? Depends on what stage you are in, but a couple of years ago I picked up lots of problems without solutions. It was a risky move, I wasted a ton of time, and the payoff wasn't obvious --- I definitely did some short-term damage. I am reaping some benefits now because of the skills I developed.

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

Yes, so essentially I try a few things, I try to find a naive and simplest solution and not ever worry about optimizations. If I fail in that case I try to find a simpler variation of the problem and solve that, if not I keep reducing the problem down. If the problem is reduced down I can explain it to someone else and ask them. Then or from that reduced problem I try and figure out what class of problems it belongs to. If you get anxiety you should ask around, and do what you are doing ask the internet using concise language.

Don't take yourself so seriously if that creates anxiety and stress. If everyone around you expects you to be serious about it and that makes you feel uncomfortable in general, take that message from your brain seriously. It can become an everyday torture that takes you down to terrible places. People have praised and deride my solutions. Life goes on either way. I don't solve problems because I want to please people. I solve problems because I want to understand the causes and effects of everything. EVERYTHING! ;)

There may be no easy (general) solution, but there may be an acceptable solution in a particular case.

The halting problem is unsolvable, but you usually can say with certainty that a particular piece of code is not an infinite loop. The knapsack problem may take ridiculous time to solve precisely, but moat of the time you have little trouble packing your backpack or bag so that everything you need fits. Etc.

Often you only need to solve 20% of the problem to get 80% of the benefit. Make this step, and you will face further problems from a much better position.

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.

One approach: try to prove it doesn't have a solution. Would solving the problem entail things that obviously aren't true? Or does it entail things that probably aren't true, forcing you to dig farther about situations where they might be? Attempting to prove impossibility inverts the problem, and lets you act as critic on an argument that you want to be proved false.

This is a common approach to mathematical problems, but it's helped me break down more practical situations too.

I just had this conversation with my wife. She needs to expand her business into the nearest city and has been dragging on it for a couple of years. She admits she is not sure why she has not started. She is overwhelmed with the tasks needed to get it going and not sure where to start.

I suggested that the least important thing is How you start, and the most important thing is That you start. Starting the process, in any form, focuses you quickly on the most important things that need to get done first.

In research, you have this situation quite often.

Often you at least have some intuition or assumption on sth and then you just keep doing experiments to either confirm or falsify this. When sth does not work yet, you do experiments or analysis to better understand why it is failing. And then you try out more ideas to compensate those problems.

There is really no ending here, you can push it further and further as much as you like. You will get a better understanding along the way on what is possible and what is not.

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 was handed a problem during a job interview that was a "how do you get a computer to do this?" problem. Apparently I was the only one who attempted, and the general consensus is that no, you need a human being to do it.

So I sometimes divide problems into "Can a human do it or not?"

(Years later I would finally have the inklings of how to get a computer to do it. It would be quite complex but I think it might actually be feasible. A lot of subconscious introspection happened.)

Not knowing if something has a proper solution is a pretty normal state of affairs. Make a plan how to analyze it: for the next n days, what are you doing each day. Collect data x, run analysis y, book time on machine z, etc. Really write it down the activities and deliverables for each day for the next 2 to 3 weeks to start.

It does not mean there is no space for creativity - the plan will not last as new things come to light, but the plan means you move forward in a structured manner.

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.

My approach: Divide and conquer

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

Can I make an observation? Most of life involves problems that may not have a solution or a demonstrably optimal solution. Most complex problems involve trade offs. Much of the skill in being an experienced person in one's field involves making the best possible trade offs toward a working solution. I like the other observations in this thread about failing fast too - often we find something that works, and we continue to iterate to improve.

To problems that can't be solved (like how can I get my wife back) I just imagine I have solved it, or my brain will just keep trying to solve the problem. For solvable problems i either brute force by moving the mountain one sand corn at at time, or keep iterating. When you have a grip on how much the problem will cost to solve you have to ask yourself it it's worth solving - or if you can just use a more crude existing solution.

I really enjoyed reading Fermat's Enigma[1] a book about the guy who solved Fermat's Last Theorem.

A memorable quote from the book:

"It’s fine to work on any problem, so long as it generates interesting mathematics along the way—even if you don’t solve it at the end of the day."

[1] https://www.amazon.com/Fermats-Enigma-Greatest-Mathematical-...

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

I look for different ways of representing the problem domain or the desired outcome. This will improve your vocabulary/toolbox for reasoning about and subdividing them into more approachable units.

For some inspiration, I recommend watching this talk by Bret Victor https://www.youtube.com/watch?v=oUaOucZRlmE (Media for Thinking the Unthinkable)

If you're lucky enough to be in a problem-solving situation where you have the space (mentally, physically, monetarily) to take this advice: When you can't find a breadcrumb in the middle, focus on the end and the start (in that order). Ignore the chance of a solution being impossible (but don't ignore evidence of a solution being impossible - use it to think about the end, the start, or the middle.)

Think about the problem deeply for several days. Take a 3 day break and then start working in the solution. Allow the associative cortex to do the work.

Read, think, and sleep. Problems in this category often need time in your brain to settle and clarify. The process is rewarding, and after you’ve tackled a few such problems (either proving them impossible or actually solving them) you gain confidence. A subset of unsolved or unsolvable problems might become long term projects that you can manage and prioritize (or eventually put aside) over the years.

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.

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

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.

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.

If you're getting paralysis: That means that you need to write down how you feel and you need to write down what you know about the problem.

From there:

1. Write down and solve/suggest for what you know on the edges of the problem

2. Extremely pinpoint what the problem is

3. Talk it out with the rubber duck/coworkers

4. Escalate the issue.

5. Design out the solution and leave question marks where you can't solve it.

6. Go out for a walk

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

Are you working on P != NP? Jokes aside, this reminds me of working on a grad school thesis. I tend to find the biggest whiteboard (you can use any medium though) and lay out everything that is known and unknown about the problem. This helps avoid the sensation of "too massive", which can be anxiety or paralysis inducing.

Flip a coin (or roll a die). I'm not kidding. There has been research on this. It has two benefits. One, as you flip the coin, you'll find yourself rooting for a certain outcome -- that's what you should do, regardless of how the coin lands.

And in some cases where you truly have no idea, it helps push your brain into a choice.

Some of the guidance given by the Cynefin framework helped me to make better decisions: https://www.everydaykanban.com/2013/09/29/understanding-the-...

Instead of thinking the problem is technical or scientific in nature, let's think about the same question for human relationship problems. Like how do we solve the inability of our elected, appointed or self-selected leaders to seek consensus or consider alternative points of view.

- Is this knowable or solvable or of problem-type solved? (e.g. information problem vs. work problem, do we need to do new science?)

- How do analogies for this resolve? e.g. what else is an n-part dynamic?

- What is a test for a solution?

- Do I want the general solution or just a specific result and is this actually a problem I need to solve?

Just mess around with stuff and techniques related to the problem. Also rubber duck debug the problem a lot. Describe it to people so that they can understand it. Listen closely to their questions even though they won't make a lot of sense to you at first glance.

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.

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.

Sounds like the problem is not the problem, but the problem-solver. Many good suggestions here on solving toy problems, etc., but since you describe the real problem as mental (anxiety), do all the boring self care stuff too: #1 is get enough sleep.

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.

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.

Richard Hamming's talk, "You and Your Research" is applicable.

https://www.cs.virginia.edu/~robins/YouAndYourResearch.html

Stay stupid.

Do whatever seems to work or may work. Don't think about it. Just do it.

The midwit meme pretty much sums this entire problem up: https://www.swyx.io/simplicity-rush

Knowing when to stop researching the problem and start colliding ideas is an art in itself.

It's always good to have an easier and more attractive backup problem in your back pocket to make your current problem jealous and your approach to it more playful.

When you find something that doesn't work, you should consider that a win. That means you can celebrate getting closer to the solution.

Reminds me of the Edison quote: "I have not failed. I've just found 10,000 ways that won't work."

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.

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.

Another good one: describe the problem and why it's so hard to someone else.

In my experience usually it means you are not solving the right problem - that problem you feel has "no solution" is like the outer appendages or surface of something else which is where the real problem is.

My advice would be push back the possibly unsolvable problem down the road, and deal with your axienty/paralysis first.

If your anxiety/paralysis is specifically tied to the problem, seek help from a mental health professional.

Usually it's a good idea to start with a simple base case with only a few moving parts/interactions such that you can handle it all in your head. Only once you understand the base case well you complexify.

I think if there is no good solution, doing nothing might be the best thing. We generally forget this option, in many cases, there are always ways to side step and avoid the problem.

The mindset I use is to believe (without evidence) that a solution exists. That allows me to see solutions faster because I'm not fighting with myself.

Put yourself into the world where the solution exists.

Try to write down a semi-proof as to why it can't be solved.

I tend to find that assumptions/etc that get made in that proof can be attacked and something trackable can be found this way.

Often the pivot to proving why the solution you looked for can't exist is just as rewarding. A lot of interesting would-be research lays in that avenue of investigation.

~"Part of an answer to a question lies in the definition of the question" (c) some famous physicist.

James Fadiman also conducted research on microdosing aiding problem solutions.

It’s very tough. For me, an important moment is realizing that these situations are rare and where the most growth can happen, which helps me push through sometimes.

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

Think about the problem, actively and deeply. Then let it go and sleep on it.

Sometimes, when you can’t come to a solution, it’s best to let the solution come to you.

I usually tackle the absolute hardest part first, hoping that I'll either fail fast on that, or it'll work and it will be downhill from there.

“Sometimes the best way to solve a problem is to stop participating in it.” Can be applied to various parts of the overall problem, or the entire thing.

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.

I look at it once, then ignore it and do something else for a few days. Revisiting the problem usually presents a couple of potential solutions.

Side question: How do you deal with micromanagement or incessant demands for estimations on a problem that you're not sure has a solution?

Feel like there's an "Ask HN: How do you approach a solution you are not sure has a problem?" counter thread opportunity here.

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

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

Step away from it, do something else. I find my mind will process it in the background. After a day or so, I may be ready to tackle it.

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.

I suppose it happens to everybody one day. I suppose it deals with self confidence and optimism. And confidence in the team…

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

try a (or some) quick prototypes of the simplest possible form of the problem. Try and find if it maps to other, solved or proven unsolvable, problems. Split your problem into subproblems, see if those are solvable, if not completely, change course toward a more solvable, maybe similar, problem.

since you mentioned your open mind having difficulty, it sounds like you need to to improve the ability to tackle these issues more methodically and slowly plan out a strategy of attack instead of just trying things.

Assign it to a group of students new to the topic... without telling them that no known solution exists.

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

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

synths https://twitter.com/seanmcdonaldxyz/status/16611400526747443...

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

TDD. (I'm not religious about tdd, but this is the place where I use it always).

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

Do you mean like a technical problem with code or a social/political issue?

Just start trying stuff. Learning happens through the trial and error process.

Set a deadline and try as hard as you can assuming it has a solution.

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

Turn it into a problem where you are sure there’s a solution.

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

“What is the smallest part of this problem can I solve”?

Relax the problem - remove one constraint and try again.

Deconstruct and aim to solve a lesser subproblem first.

There’s an interesting approach used by DARPA:

1. Prove its not impossible

2. Prove it’s possible

3. Do it

Ask gpt the answer, then correct its errors

Work consistently, and pray for strength, hope and wisdom. These are the best kinds of problems to work on, IMO, but they can get very difficult.

Assume it has a solution. Try that.

make your problem figuring out if the original one is solvable. more thinking, less typing

Solve it 80%

What's an example of one?

A thing I tell junior programmers is that their job isn't so much to solve problems, as to help figure out what the problem really is, and solve that. When somebody asks for a thing, don't go silent and go and build precisely that thing, and then come back weeks (or, heaven help us, months) later with that thing. Rather, talk to them! Hardly anybody knows what they want! Your job isn't to do precisely what they say they want, it's to help them figure out what they want! Iterate!

So, in that vein, both the solution *and the problem* are fair game for attack.

There is a wonderful, wonderful short essay by Michael Jackson (the other one) called "Brilliance" in his book "Software Requirements and Specifications". It is poignant, even painful, in the way that the the TV shows Silicon Valley or The Office are exquisitely painful. It is, alas, impossible to find unless you know exactly what you are looking for, but...

*Brilliance*, by Michael Jackson (from "Software Requirements and Specifications")

Some time ago I spent a week giving an in-house program design course at a manufacturing company in the mid-west of the United States. On the Friday afternoon it was all over. The DP Manager, who had arranged the course and was paying for it out of his budget, asked me into his office.

"What do you think?" he asked. He was asking me to tell him my impressions of his operation and his staff. "Pretty good," I said. "You've got some good people there." Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.

"What did you think of Fred?" he asked. "We all think Fred's brilliant." "He's very clever," I said. "He's not very enthusiastic about methods, but he knows a lot about programming." "Yes," said the DP Manager. He swiveled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. "Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it." His voice dropped to a reverent hush. "Fred tells me that he's not sure he understands it himself."

"Terrific," I mumbled respectfully. I go the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. That matched my own impression of Fred very well. "But what about Jane?" I said. "I thought Jane was very good. She picked up the program design ideas very fast."

"Yes," said the DP Manager. "Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really tough at all. Most of them turned out pretty simple. She hasn't really proved herself yet - if you see what I mean?"

I saw what he meant.

Use GPT

[dead]

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

[dead]

As a capitalist with resources, you hire someone to find a solution, dispose of them when they fail or profit from their labor when they succeed, and even then sometimes dispose of them if you don’t have more problems to solve.