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.
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.
No, it isn’t nuance. You are describing a completely different part in the process.
Rubber ducking is after you decided on a solution to a problem that you know should work but it isn’t working the way you expect. “Why isn’t the change I am making doing the thing? It works on the other site and oh shoot I forgot to add in the workaround for our goofy environment.”
I don’t see the extreme difference you seem to make it out to be. There are plenty of instances in my industry where something should work but needs to be adjusted to work correctly.
I still see it as brainstorming. But if coders need their own thing, cool.