Programmers often discover solutions while explaining a problem to someone else, even to people with no programming knowledge. Describing the code, and comparing to what it actually does, exposes inconsistencies. Explaining a subject also forces the programmer to look at it from new perspectives and can provide a deeper understanding.
Isn’t that just brainstorming?
No. Brainstorming is when you’re with a group and everyone is throwing out ideas unfiltered.
Rubber duck debugging is when you are trying to solve an issue by describing your problem to another person (or a rubber duck) and through the act of describing the problem you gain a better understanding of the issue and often this causes you to get a ‘eureka moment’ where the solution is suddenly clear to you.
I mean in my line of work that is the collaboration process. Our problems are not in “debugging”. However it’s real solutions to problems. We discuss ideas and execute the one we feel is best. Quite often these discussions create that moment you speak of. Perhaps it’s nuanced to programming.
I’d say brainstorming is what you do before writing code and rubber ducking is what you do to debug code that you’ve already written.
They also work kinda differently. Brainstorming an idea is different from explaining it out loud, detail by detail.