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.
Jtsummers · 41m 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.
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.
gosub100 · 1h 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 · 1h 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 · 1h 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.
cratermoon · 36m 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.
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://news.ycombinator.com/item?id=43795090
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.
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.
It's also why various sources recommend writing so much: writing results in learning, or perhaps writing is learning.