Talking about a problem helps (software developing)

Question

I am 42 and doing software developer since 20 years.

Since several years I know that talking about a problem helps.

If I can't find a an easy solution myself I talk to a team mate or ask at a site like stackoverflow.

Often it is enough to speak about it (or write the question). If I do this, I often find the solution myself.

I would like to find a matching term (from psychology or neuroscience) for this.

Question: How do you call this?

If you have links to related studies, please leave a comment. Thank you.

Answer 1

I can think two reasons why talking about a problem helps :

• Explaining your knowledge can reveal gaps and bugs

The following extract is from the book Smart Thinking by Art Markman :

• Talking about a problem changes its mental representation

Our mental representation is the ideas, concepts, stories, theories, and skills that make up how we internalize something in our mind. Gardner writes:

“Generically, mind change entails the alteration of mental representations. All of us develop mental representations quite readily from the beginning of life. Many such representations are serviceable, some have notable charm, others are misleading or flatly wrong. Mental representations have a content: we think of these contents as ideas, concepts, skills, stories, or full-fledged theories (explanations of the world). These contents can be expressed in words — and in a book, that medium is customarily used. However, nearly all contents can be expressed in a variety of forms, media, symbol systems: these systems can be exhibited publicly as marks on a page and can also be internalized in a ‘language of the mind’ or a particular ‘intelligence.’”

The mere fact of trying to formulate our thinking into speech, changes its representation (see this article).

Answer 2

Well, first of all, let's briefly discuss the process of thinking.

Lone, silent thinking is the internalization of words taught to you at a very young age. Clinical literature suggests that if you miss learning period you cannot learn it anymore. Feral Child Wikipedia

Speculation: Based on this, I strongly believe that understanding words and speaking came earlier in our evolutionary process than thinking. This posits the idea that we're better at discussing things in social settings than thinking them internally.

Now, writing obviously came later than understanding words, speaking words and thinking, however, it is a bit different than thinking. When you are writing you externalize something within and actually look at it, which entirely changes the perception of the subject.

Also, to further my point. As I mentioned above, thinking is the internalization of a conversation and it is really hard to think properly because it requires you to activate different parts of your personality that can actually argue/communicate as you would in a normal conversation. Technically speaking in order to think properly you need to create a cognitive dissonance otherwise it is going to be confirmation bias.

It's also useful to bring in terms such as subconscious and conscious. Carl Jung thought that those two exist 'in different dimensions'. You can attribute symbolic and metaphorical aspects of your psyche to the subconscious, while the verbal aspect of your mind is conscious. In other words, there is a difference between unarticulated and articulated knowledge.

Unarticulated knowledge is somewhat subconscious, so you do not have full access to it, however, if you manage to articulate it - you gain full access. Thinking is a quick process and thoughts might slip away while writing is slower and you actually perceive, correct yourself and rectify the issues as you go through. (Same applies to the communication except there are two or more heads instead of one.)

Answer 3

I found this related Wikipedia article:

https://en.wikipedia.org/wiki/Rubber_duck_debugging

Rubber duck debugging

In software engineering, rubber duck debugging or rubber ducking is a method of debugging code. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck.[1] Many other terms exist for this technique, often involving different inanimate objects.

Many programmers have had the experience of explaining a problem to someone else, possibly even to someone who knows nothing about programming, and then hitting upon the solution in the process of explaining the problem. In describing what the code is supposed to do and observing what it actually does, any incongruity between these two becomes apparent. More generally, teaching a subject forces its evaluation from different perspectives and can provide a deeper understanding. By using an inanimate object, the programmer can try to accomplish this without having to interrupt anyone else.