Hablar de un problema ayuda (desarrollo de software)

Puedo pensar en dos razones por las que hablar de un problema ayuda:

• Explicar su conocimiento puede revelar lagunas y errores

El siguiente extracto es del libro Smart Thinking de Art Markman:

• Hablar de un problema cambia su representación mental

Nuestra representación mental son las ideas, conceptos, historias, teorías y habilidades que componen cómo interiorizamos algo en nuestra mente. Gardener escribe:

“Genéricamente, el cambio mental implica la alteración de las representaciones mentales. Todos nosotros desarrollamos representaciones mentales con bastante facilidad desde el comienzo de la vida. Muchas de estas representaciones son útiles, algunas tienen un encanto notable, otras son engañosas o completamente erróneas. Las representaciones mentales tienen un contenido: pensamos en estos contenidos como ideas, conceptos, habilidades, historias o teorías completas (explicaciones del mundo). Estos contenidos se pueden expresar en palabras, y en un libro, ese medio se usa habitualmente. Sin embargo, casi todos los contenidos pueden expresarse en una variedad de formas, medios, sistemas de símbolos: estos sistemas pueden exhibirse públicamente como marcas en una página y también pueden interiorizarse en un 'lenguaje de la mente' o una 'inteligencia' particular. ”

El mero hecho de intentar formular nuestro pensamiento en discurso, cambia su representación ( ver este artículo ).

Bueno, antes que nada, analicemos brevemente el proceso de pensar.

El pensamiento solitario y silencioso es la internalización de las palabras que le enseñaron a una edad muy temprana. La literatura clínica sugiere que si pierde el período de aprendizaje, ya no podrá aprenderlo. Niño salvaje en Wikipedia

Especulación: Basado en esto, creo firmemente que entender palabras y hablar vino antes en nuestro proceso evolutivo que pensar. Esto postula la idea de que somos mejores discutiendo cosas en entornos sociales que pensando internamente.

Ahora, escribir obviamente vino después que entender palabras, hablar palabras y pensar, sin embargo, es un poco diferente a pensar. Cuando estás escribiendo, exteriorizas algo interior y realmente lo miras, lo que cambia por completo la percepción del tema.

Además, para avanzar en mi punto. Como mencioné anteriormente, pensar es la internalización de una conversación y es realmente difícil pensar correctamente porque requiere que actives diferentes partes de tu personalidad que realmente pueden discutir/comunicarse como lo harías en una conversación normal. Técnicamente hablando, para pensar correctamente, debe crear una disonancia cognitiva; de lo contrario, será un sesgo de confirmación.

También es útil incluir términos como subconsciente y consciente. Carl Jung pensó que esos dos existen 'en diferentes dimensiones'. Puedes atribuir aspectos simbólicos y metafóricos de tu psique al subconsciente, mientras que el aspecto verbal de tu mente es consciente. En otras palabras, hay una diferencia entre conocimiento no articulado y articulado.

El conocimiento no articulado es algo subconsciente, por lo que no tienes acceso completo a él, sin embargo, si logras articularlo, obtienes acceso completo. Pensar es un proceso rápido y los pensamientos pueden escabullirse mientras que escribir es más lento y realmente percibes, te corriges y rectificas los problemas a medida que avanzas. (Lo mismo se aplica a la comunicación, excepto que hay dos o más cabezas en lugar de una).

Encontré este artículo relacionado de Wikipedia:

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

Depuración de pato de goma

En ingeniería de software, la depuración de patitos de goma o el patito de goma es un método de depuración de código. El nombre es una referencia a una historia en el libro El programador pragmático en el que un programador llevaría un pato de goma y depuraría su código obligándose a explicárselo, línea por línea, al pato.[1] Existen muchos otros términos para esta técnica, a menudo relacionados con diferentes objetos inanimados.

Muchos programadores han tenido la experiencia de explicar un problema a otra persona, posiblemente incluso a alguien que no sabe nada de programación, y luego encontrar la solución en el proceso de explicar el problema. Al describir lo que se supone que debe hacer el código y observar lo que realmente hace, se hace evidente cualquier incongruencia entre estos dos. De manera más general, la enseñanza de una materia obliga a su evaluación desde diferentes perspectivas y puede proporcionar una comprensión más profunda. Mediante el uso de un objeto inanimado, el programador puede intentar lograr esto sin tener que interrumpir a nadie más.