6 ms·

I Don't Understand This (Yet)

80 points by spansoa 5y ago

User23 5y ago
That coin problem is fun. I’m not really familiar with insight problems like this, so it took about a minute to get it.
- whatshisface 5y ago
  The trick for me was to move one triangle around over the other until only three coins didn't overlap.
  - cardanome 5y ago
    I think am misunderstanding the problem because I have convinced myself that it can not have a valid solution. I had one fake AHA moment and but then it was gone again. Not sure what that says about me. Edit and spoiler warning: Looked up the solution and I think the picture is misleading. It implies that pyramid staying on same height.
    - isp 5y ago
      The background of paper with lines is very misleading - because it implies that translation of the pyramid is forbidden, when this translation is the key.
      - mental1896 5y ago
        I agree, although it's not the lines for me but the boundary of the page itself.
        deleted 5y ago
        [deleted]
    - deleted 5y ago
      [deleted]
    - odonnellryan 5y ago
      There is always some kind of consideration like that for these types of trick problems.
- BiteCode_dev 5y ago
  It's a good insight for any transformation really, including change in code: look at what's in common between the desired outcome and the current situation to have an idea how how much work to do.
- odonnellryan 5y ago
  I feel like I'm broken. I got the problem fairly quickly but had no aha moment!
wilburTheDog 5y ago
>Rob Pike of golang fame noted that while he reached for the debugger first thing, Ken Thompson would ignore what Rob was doing and just stand and think. Then after a while he'd say: "I know what's wrong" and very often be right. I feel like this is not a helpful take on debugging for most of us. I'm certainly not as good at this as Ken Thompson, and very seldom is the problem space simple enough that I can hold a complete mental model of it in my head. Instead I reach for the debugger to collect more data on what's going on. And I can usually find the issue by looking a lot faster than I can correctly theorize about it. In Debugging by Davig J. Agans, his third rule is "Quit thinking and look". And I tend to agree. In the majority of cases when I'm debugging a problem the solution only reveals itself when I see that missing piece of information. EDIT: As others have rightly pointed out, if I wrote the code I've already thought about it and have a mental model of what I wrote. And yes, I do think about what could be causing the problem. I guess it's those cases where I think it should be working in a certain way, but it isn't, where I find it most valuable to stop thinking and look. And usually in those cases I either have an incorrect or incomplete model, or I wrote something that didn't match what I was thinking.
- m463 5y ago
  If you wrote the code, there's likely a mental model in your head. This is why it is relatively easy to work on a project you were in on from the beginning. and why it is always a struggle to come into a project with an existing codebase. I've spent many years working on large existing codebases and it gets in the way of liking your job.
  - drewcoo 5y ago
    > there's likely a mental model in your head Yes, and unless there was a simple typo, the problem is the model in your head. Most bugs come from unchallenged assumptions.
    - Jensson 5y ago
      Knowing that a particular bug can happen is usually enough to debug your mental model though. You just trace back to different assumptions you made and see which of them could cause this bug if wrong, and then fix it.
dboreham 5y ago
This is good stuff. I'd add: if you're tussling with what seems to be a very confusing problem, often you are looking at _two_ problems.
ridiculous_fish 5y ago
> Use the debugger sparingly if at all. See if you can use more exotic ways like printfs, dump out data via files, assertions etc just for the sake of getting a wider range of troubleshooting techniques should you find yourself without a debugger someday Often it's the reverse: printfs, data file dumping, etc. are impossible, but the debugger is always there. If you find yourself chasing a bug into glibc or Rust stdlib, printf debugging won't be sufficient. Using a debugger is an underrated skill.
entrep 5y ago
Talk to someone. Tell them about the problem. Show them your previous steps trying to figure it out. Talk about possible solution you've thought of. Share your frustration. Ask them if they have any ideas. When you are done you would have come up with at least one new thing to try.
- nine_k 5y ago
  The other party you talk to need not to be a top-notch engineer. Good results were reported with the use of a rubber duck. With some training, you can talk to a more intelligent counterpart, yourself. One more approach that worked several times for me is to start writing a Stackoverflow question, carefully formulating the problem for the reader who does not have your context. Often I saw the answer before you finish writing, and never posted the question.
  - tharkun__ 5y ago
    I do almost the same. I don't usually use an actual rubber duck or another person and definitely not out on stack overflow but I start writing an explanation for why the bug I'm looking into happens as a reply to the bug ticket and/or ask questions to other people. It keeps evolving as I write down and check hypotheses and validate or invalidate them without ever actually posting the reply. In the end I either have a question left over that I can post or I have a trace of how/why the bug happened and post that, which comes in very handy when people inevitably ask "dumb questions" in the code review on why the fix is what the fix is. It really helps to have these things written down somewhere as you can easily refer back to them as you revert back up the depth first search stack in your head. I guess some people can do this entirely in their head but I can't especially with all the interruptions one has. One of our guys actually had an actual rubber duck sent to them by their employer. This was for a remote only position like 10 years ago by now.
zoomablemind 5y ago
> ...The diffuse mode shuts down when we're stressed. There's no time for dreamy big picture thinking during crunch time... I'd add also that the focused mode often gets you stuck even more under stress. Both approaches are complimentary. This kind of problem solving needs thinking pace, just as if mind were a CPU with a program being weaved in real time, morphing constantly, seeking patterns, eliminating choices. - Hey, Jim, are you sleeping at your desk? - No, Mr. Stone, my mind is thinking! Just be patient and please don't interrupt... On a serious note, under the stress or not, it's important to recognize when one's own mind got stuck. Getting other people involved (as listeners or active participants) is often the only way to get through without exhausting oneself. I wish this was more encouraged in teams, instead of my task must do kind of approach.

80 points by spansoa 5y ago

User23 5y ago

That coin problem is fun. I’m not really familiar with insight problems like this, so it took about a minute to get it.

whatshisface 5y ago
The trick for me was to move one triangle around over the other until only three coins didn't overlap.
- cardanome 5y ago
  I think am misunderstanding the problem because I have convinced myself that it can not have a valid solution. I had one fake AHA moment and but then it was gone again. Not sure what that says about me. Edit and spoiler warning: Looked up the solution and I think the picture is misleading. It implies that pyramid staying on same height.
  - isp 5y ago
    The background of paper with lines is very misleading - because it implies that translation of the pyramid is forbidden, when this translation is the key.
    - mental1896 5y ago
      I agree, although it's not the lines for me but the boundary of the page itself.
      - deleted 5y ago
        [deleted]
  - deleted 5y ago
    [deleted]
  - odonnellryan 5y ago
    There is always some kind of consideration like that for these types of trick problems.
BiteCode_dev 5y ago
It's a good insight for any transformation really, including change in code: look at what's in common between the desired outcome and the current situation to have an idea how how much work to do.
odonnellryan 5y ago
I feel like I'm broken. I got the problem fairly quickly but had no aha moment!

wilburTheDog 5y ago

>Rob Pike of golang fame noted that while he reached for the debugger first thing, Ken Thompson would ignore what Rob was doing and just stand and think. Then after a while he'd say: "I know what's wrong" and very often be right. I feel like this is not a helpful take on debugging for most of us. I'm certainly not as good at this as Ken Thompson, and very seldom is the problem space simple enough that I can hold a complete mental model of it in my head. Instead I reach for the debugger to collect more data on what's going on. And I can usually find the issue by looking a lot faster than I can correctly theorize about it. In Debugging by Davig J. Agans, his third rule is "Quit thinking and look". And I tend to agree. In the majority of cases when I'm debugging a problem the solution only reveals itself when I see that missing piece of information. EDIT: As others have rightly pointed out, if I wrote the code I've already thought about it and have a mental model of what I wrote. And yes, I do think about what could be causing the problem. I guess it's those cases where I think it should be working in a certain way, but it isn't, where I find it most valuable to stop thinking and look. And usually in those cases I either have an incorrect or incomplete model, or I wrote something that didn't match what I was thinking.

m463 5y ago
If you wrote the code, there's likely a mental model in your head. This is why it is relatively easy to work on a project you were in on from the beginning. and why it is always a struggle to come into a project with an existing codebase. I've spent many years working on large existing codebases and it gets in the way of liking your job.
- drewcoo 5y ago
  > there's likely a mental model in your head Yes, and unless there was a simple typo, the problem is the model in your head. Most bugs come from unchallenged assumptions.
  - Jensson 5y ago
    Knowing that a particular bug can happen is usually enough to debug your mental model though. You just trace back to different assumptions you made and see which of them could cause this bug if wrong, and then fix it.

dboreham 5y ago

This is good stuff. I'd add: if you're tussling with what seems to be a very confusing problem, often you are looking at _two_ problems.

ridiculous_fish 5y ago

> Use the debugger sparingly if at all. See if you can use more exotic ways like printfs, dump out data via files, assertions etc just for the sake of getting a wider range of troubleshooting techniques should you find yourself without a debugger someday Often it's the reverse: printfs, data file dumping, etc. are impossible, but the debugger is always there. If you find yourself chasing a bug into glibc or Rust stdlib, printf debugging won't be sufficient. Using a debugger is an underrated skill.

entrep 5y ago

Talk to someone. Tell them about the problem. Show them your previous steps trying to figure it out. Talk about possible solution you've thought of. Share your frustration. Ask them if they have any ideas. When you are done you would have come up with at least one new thing to try.

nine_k 5y ago
The other party you talk to need not to be a top-notch engineer. Good results were reported with the use of a rubber duck. With some training, you can talk to a more intelligent counterpart, yourself. One more approach that worked several times for me is to start writing a Stackoverflow question, carefully formulating the problem for the reader who does not have your context. Often I saw the answer before you finish writing, and never posted the question.
- tharkun__ 5y ago
  I do almost the same. I don't usually use an actual rubber duck or another person and definitely not out on stack overflow but I start writing an explanation for why the bug I'm looking into happens as a reply to the bug ticket and/or ask questions to other people. It keeps evolving as I write down and check hypotheses and validate or invalidate them without ever actually posting the reply. In the end I either have a question left over that I can post or I have a trace of how/why the bug happened and post that, which comes in very handy when people inevitably ask "dumb questions" in the code review on why the fix is what the fix is. It really helps to have these things written down somewhere as you can easily refer back to them as you revert back up the depth first search stack in your head. I guess some people can do this entirely in their head but I can't especially with all the interruptions one has. One of our guys actually had an actual rubber duck sent to them by their employer. This was for a remote only position like 10 years ago by now.

zoomablemind 5y ago

> ...The diffuse mode shuts down when we're stressed. There's no time for dreamy big picture thinking during crunch time... I'd add also that the focused mode often gets you stuck even more under stress. Both approaches are complimentary. This kind of problem solving needs thinking pace, just as if mind were a CPU with a program being weaved in real time, morphing constantly, seeking patterns, eliminating choices. - Hey, Jim, are you sleeping at your desk? - No, Mr. Stone, my mind is thinking! Just be patient and please don't interrupt... On a serious note, under the stress or not, it's important to recognize when one's own mind got stuck. Getting other people involved (as listeners or active participants) is often the only way to get through without exhausting oneself. I wish this was more encouraged in teams, instead of my task must do kind of approach.