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.
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!
I think you're right that men and women (tend to) have different responses to someone venting to them, and different tendencies in when and who to vent to, but I think both (tend to) prefer the listening approach when they are venting. It's kind of like writing in that the benefit is in being open and being able to reflect on that openness. In addition to openness, just having someone to vent to brings the comfort of human connection.
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.
Composing an email works. Start writing about the problem, and as you write, imagine the (adversarial?) comeback: Did you try A? B? C? Have you considered D or E? Do you know about F?
Numerous times IME, from this process of message composition has emerged a solution.
This is what I do—it can even be a detailed slack message. I start writing the message with the goal of asking for some guidance, but in the process of carefully outlining the problem and what I’ve already attempted (in order to respect the time of my colleague) I usually arrive at the correct solution. I then delete the email without ever needing to send it.
I started off on mailing lists (openldap was a big one for me). And my first pleas for help were often met with some pretty brutal scathing replies. I learned to really write up the problem, reduce it to its point. Go back to it so I could find the most concrete path to either reproduce it, or isolate it. This often led to the solution, or it led to getting some confirmation of bugs. Granted I definitely ended up making some verbose emails and then I would get frustrated with people asking me to try things I detailed in my email.
But that was my "rubber duck debugging". Start by writing an email to to an imagined hostile support group. In the process of explaining the problem, it turns into a research project where I have to defend my claims. The sheer act of writing it out forces me to isolate the issue and keep troubleshooting. I can anticipate the bulk of the things they would have me try and I'd try them ahead of time.
People encountered similiar pushback with stack overflow, but I think the stack sites were much more lenient than some of those early mailing lists were.
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.
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.
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.
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 :)
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.
Dang, sometimes the world seems so small. I know one of the names mentioned in the article. And while this was before the duck was known, we did have conversations like that. Communication with another person can really help with figuring out the problem yourself.
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".
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.
> 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.
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.
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.
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.
> 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 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.
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.
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!
I think you're right that men and women (tend to) have different responses to someone venting to them, and different tendencies in when and who to vent to, but I think both (tend to) prefer the listening approach when they are venting. It's kind of like writing in that the benefit is in being open and being able to reflect on that openness. In addition to openness, just having someone to vent to brings the comfort of human connection.
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.
Composing an email works. Start writing about the problem, and as you write, imagine the (adversarial?) comeback: Did you try A? B? C? Have you considered D or E? Do you know about F?
Numerous times IME, from this process of message composition has emerged a solution.
This is what I do—it can even be a detailed slack message. I start writing the message with the goal of asking for some guidance, but in the process of carefully outlining the problem and what I’ve already attempted (in order to respect the time of my colleague) I usually arrive at the correct solution. I then delete the email without ever needing to send it.
Putting it into words, methodically, structuredly, seems to do the trick eh
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.
I started off on mailing lists (openldap was a big one for me). And my first pleas for help were often met with some pretty brutal scathing replies. I learned to really write up the problem, reduce it to its point. Go back to it so I could find the most concrete path to either reproduce it, or isolate it. This often led to the solution, or it led to getting some confirmation of bugs. Granted I definitely ended up making some verbose emails and then I would get frustrated with people asking me to try things I detailed in my email.
But that was my "rubber duck debugging". Start by writing an email to to an imagined hostile support group. In the process of explaining the problem, it turns into a research project where I have to defend my claims. The sheer act of writing it out forces me to isolate the issue and keep troubleshooting. I can anticipate the bulk of the things they would have me try and I'd try them ahead of time.
People encountered similiar pushback with stack overflow, but I think the stack sites were much more lenient than some of those early mailing lists were.
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.
More generally, does this process work similarly if you just try to express your problem in writing instead of trying to explain it verbally?
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.
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.
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.
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 :)
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.
Dang, sometimes the world seems so small. I know one of the names mentioned in the article. And while this was before the duck was known, we did have conversations like that. Communication with another person can really help with figuring out the problem yourself.
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".
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.
> 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
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.
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.
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.
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.
> 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 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.
Sounds like a Tom Green bit.