[HN Gopher] Thank you for holding my duck (2021)
___________________________________________________________________
Thank you for holding my duck (2021)
Author : jxmorris12
Score : 61 points
Date : 2025-04-26 13:56 UTC (9 hours ago)
(HTM) web link (naml.us)
(TXT) w3m dump (naml.us)
| immibis wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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://news.ycombinator.com/item?id=43795090
| cratermoon wrote:
| 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 wrote:
| > 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".
| OliverWales wrote:
| I'm not sure where I first heard of rubber duck debugging, but in
| my experience there is rarely a physical rubber duck at all. It's
| more of a "can I rubber duck you on something for a minute?"
| "Yea, sure!" "<starts explaining> ... ah I've figured it out
| cheers".
| frereubu wrote:
| This frequently happens to me in the middle of writing a support
| ticket, which I try to make as detailed as possible for that
| specific purpose.
| mizzao wrote:
| More generally, does this process work similarly if you just
| try to express your problem in writing instead of trying to
| explain it verbally?
| frereubu wrote:
| I think writing is more effective because it makes me slow
| down and more considered in how I write things. On reflection
| as I write this, I think it often happens when editing the
| message to make it as precise as possible - forcing myself to
| explain everything explicitly often causes the lightbulb
| moment.
| chickensong wrote:
| IMHO, this is one of the biggest benefits of leaning into
| writing good stories in a project tracker. Even if the the
| light bulb moment that solves everything doesn't appear
| immediately, distilling your work into clear, precise
| language, suitable for consumption by parties who may not
| be intimate with the issue, strongly reinforces your
| understanding. It saddens me that there's a pervasive
| culture of looking down on this type of work, when there
| are clear benefits.
| mrandish wrote:
| That's not only a lovely story, it also holds useful insights
| about effective problem solving and collaboration (or when the
| best collaboration is just listening).
|
| There's a different but somewhat related "no response necessary"
| communication technique my wife and I discovered. This occurred
| when she would share a problem she'd recently faced with me.
| Being an engineer, I'd listen to the problem and then helpfully
| try to suggest possible solutions. Sometimes this was fine but on
| other occasions, she'd seem to just disconnect or even get
| frustrated. But which way things went didn't seem dependent on
| the usefulness of my answer.
|
| The realization came one day when I was kind of disappointed that
| the comprehensive rank-ordered list of possible solutions I'd
| helpfully provided only got an annoyed and frustrated non-
| response. So I pushed back and asked what answer she was looking
| for. This caused her to erupt and exclaim "I _just_ needed you to
| say _' That's terrible, honey.'_" and then she stormed off. This
| was a shocking revelation for me.
|
| We discussed it more calmly later and, sure enough, _sometimes_
| she was relating the problems she 'd confronted not because she
| wanted solutions but because she felt a need for understanding,
| empathy and connection. Ah! That's the day I learned to consider
| (or sometimes even ask) which kind of problem statement this is -
| and that lets me respond with either solution suggestions or a
| heartfelt "That's terrible, honey." This has made life better.
| brewtide wrote:
| Regardless of engineering background or not, I do believe this
| is a major different between men and women in general.
|
| I know I'm guilty of the same thing and I'm positive many
| others here have had very similar experiences.
|
| IN GENERAL, it seems when guys talk to someone else, they are
| likely looking for input into a situation. If we didn't want
| input, we would just sit and ruminate in our own personal
| thoughts processes.
|
| Your story is also a great lesson in why communication is key -
| unfortunately it takes both parties to realize this!
| low_tech_love wrote:
| Although the whole idea of "figuring out the solution by
| explaining the problem" is absolutely real, I find that the
| problem for me with this is that the duck is (and always will be)
| an obvious stand in for something else; a gimmick of sorts. It
| just doesn't work for me as a suspension of disbelief. I need to
| _believe_ that my explanation is actually useful and necessary
| for the other person to help me. This happened to me a lot back
| in the days when stack overflow was the go-to place for
| programming help. I think the vast majority of my questions there
| I figured out by myself immediately after posting, but only
| because I actually believed that someone there (a) could actually
| help me and (b) for them to do it they needed me to be very clear
| in my explanation.
| failrate wrote:
| I argue that verbalizing to the duck without involving another
| person solves many problems just by itself. Deeper problems may
| require verbalizing it to a person. In my professional
| experience, I have lost vast amounts of time and attention to
| people who would break my flow state to explain the problem to me
| and figure it out themselves while verbalizing it for the very
| first time. So, I explained Rubber ducking to them and gave them
| all ducks. It worked wonderfully.
| wkat4242 wrote:
| This story has such a different feeling about it since the rise
| of auto correct, lol. It's the first thing I thought of when I
| read the title. I was a bit disappointed it was utterly harmless.
| Though I'm surprised how far back the rubber ducking habit goes.
|
| Also someone sent me that meme "Dear Autocorrect. It's never
| 'duck'." recently :) It was still fresh in the back of my mind.
| Also I'm a super "open" person when it comes to such matters and
| activities. So I have a very dirty mind :)
| felineflock wrote:
| Sometimes posting my problem/question in Slack causes me to
| figure out the solution by myself not too long after.
|
| It feels like God wants me to expose my ignorance/inability in
| public first and only then reward my "humility" with a solution
| directly in my brain.
| twodave wrote:
| In truth, rubber-ducking doesn't even require anyone to listen. I
| find this practice of "step back and describe the system again"
| to be useful anytime an assumption changes, though I guess it
| isn't limited to that. In my own work change of
| assumptions/requirements is pretty frequent, so I often find
| myself wanting to just step back and re-evaluate the system based
| on that new information. If you can take even a fragment of your
| problem space and go "end to end" on it logically, then you've in
| many cases given yourself a reference to work from, and now you
| can go off and make changes to align your work to that logic with
| confidence. And then you've also made yourself a decent test
| scope, so you can verify your logic and iterate on it.
|
| If I get to the end of all that and still have questions then
| I'll bring someone else in, usually just for a fresh perspective,
| though.
___________________________________________________________________
(page generated 2025-04-26 23:00 UTC)