3 ms·

I don't believe in rubber-duck debugging as a deliberate practice - you don't know that you'll work out your problem in the process of explaining it. It just ha

I don't believe in rubber-duck debugging as a deliberate practice - you don't know that you'll work out your problem in the process of explaining it. It just happens sometimes.

gosub100 2y ago
more than once, I've typed up several paragraphs on a support forum or Teams message and solved my issue as I laid out all the facts and details.
- cjs_ac 2y ago
  Me too. Explaining something conceptual is a data serialisation problem, and explaining something out loud (regardless of whether anyone is listening) forces you to organise all the relevant information into a form where each additional piece of information makes sense only with the information that preceded it, and doesn't rely on anything succeeding. This reorganisation process is what forms the understanding of how to solve the problem.
  - AndrewOMartin 2y ago
    Not only that but also you often want to anticipate or avoid some common responses so you make special effort to make sure you've tried all common techniques and referenced all available resources. Doing this is often the answer. E.g. It's just not working, I've tried everything I can think of, I looked up the official documentation on this method and... oh, there's a big highlighted paragraph explaining what to do in this situation.
dspillett 2y ago
I find it does, at least for some classes of problem, particularly where there are several details or a sequence of events in play, with some reliability. When problem-solving I tend to jump about a bit, which is often efficient as it gets me thinking about the wider picture and seeing varied parts of it instead of getting locked into a particular detail. This sometimes leads me to missing something slightly obvious, that I keep missing as I rerun through things. Explaining to someone else forces me to organise the diagnostic process so far into a more solid narrative which invariable passes closer to, if not headlong into, the detail I've skipped past previously. Sometimes just pretending I'm explaining to someone else helps the same way, but not always (and hardly ever if I'm a bit manic) because it is too easy to start skipping over bits again where actually talking to someone else (or writing things down) highlights when I'm doing that as the narrative ends up with a gap. Such a gap confuses a human, so they query the skip, or makes the grammar of a written explanation "rub wrong" either immediately or when I read it back. > you don't know that you'll work out your problem in the process of explaining it Of course this isn't 100%, it doesn't help if there isn't a clue to the solution in the gap that gets filled, but it works surprisingly often and usually the gap is because I've simply made an unsafe assumption (such as that a particular detail is not really relevant) and things become massively more obvious when that simple error is undone. > you don't know that you'll work out your problem in the process of explaining it But if you feel you've exhausted other current avenues, it is worth giving it a shot. It is highly unlikely to make the situation any less fixed, unless your rubber duck highlights a larger problem that the problem you think you are debugging is merely a symptom of… I think a similar process is in play when I do the “going for some air” thing, come back, and very quickly see the new vital clue. Having taken the break, the process of getting my head back into the problem space becomes one of quickly re-explaining it to myself. This gives the feeling that the back of my mind, my autopilot, has come up with the answer while I wasn't looking.
Jtsummers 2y ago
> you don't know that you'll work out your problem By this reasoning you must not believe in any debugging techniques (what does it mean to "believe" in a debugging technique anyways?). You don't know that they'll lead you to a solution to your problem. The differential coverage technique posted yesterday? It doesn't work all of the time, or may give you too much to look at to be practical. The statistical variant I posted in that discussion also doesn't always work, it can lead you astray. TDD? Even Kent Beck says to not use it all the time. These things, and rubber duck debugging, do work. That they don't work all the time is immaterial. Are they effective for you and your team? You rotate through techniques while debugging and you select them based on experience. A first pass with that differential coverage technique or a git bisect may be enough. If they don't help right away you go to other techniques. Repeat. Probably even cycling back once you've isolated the issue better. https://research.swtch.com/diffcover https://research.swtch.com/diffcover https://news.ycombinator.com/item?id=43795090 https://news.ycombinator.com/item?id=43795090
cratermoon 2y ago
There are known cognitive processes that come into play when the brain has to turn thoughts into communication, written or verbal. There are different modes, and thinking primarily happens in the Default Mode Network, but rubber ducking activates the language network, articulating thoughts into verbal and written words. This "just happens" is not random nor unexplained: it's a result of the way our brains function, and rubber ducking forces this switch. It's also why various sources recommend writing so much: writing results in learning, or perhaps writing is learning.
mrandish 2y ago
> you don't know that you'll work out your problem in the process of explaining it. For me, the solution doesn't often arrive while I'm explaining the problem but I've had a strong correlation with solutions arriving shortly afterward. As others have said, for at least for some cognitive types (which include me), the process of verbalizing a complex problem activates alternate mental pathways. Explaining it requires curating the domain into what's relevant/not relevant to include, adequately defining terms, surfacing implied assumptions and transforming the mental structure into a linear sequence of explanatory statements. I think the other person actually being there, as opposed to talking to the duck, is an essential element. And I suspect the results tend to improve in proportion to how capable and experienced in the relevant domain the duck holder is - despite not even speaking. The reason is that when I'm thoroughly explaining something complex to someone I know well, that communication requires me to model their prior understanding of the domain, terminology and even the ways they're most likely to engage with the problem. Sure, explaining something to a random stranger who doesn't know the domain can be partially helpful but it's also inefficient because a lot of my mental focus will be spent on explaining enough of the basics to orient a domain novice. Explaining it to someone who not only knows the domain but who I know is smart in exactly the ways likely to lead to solutions, unconsciously forces me to model my knowledge of how they tend to solve problems like these. It's kind of like a turbo version of that old adage "Ask yourself how {experienced domain expert} would solve this".

I don't believe in rubber-duck debugging as a deliberate practice - you don't know that you'll work out your problem in the process of explaining it. It just happens sometimes.

gosub100 2y ago

more than once, I've typed up several paragraphs on a support forum or Teams message and solved my issue as I laid out all the facts and details.

cjs_ac 2y ago
Me too. Explaining something conceptual is a data serialisation problem, and explaining something out loud (regardless of whether anyone is listening) forces you to organise all the relevant information into a form where each additional piece of information makes sense only with the information that preceded it, and doesn't rely on anything succeeding. This reorganisation process is what forms the understanding of how to solve the problem.
- AndrewOMartin 2y ago
  Not only that but also you often want to anticipate or avoid some common responses so you make special effort to make sure you've tried all common techniques and referenced all available resources. Doing this is often the answer. E.g. It's just not working, I've tried everything I can think of, I looked up the official documentation on this method and... oh, there's a big highlighted paragraph explaining what to do in this situation.

dspillett 2y ago

I find it does, at least for some classes of problem, particularly where there are several details or a sequence of events in play, with some reliability. When problem-solving I tend to jump about a bit, which is often efficient as it gets me thinking about the wider picture and seeing varied parts of it instead of getting locked into a particular detail. This sometimes leads me to missing something slightly obvious, that I keep missing as I rerun through things. Explaining to someone else forces me to organise the diagnostic process so far into a more solid narrative which invariable passes closer to, if not headlong into, the detail I've skipped past previously. Sometimes just pretending I'm explaining to someone else helps the same way, but not always (and hardly ever if I'm a bit manic) because it is too easy to start skipping over bits again where actually talking to someone else (or writing things down) highlights when I'm doing that as the narrative ends up with a gap. Such a gap confuses a human, so they query the skip, or makes the grammar of a written explanation "rub wrong" either immediately or when I read it back. > you don't know that you'll work out your problem in the process of explaining it Of course this isn't 100%, it doesn't help if there isn't a clue to the solution in the gap that gets filled, but it works surprisingly often and usually the gap is because I've simply made an unsafe assumption (such as that a particular detail is not really relevant) and things become massively more obvious when that simple error is undone. > you don't know that you'll work out your problem in the process of explaining it But if you feel you've exhausted other current avenues, it is worth giving it a shot. It is highly unlikely to make the situation any less fixed, unless your rubber duck highlights a larger problem that the problem you think you are debugging is merely a symptom of… I think a similar process is in play when I do the “going for some air” thing, come back, and very quickly see the new vital clue. Having taken the break, the process of getting my head back into the problem space becomes one of quickly re-explaining it to myself. This gives the feeling that the back of my mind, my autopilot, has come up with the answer while I wasn't looking.

Jtsummers 2y ago

> you don't know that you'll work out your problem By this reasoning you must not believe in any debugging techniques (what does it mean to "believe" in a debugging technique anyways?). You don't know that they'll lead you to a solution to your problem. The differential coverage technique posted yesterday? It doesn't work all of the time, or may give you too much to look at to be practical. The statistical variant I posted in that discussion also doesn't always work, it can lead you astray. TDD? Even Kent Beck says to not use it all the time. These things, and rubber duck debugging, do work. That they don't work all the time is immaterial. Are they effective for you and your team? You rotate through techniques while debugging and you select them based on experience. A first pass with that differential coverage technique or a git bisect may be enough. If they don't help right away you go to other techniques. Repeat. Probably even cycling back once you've isolated the issue better. https://research.swtch.com/diffcover https://research.swtch.com/diffcover https://news.ycombinator.com/item?id=43795090 https://news.ycombinator.com/item?id=43795090

cratermoon 2y ago

There are known cognitive processes that come into play when the brain has to turn thoughts into communication, written or verbal. There are different modes, and thinking primarily happens in the Default Mode Network, but rubber ducking activates the language network, articulating thoughts into verbal and written words. This "just happens" is not random nor unexplained: it's a result of the way our brains function, and rubber ducking forces this switch. It's also why various sources recommend writing so much: writing results in learning, or perhaps writing is learning.

mrandish 2y ago

> you don't know that you'll work out your problem in the process of explaining it. For me, the solution doesn't often arrive while I'm explaining the problem but I've had a strong correlation with solutions arriving shortly afterward. As others have said, for at least for some cognitive types (which include me), the process of verbalizing a complex problem activates alternate mental pathways. Explaining it requires curating the domain into what's relevant/not relevant to include, adequately defining terms, surfacing implied assumptions and transforming the mental structure into a linear sequence of explanatory statements. I think the other person actually being there, as opposed to talking to the duck, is an essential element. And I suspect the results tend to improve in proportion to how capable and experienced in the relevant domain the duck holder is - despite not even speaking. The reason is that when I'm thoroughly explaining something complex to someone I know well, that communication requires me to model their prior understanding of the domain, terminology and even the ways they're most likely to engage with the problem. Sure, explaining something to a random stranger who doesn't know the domain can be partially helpful but it's also inefficient because a lot of my mental focus will be spent on explaining enough of the basics to orient a domain novice. Explaining it to someone who not only knows the domain but who I know is smart in exactly the ways likely to lead to solutions, unconsciously forces me to model my knowledge of how they tend to solve problems like these. It's kind of like a turbo version of that old adage "Ask yourself how {experienced domain expert} would solve this".