This made me think of rubber duck problem solving [1][2], though it didn't mention it specifically. Talking through a problem out loud forces you to structure your thoughts in a logical way, and sometimes doing that you'll realize an obvious connection or step you missed.
For me, it isn't even vocalizing - I discovered that forcing things into words helps me troubleshoot after noticing that I solved my own problems after giving up and composing an email to someone to ask for help. The act of describing the problem in written form allowed me to see what I was missing.
Since noticing that, I started doing it fairly, and not just with programming. At some point, I realized I was keeping a (somewhat oddly structured) journal.
When writing SO questions I tend to only press the submit button 5–10% of the time before realising my error (typically something mundane). The act of putting the problem into words, along with writing up a good background of the problem (as you should for a good question) often forces an objective viewpoint/reevaluation of the problem.
Damn. I thought I was the only one who does this :'D
On a serious note, this effect can be applied to our everyday problem as well. Such as when you are feeling lethargic, you'd want to write down all of your thoughts in a list to see the bigger picture and figure out how simple it can be to finish a task at hand.
s/lethargic/anxious/, and I do this all the time! Doing a quick mind dump usually clears out my anxiety, or at least reduces it to a manageable level, allowing me to continue doing things.
You should check out the book "Getting Things Done", which is based on taking what you described and using it to stay organized and adaptable. If you've got anxiety it would probably help at least a little bit.
This makes me wonder what the bounce rate for Stack Overflow questions is and what percent of visitors actually make it through the submission process.
If they have a big enough database of half-typed-then-abandoned questions, do you think it would be possible to train an RNN (or something) to read a post in progress and predict at what point the answer should be obvious to you?
I seem to recall something similar which does pattern matching comparing the code that you're typing with a database of code in accepted stackoverflow answers and gives "smart autocomplete". Not sure how I stand on the overall impact of such a thing but technically it was cool. :)
On the other hand in the past year especially my experience has been I am asking something for which the documentation is very bad, I don't know enough about the particular problem area I am trying to solve to make a concise description with code examples that nearly work but don't, and as a consequence I just drop it and say it's not worth asking here because nobody will help you understand the problem area unless you understand it really well. Too bad SO has replaced user groups in so many cases.
Writing things down - or sketching or using mind-maps (not software but actually drawing your own manually) - seems to have an amazing effect on the brain.
We haven't been writing long (in evolutionary terms) so I wonder why that is?
I think it's because our brains are good at manipulating tangible things - it's what they've been doing since before we had a neocortex, after all. Making thoughts tangible, sensory experiences can help engage the full machinery of the brain, instead of just limiting it to higher brain functions.
I think that the stuff in our mind is mostly abstract. We absorb things from the world all the time, conscious and unconscious, and make conscious and unconscious connections between them.
Thinking aloud, whether in the mind, on paper or even vocally, helps us to identify some of these points, and thus quantify a meaning from it. There's only so many points that we can mentally hold though - we're not good multi-taskers after all! So the better we can think aloud, the better we can consciously grab thoughts and identify the real gaps - which we can fill in by searching/ creating more points in our mind, or go external.
This might be splitting hairs, but I think hearing/reading my own question is more important than the act of writing down the problem.
I theorize that words you hear/read pass through some part of the brain specialized in finding answers, that is not engaged during regular problem solving.
I do this with writing. Even if the problem has 3 points, I write down a list on the whiteboard. Even if the part of the system I'm concerned about has two components, I draw two boxes with a connecting line. Then I stare at the board. It's surprising how effective this can be.
Edit: I suspect Sherlock Holmes was the first fictional character to employ rubber-ducking (albeit with Watson as the duck). Greg House would be a more recent example (who uses his entire team).
It seems to have a lot of positive press, and it works for me--though I'm cautious of talking to myself at work before knowing if it would come across negatively.
I learned to do my self talk in writing. I just switch to Emacs and start typing (either in my project "notebook", general "mind dump" file, or a throwaway buffer).
These days I actually feel I'm worse at talking to myself in my head than I am in talking to myself via a keyboard.
I don't buy the whole "if you hear it you'll see it" thing for coding - unless you're used to saying things you're working on I guess, but I'm not. I can see the extra focus it could bring because you're spending more effort in vocalizing your thoughts and it's going trough different systems as well (physically hearing yourself speak).
I've tried both and you can talk yourself trough the problem inside of your head step by step just as effectively when it comes to coding tasks IMO.
Immediate problem solving/planning like "OK I need to do this then this" is a different story - saying stuff out loud helps here.
What percentage of your problems do you end up solving either with rubber ducky debugging or just in the process of explaining them to someone else? I feel like 80% of the things I can't figure out on my own are solved once I start to explain them.
[1] https://en.m.wikipedia.org/wiki/Rubber_duck_debugging
[2] http://hwrnmnbsol.livejournal.com/148664.html