My theory on this is that it does use a bunch of wiring used for social behaviour. An important part of social behaviour is reputation and an important part of reputation is how often we make incorrect statements.
So when we're about to communicate some information to someone else, we run a bunch of extra checks on the information we are about to impart. If we didn't do so, we could lose reputation for accuracy (which could have negative implications socially).
Basically I think we have all information in our heads tagged with meta-data which describes how confident we are in the information. We essentially check these tags when we pass on the info to other people. (This helps show up the invalid assumption which has been stalling our problem solving process).
Interestingly, they'll label the trustworthiness of the information we give them with their own determination of our trustworthiness as an information source (possibly modified for topic etc).
(And to add to the list of names people have for this widespread behaviour, I call it "debugging by confession")
"You can also write an email to a mailing list or newsgroup. While you will not have the acoustic feedback in this case, at least it forces you to bring your thoughts into order. So in 90% you will not need to send the email because you've already found the solution. In the remaining 10% you can just send your posting."
So very true. I'm endlessly annoyed by coworkers who come up with questions when they haven't yet worked through the problem in their mind. Regularly in the process of writing out an e-mail containing my question, I notice an assumption I made or step I ignored. Failing that, the process gives me time to think of a way to figure out the problem my self, with a test program or scenario.
The nice thing about externalizing the process is that it almost inspires you to ask questions that 'someone else' might ask, but that you almost certainly wouldn't! Schizoid? Perhaps - but quite useful.
I've written many posts to newsgroups and mailing lists asking for help with my programming problems over the years. I've only actually posted/sent less than 5% of those.
Infrequently, in extreme cases, I've actually written out a full dialog with myself. It can get confusing, but occasionally is a good trick to expose hidden assumptions or lack of perspective in a particulalry vexing quandry.
More commonly, I try to write a statement of the problem to myself, kind of emulating the process of writing to a newsgroup.
My theory is that as our brains evolved, many of the complex problems they faced were social. Communicating ideas to somebody else probably uses different parts of the brain than solitary thinking does. It's best when the listener has good ideas, but sometimes just the act of communicating the problem can get you unstuck.
Anthropomorphising parts of a problem ("this object is trying to send this message to this other one, but it isn't getting through") can be useful, for the same reason.
I'm in the process of writing a book. One thing that's very hard is to reread each chapter to make sure it flows. Once you've been over the text again and again it's hard to get a fresh perspective.
What's working for me is to read the text out loud. I don't actually read it to someone, but clearly speaking out loud has helped.
I explained this to my fiancee, who is a counselor with a masters in social work. I don't think it's made a difference, other then allowing me to occasionally quack for a response (to get a laugh) when she's taking to me.
She prefers for me to take the place of the rubber duck anyway, because I'll "quack" out a valuable suggestion that she hadn't considered maybe a 3rd of the time. Apparently I'm just too helpful.
I suspect it works far better with computers and programming because we're trying to solve a specific issue that doesn't involve feelings and group politics. Further more, it seems to make a psychological difference when a person is listening, as opposed to just talking to an object. On the other hand, it could just be because of her career.
I think this works because when we don't have to formalize (through speech or writing) our concept of the problem, our thinking is allowed to be less rigorous. We think we understand something, so we skip over it in our mind. Only when we formalize our thoughts do we realize our understanding isn't as complete as we thought.
Also, since we have to make sure our audience (duck) knows everything we know, we have to revisit concepts that perhaps we haven't thought about for a while.
A friend and I were talking the other day about teaching software architecture. He was telling me that he was able to teach all the details of the work, and why everything was important. What he couldn't teach was that "ah-ha!" moment that occurs during planning.
I told him the secret was that you continue to describe and refine your definitions of the problem. That's how "ah-ha" moments work.
So when we're about to communicate some information to someone else, we run a bunch of extra checks on the information we are about to impart. If we didn't do so, we could lose reputation for accuracy (which could have negative implications socially).
Basically I think we have all information in our heads tagged with meta-data which describes how confident we are in the information. We essentially check these tags when we pass on the info to other people. (This helps show up the invalid assumption which has been stalling our problem solving process).
Interestingly, they'll label the trustworthiness of the information we give them with their own determination of our trustworthiness as an information source (possibly modified for topic etc).
(And to add to the list of names people have for this widespread behaviour, I call it "debugging by confession")