5 ms·

Practical guide to solving hard problems

166 points by kiyanwang 5y ago

FigurativeVoid 5y ago
> Think hard about the problem for a few weeks before typing any code I have always thought the "subconscious mind" was a bit of a myth. But the more I have learned about it, there is a lot to be said for having some simple unstructured time to let your mind process. No music. No podcasts. Just a walk.
- genghisjahn 5y ago
  Just an anecdote...Last week I was on a run and not really thinking about a software problem at all. And then the solution just appeared in my head. Like it got beamed there. Got home and made up for two weeks of procrastination in a weekend.
  - UnpossibleJim 5y ago
    I absolutely hate running. Hate it... but I do it because it helps me solve problems. I have to think about other things to forget about the running, so my brain wanders off and does the hard work that it (what I'll call) subconsciously didn't want to do. Unfortunately this led to a stress fracture during one troubling sprint.
    - SkyMarshal 5y ago
      Try biking instead. Similar to running, it’s an individual exertion you can do outdoors in the fresh air, but smoother and lower impact on the bones and joints. No shin splints or other impact injuries. You can often find a used but quality brand bike on Craigslist for ~$100, which is sufficient for just exercise.
      - UnpossibleJim 5y ago
        I actually switched to a treadmill and took a course in running and minimalist shoes (which I thought were BS before) and changed my running form. Got rid of my shin splints and knee pain. No impact issues... was a weird transition, though. Learning to run like a boxer stands was more difficult than I thought it would be. I can run for about a mile, mile and a half on the concrete, outside before I realize I'm doing damage and have to stop... getting old sucks =) I do have a bike, but somehow it doesn't do the same disassociation for me. Not sure why. I think it has to be something I hate, personally, to get me over the hump and force me out of my own body.
      - freemint 5y ago
        Or kick bikes. https://en.wikipedia.org/wiki/Kickbike https://en.wikipedia.org/wiki/Kickbike
  - jeevan4 5y ago
    absolutely, I second this. These days I'm stuck with endless meetings and not getting anything done. But I made a habit of jogging in the evenings and so much of productive hours in just 45mins or soo..
  - np- 5y ago
    A lot of times I’ve found the amount of time it takes me to solve a problem is about the same whether I’m actively working on it or not. Once a problem has been percolating in my head for a while things eventually “click” and it just becomes a matter of typing out the code. This looks like procrastination from the outside, but I’m still working even if it looks like I’m taking it easy. At least my brain is, somehow. I have come to trust this process after many years. Alternatively if I start tackling the problem immediately and really put my nose to the grindstone there’s often a lot of moments where I realize I didn’t understand the problem fully, and waste a ton of time backtracking. So it ends up taking the exact same amount of time, only difference is how many times I banged my head against the wall in frustration.
- qiskit 5y ago
  I was told by my philosophy professor that Kant was a big walker/hiker. I believe einstein said he got his eureka moments in dreams while napping/sleeping. It may be myth, but Martin Luther apparently got his revelations on the toilet. I don't remember if it was benjamin franklin who credit his contributions to bathing. And I'm sure there have been a few thinkers who praised alcohol. Whatever works I guess.
- ravi-delia 5y ago
  > I have always thought the "subconscious mind" was a bit of a myth. If you really think about it, aren't all insights subconscious insights? Even if you're consciously stringing it all together, there's no thought process for adding two and two. You just look at '2+2' and out pops '4', ready for your conscious mind to use.
- mellavora 5y ago
  > I have always thought the "subconscious mind" was a bit of a myth I had an insight recently about this, because I also have a tendency to trust my conscious more than my unconscious. What is the conscious made of? sorry if that gets too zen/koan-y.
piinbinary 5y ago
I've written a few notes about problem solving [0] that you might also find useful [0] https://jeremymikkola.com/posts/2022_01_01_a_few_notes_on_problem_solving.html https://jeremymikkola.com/posts/2022_01_01_a_few_notes_on_pr...
is_true 5y ago
I find that the formal requirements process sometimes helps me think about problems
- JackFr 5y ago
  I think the method given here is also good at uncovering where a spec might be subtly unclear. I'm not sure how to do this and as I break it down farther and farther I realize part of that is because a signficant (but initially hidden) aspect of it has not been specified. Now it may be that it's my job to specify it as well as implement it, which is fine, but those are two different problems.
ChrisMarshallNY 5y ago
Good commonsense stuff. > Think hard about the problem for a few weeks before typing any code. In my case, it's never more than overnight, but maybe it's because I am working on a smaller scope than the author.
- dgb23 5y ago
  I work on small scoped things too, so I can relate, but in some cases, when learning a thing that is really "new" for me it can be challenging to digest and really absorb it can take quite some time until it starts to tangibly influence what I do in my day to day. In some cases even months. I think learning and problem solving are very related. They need nourishment, a proper amount of time, playful and focused/stubborn phases etc.
- mbrameld 5y ago
  If one can get their mind around it overnight then it's likely not in the class of hard problems the author is addressing.
  - ChrisMarshallNY 5y ago
    Maybe, maybe not. You’d be surprised how experience can shorten the planning time. Also, I’m not quite “neurotypical,” and avoid writing things down. I tend to keep my strategic model in my head. I’m constantly wargaming my strategy. You might be surprised at the scope of the project I’m doing right now. I’ve been working on it for around two years, and we’re getting within sight of the finish line. About the only time I write stuff down, is when I want to pass it by other team members. I’ve also learned that, sometimes, there’s no substitute for writing some code, stepping through it, and seeing how that jives with your strategy. To do things my way, you have to be willing to toss out a lot of code; sometimes, weeks’ worth of code.
    - Jensson 5y ago
      > To do things my way, you have to be willing to toss out a lot of code; sometimes, weeks’ worth of code. If you wasted weeks coding the wrong thing then you didn't solve it overnight. Making mistakes is a part of the process, you have to count that time as well.
PaulHoule 5y ago
You need a taxonomy of what makes problems 'hard' to attack hard problems. For instance I often find solving problems with CSS 'hard' and that is some combination of the complexity of the environment (the web browser), my own ignorance, and the tendency for the code I'm working on to have been developed based on the "look it up on Google/Stackoverflow" such that I don't have a solid foundation to work on. Another kind of 'hard' problem that I relish are problems that are hard because of circular dependencies and I find it really rewarding to go over the problem again and again until I've found the irreducible core of circularity, build a minimum-size system that resolves it, and then build the rest of the system as a set of clean layers on top of it, often using techniques such as code generation.
dgb23 5y ago
This technique reminds me of "wishful thinking" in SICP (not sure if it was in the book or the lectures). The tricky parts get delayed but one progresses on the overall structure and the more obvious parts to reduce the mental overhead. It's pretty effective. I think it is best used on "software design" kind of problems. Related things: A book that is very digestible and praised is "How to Solve It" by George Polya (Original: "Schule des Denkens. Vom Lösen mathematischer Probleme"). It has focus on math teaching but many of the principles are generally applicable to problem solving and teaching. A talk I really like is "Hammock Driven Development" by Rich Hickey. Very enjoyable and goes into some of the longer term things we can do around problem solving. Utilizing time and letting the brain work in the background. I just a few weeks ago had to refactor and generalize some hairy part of a web app. I could do it well because I was thinking about the problems over a longer period. In the end I frantically hacked away the solution and now have a nice little extendable library that is quite a bit more useful than what I had before. I even _found_ and _fixed_ some bugs while sleeping - just popped into my mind after waking up at some point.
minroot 5y ago
Lot of throwing
cossatot 5y ago
Although the nature our work varies quite a bit, here are some things that I have found in my domain (earthquake-related science broadly, with a large computational component) that I think generalize fairly well: 1. Tightening feedback loops as much as possible. This means both recursively breaking down the problem into subproblems (as discussed by the author), and having very fast ways of doing formal testing, sensitivity testing, etc. Sometimes I'm working on a problem where I have to solve a system of equations that takes a few hours. This means that progress is really slow and I just won't be able to turn all the knobs that I want to or try alternative approaches. If I can subsample the data or the model domain down to 20 minutes, then that gets better but I still need to do something else during the downtime. If I can get it down to 2 minutes, then I can really make progress and if it's a few seconds then I can fly. To do this I might have to invest a few hours or a day into making a testing dataset and environment that allows for very rapid iterations (but may not be useful once the particular issue is addressed), but I am often averse to doing because it feels like a waste of time, even though my velocity averaged over the month is usually higher if I do it. 2. Work on the hard problems first. This is in contrast to what the author suggests but I would rather take the bull by the horns knowing that once I address the hard parts it's going to be a lot easier. If the hard parts loom in the distance I worry that I will run out of time, because even on the easy parts it's possible to spend all of the time making small tweaks. Do the hard parts, or at least a draft implementation, first so you can allocate your time over the project more efficiently and ensure that you're not going to blow up when you're 80% done but just hit a massive roadblock.
- minkzilla 5y ago
  I agree with 2. I have found that working on the hard parts triggers the realization that something needs to change on my inputs, outputs, or the whole way I am thinking about it much more often than the easy parts do. So I save the easy parts for writing once I know the hard parts are going to work.
iamricks 5y ago
I’ve found when something feels really hard (programming problem) that is takes me longer than a day to figure out a solution, i am missing some piece of knowledge that’s a stepping stone to solve the problem This will lead me to trying to figure out where my knowledge gap is so i can fill the gap and then try again to solve the problem
kevmo314 5y ago
> Chances are you’re not the first person to need this particular function or widget. On the other hand, when I don't find such a function at least I know I'm solving a new problem.
lodovic 5y ago
This process works, but in my experience it also leads to the naive implementation. Which isn't always bad.
thisisbrians 5y ago
I think this is very sound advice. But it can be equally effective (and maybe even more fun) to careen a prototype through the problem space as quickly as possible to see what comes to light. Even if I can't solve a problem this way, I usually have a leg up on the next attempt from what I learned. Or maybe it even works, and then gets refactored or redesigned to improve in the necessary dimensions.
visviva 5y ago
"Practical guide to solving hard programming problems"
someweirdperson 5y ago
step 1: Try to prove that a solution cannot exist. step 2: Challenge assumptions about implicit requirements, the scope of applicability of explicit requirements, and boundary conditions. Then, in some magical moment, a loophole opens, and a solution manifests. I love that feeling. I wish there were more such hard but then not so hard problems.
otikik 5y ago
My first step is "google for at least one day". You might find that the problem you were planning on spending weeks thinking hard about was solved thousands of years ago by a reclusive greek guy. Or that a couple Nobel Prices in Mathematics have spent 10 years thinking about how to solve it, but are not there quite yet.
- anon2020dot00 5y ago
  I agree this is good when dealing with hard and important problems; in which the vast store of human knowledge can come into play. But just a digression, if solving the problem is not that important like with hobbies, it is usually more fun and more rewarding to solve the problem without googling; like playing a video game without looking at a guide beforehand.
- deanmen 5y ago
  There isn't a NOBEL PRIZE in Mathematics. Perhaps you meant the FIELDS MEDAL, or the ABEL PRIZE? Some mathematicians won the Nobel Prize in Physics (e.g. Sir Robert Penrose) Or maybe you were thinking of John Nash, who won the Nobel Prize in Economics?
  - otikik 5y ago
    Heh. I should have googled first. Q.U.E.D.
MaxMoney 5y ago
swframe2 5y ago
I usually start with a program that visualizes the problem. Then I repeatedly implement small steps towards the solution and confirm that their effects are as I expected.
axiosgunnar 5y ago
This seems useful for "i want to implement 2fa in a language i don't really know", but not so much for "i want to solve P/NP"
AtomicOrbital 5y ago
my approach is the opposite ... attack the most difficult aspect of the challenge first ... get this working using the normal divide and conquer approach ... this often requires totally different inputs and outputs since its the inner core ... then work outward solving related issues until you read the outermost inputs and outputs to me its critical to nail the hardest part first since if that portion cannot be solved or needs a radical rethink it will often require entirely new surrounding logic

166 points by kiyanwang 5y ago

> Think hard about the problem for a few weeks before typing any code I have always thought the "subconscious mind" was a bit of a myth. But the more I have learned about it, there is a lot to be said for having some simple unstructured time to let your mind process. No music. No podcasts. Just a walk.

genghisjahn 5y ago
Just an anecdote...Last week I was on a run and not really thinking about a software problem at all. And then the solution just appeared in my head. Like it got beamed there. Got home and made up for two weeks of procrastination in a weekend.
- UnpossibleJim 5y ago
  I absolutely hate running. Hate it... but I do it because it helps me solve problems. I have to think about other things to forget about the running, so my brain wanders off and does the hard work that it (what I'll call) subconsciously didn't want to do. Unfortunately this led to a stress fracture during one troubling sprint.
  - SkyMarshal 5y ago
    Try biking instead. Similar to running, it’s an individual exertion you can do outdoors in the fresh air, but smoother and lower impact on the bones and joints. No shin splints or other impact injuries. You can often find a used but quality brand bike on Craigslist for ~$100, which is sufficient for just exercise.
    - UnpossibleJim 5y ago
      I actually switched to a treadmill and took a course in running and minimalist shoes (which I thought were BS before) and changed my running form. Got rid of my shin splints and knee pain. No impact issues... was a weird transition, though. Learning to run like a boxer stands was more difficult than I thought it would be. I can run for about a mile, mile and a half on the concrete, outside before I realize I'm doing damage and have to stop... getting old sucks =) I do have a bike, but somehow it doesn't do the same disassociation for me. Not sure why. I think it has to be something I hate, personally, to get me over the hump and force me out of my own body.
    - freemint 5y ago
      Or kick bikes. https://en.wikipedia.org/wiki/Kickbike https://en.wikipedia.org/wiki/Kickbike
- jeevan4 5y ago
  absolutely, I second this. These days I'm stuck with endless meetings and not getting anything done. But I made a habit of jogging in the evenings and so much of productive hours in just 45mins or soo..
- np- 5y ago
  A lot of times I’ve found the amount of time it takes me to solve a problem is about the same whether I’m actively working on it or not. Once a problem has been percolating in my head for a while things eventually “click” and it just becomes a matter of typing out the code. This looks like procrastination from the outside, but I’m still working even if it looks like I’m taking it easy. At least my brain is, somehow. I have come to trust this process after many years. Alternatively if I start tackling the problem immediately and really put my nose to the grindstone there’s often a lot of moments where I realize I didn’t understand the problem fully, and waste a ton of time backtracking. So it ends up taking the exact same amount of time, only difference is how many times I banged my head against the wall in frustration.
qiskit 5y ago
I was told by my philosophy professor that Kant was a big walker/hiker. I believe einstein said he got his eureka moments in dreams while napping/sleeping. It may be myth, but Martin Luther apparently got his revelations on the toilet. I don't remember if it was benjamin franklin who credit his contributions to bathing. And I'm sure there have been a few thinkers who praised alcohol. Whatever works I guess.
ravi-delia 5y ago
> I have always thought the "subconscious mind" was a bit of a myth. If you really think about it, aren't all insights subconscious insights? Even if you're consciously stringing it all together, there's no thought process for adding two and two. You just look at '2+2' and out pops '4', ready for your conscious mind to use.
mellavora 5y ago
> I have always thought the "subconscious mind" was a bit of a myth I had an insight recently about this, because I also have a tendency to trust my conscious more than my unconscious. What is the conscious made of? sorry if that gets too zen/koan-y.

piinbinary 5y ago

I've written a few notes about problem solving [0] that you might also find useful [0] https://jeremymikkola.com/posts/2022_01_01_a_few_notes_on_problem_solving.html https://jeremymikkola.com/posts/2022_01_01_a_few_notes_on_pr...

is_true 5y ago

I find that the formal requirements process sometimes helps me think about problems

JackFr 5y ago
I think the method given here is also good at uncovering where a spec might be subtly unclear. I'm not sure how to do this and as I break it down farther and farther I realize part of that is because a signficant (but initially hidden) aspect of it has not been specified. Now it may be that it's my job to specify it as well as implement it, which is fine, but those are two different problems.

ChrisMarshallNY 5y ago

Good commonsense stuff. > Think hard about the problem for a few weeks before typing any code. In my case, it's never more than overnight, but maybe it's because I am working on a smaller scope than the author.

dgb23 5y ago
I work on small scoped things too, so I can relate, but in some cases, when learning a thing that is really "new" for me it can be challenging to digest and really absorb it can take quite some time until it starts to tangibly influence what I do in my day to day. In some cases even months. I think learning and problem solving are very related. They need nourishment, a proper amount of time, playful and focused/stubborn phases etc.
mbrameld 5y ago
If one can get their mind around it overnight then it's likely not in the class of hard problems the author is addressing.
- ChrisMarshallNY 5y ago
  Maybe, maybe not. You’d be surprised how experience can shorten the planning time. Also, I’m not quite “neurotypical,” and avoid writing things down. I tend to keep my strategic model in my head. I’m constantly wargaming my strategy. You might be surprised at the scope of the project I’m doing right now. I’ve been working on it for around two years, and we’re getting within sight of the finish line. About the only time I write stuff down, is when I want to pass it by other team members. I’ve also learned that, sometimes, there’s no substitute for writing some code, stepping through it, and seeing how that jives with your strategy. To do things my way, you have to be willing to toss out a lot of code; sometimes, weeks’ worth of code.
  - Jensson 5y ago
    > To do things my way, you have to be willing to toss out a lot of code; sometimes, weeks’ worth of code. If you wasted weeks coding the wrong thing then you didn't solve it overnight. Making mistakes is a part of the process, you have to count that time as well.

PaulHoule 5y ago

You need a taxonomy of what makes problems 'hard' to attack hard problems. For instance I often find solving problems with CSS 'hard' and that is some combination of the complexity of the environment (the web browser), my own ignorance, and the tendency for the code I'm working on to have been developed based on the "look it up on Google/Stackoverflow" such that I don't have a solid foundation to work on. Another kind of 'hard' problem that I relish are problems that are hard because of circular dependencies and I find it really rewarding to go over the problem again and again until I've found the irreducible core of circularity, build a minimum-size system that resolves it, and then build the rest of the system as a set of clean layers on top of it, often using techniques such as code generation.

dgb23 5y ago

This technique reminds me of "wishful thinking" in SICP (not sure if it was in the book or the lectures). The tricky parts get delayed but one progresses on the overall structure and the more obvious parts to reduce the mental overhead. It's pretty effective. I think it is best used on "software design" kind of problems. Related things: A book that is very digestible and praised is "How to Solve It" by George Polya (Original: "Schule des Denkens. Vom Lösen mathematischer Probleme"). It has focus on math teaching but many of the principles are generally applicable to problem solving and teaching. A talk I really like is "Hammock Driven Development" by Rich Hickey. Very enjoyable and goes into some of the longer term things we can do around problem solving. Utilizing time and letting the brain work in the background. I just a few weeks ago had to refactor and generalize some hairy part of a web app. I could do it well because I was thinking about the problems over a longer period. In the end I frantically hacked away the solution and now have a nice little extendable library that is quite a bit more useful than what I had before. I even _found_ and _fixed_ some bugs while sleeping - just popped into my mind after waking up at some point.

minroot 5y ago

Lot of throwing

cossatot 5y ago

Although the nature our work varies quite a bit, here are some things that I have found in my domain (earthquake-related science broadly, with a large computational component) that I think generalize fairly well: 1. Tightening feedback loops as much as possible. This means both recursively breaking down the problem into subproblems (as discussed by the author), and having very fast ways of doing formal testing, sensitivity testing, etc. Sometimes I'm working on a problem where I have to solve a system of equations that takes a few hours. This means that progress is really slow and I just won't be able to turn all the knobs that I want to or try alternative approaches. If I can subsample the data or the model domain down to 20 minutes, then that gets better but I still need to do something else during the downtime. If I can get it down to 2 minutes, then I can really make progress and if it's a few seconds then I can fly. To do this I might have to invest a few hours or a day into making a testing dataset and environment that allows for very rapid iterations (but may not be useful once the particular issue is addressed), but I am often averse to doing because it feels like a waste of time, even though my velocity averaged over the month is usually higher if I do it. 2. Work on the hard problems first. This is in contrast to what the author suggests but I would rather take the bull by the horns knowing that once I address the hard parts it's going to be a lot easier. If the hard parts loom in the distance I worry that I will run out of time, because even on the easy parts it's possible to spend all of the time making small tweaks. Do the hard parts, or at least a draft implementation, first so you can allocate your time over the project more efficiently and ensure that you're not going to blow up when you're 80% done but just hit a massive roadblock.

minkzilla 5y ago
I agree with 2. I have found that working on the hard parts triggers the realization that something needs to change on my inputs, outputs, or the whole way I am thinking about it much more often than the easy parts do. So I save the easy parts for writing once I know the hard parts are going to work.

iamricks 5y ago

I’ve found when something feels really hard (programming problem) that is takes me longer than a day to figure out a solution, i am missing some piece of knowledge that’s a stepping stone to solve the problem This will lead me to trying to figure out where my knowledge gap is so i can fill the gap and then try again to solve the problem

kevmo314 5y ago

> Chances are you’re not the first person to need this particular function or widget. On the other hand, when I don't find such a function at least I know I'm solving a new problem.

lodovic 5y ago

This process works, but in my experience it also leads to the naive implementation. Which isn't always bad.

thisisbrians 5y ago

I think this is very sound advice. But it can be equally effective (and maybe even more fun) to careen a prototype through the problem space as quickly as possible to see what comes to light. Even if I can't solve a problem this way, I usually have a leg up on the next attempt from what I learned. Or maybe it even works, and then gets refactored or redesigned to improve in the necessary dimensions.

visviva 5y ago

"Practical guide to solving hard programming problems"

someweirdperson 5y ago

step 1: Try to prove that a solution cannot exist. step 2: Challenge assumptions about implicit requirements, the scope of applicability of explicit requirements, and boundary conditions. Then, in some magical moment, a loophole opens, and a solution manifests. I love that feeling. I wish there were more such hard but then not so hard problems.

otikik 5y ago

My first step is "google for at least one day". You might find that the problem you were planning on spending weeks thinking hard about was solved thousands of years ago by a reclusive greek guy. Or that a couple Nobel Prices in Mathematics have spent 10 years thinking about how to solve it, but are not there quite yet.

anon2020dot00 5y ago
I agree this is good when dealing with hard and important problems; in which the vast store of human knowledge can come into play. But just a digression, if solving the problem is not that important like with hobbies, it is usually more fun and more rewarding to solve the problem without googling; like playing a video game without looking at a guide beforehand.
deanmen 5y ago
There isn't a NOBEL PRIZE in Mathematics. Perhaps you meant the FIELDS MEDAL, or the ABEL PRIZE? Some mathematicians won the Nobel Prize in Physics (e.g. Sir Robert Penrose) Or maybe you were thinking of John Nash, who won the Nobel Prize in Economics?
- otikik 5y ago
  Heh. I should have googled first. Q.U.E.D.

MaxMoney 5y ago

swframe2 5y ago

I usually start with a program that visualizes the problem. Then I repeatedly implement small steps towards the solution and confirm that their effects are as I expected.

axiosgunnar 5y ago

This seems useful for "i want to implement 2fa in a language i don't really know", but not so much for "i want to solve P/NP"

AtomicOrbital 5y ago

my approach is the opposite ... attack the most difficult aspect of the challenge first ... get this working using the normal divide and conquer approach ... this often requires totally different inputs and outputs since its the inner core ... then work outward solving related issues until you read the outermost inputs and outputs to me its critical to nail the hardest part first since if that portion cannot be solved or needs a radical rethink it will often require entirely new surrounding logic