Del código en blanco al andamiaje cognitivo

Dos memorias

La psicología cognitiva distingue dos sistemas de memoria. El primero es el espacio donde sostenemos y manipulamos lo que estamos pensando en este momento: el número de teléfono que acabamos de escuchar, los pasos de una cuenta que hacemos de cabeza. Es muy limitado y se satura rápido. Miller (1956) estimó que retiene unos siete elementos; Cowan (2001) revisó la evidencia y bajó la cifra a unos cuatro.

Baddeley y Hitch (1974) mostraron que no es un simple depósito, sino un sistema activo que procesa información, y lo describieron como memoria de trabajo. El segundo sistema guarda todo lo que sabemos y, en la práctica, no tiene límite: es la memoria de largo plazo.

Lo que sabemos se guarda organizado

La memoria de largo plazo no guarda piezas sueltas: organiza el conocimiento en estructuras que agrupan muchos elementos y que se recuperan como si fueran uno solo. Bartlett (1932) llamó esquemas a estas estructuras.

Para una docente de programación, for i in range(10): es una sola idea. Para quien la ve por primera vez son siete u ocho piezas sin relación entre sí, y cada una ocupa un lugar en la memoria de trabajo.

El esfuerzo que exige una tarea

Sweller (1988) reunió estas ideas en una teoría: toda tarea exige un esfuerzo a la memoria de trabajo, y si ese esfuerzo supera su capacidad, no queda espacio para aprender. Llamó a ese esfuerzo carga cognitiva. Sweller, van Merriënboer y Paas (1998) distinguieron después tres fuentes:

• la que viene de la complejidad propia del contenido, que tiene muchos elementos que interactúan (carga intrínseca);
• la que agrega una tarea mal diseñada o una presentación confusa, y que no ayuda a aprender (carga extrínseca);
• la que se dedica a construir esquemas, que es la que buscamos (carga pertinente).

Por qué el editor en blanco es la tarea de máxima carga

Escribir un programa desde una pantalla vacía obliga a sostener a la vez el problema, un plan de solución, la sintaxis del lenguaje y una idea de cómo se ejecutará el código. Quien programa con experiencia agrupa todo eso en pocos esquemas; el o la joven estudiante todavía no los tiene y debe sostener cada pieza por separado.

Sweller y Cooper (1985) compararon a estudiantes que resolvían problemas de álgebra con otros que estudiaban los mismos problemas ya resueltos: los segundos aprendieron más y en menos tiempo. A este resultado se lo conoce como efecto del ejemplo resuelto.

Un debate abierto: ¿cuánta guía?

Kirschner, Sweller y Clark (2006) sostuvieron que las propuestas con guía mínima, en las que se espera que se descubra por cuenta propia, no funcionan con quienes recién empiezan, justamente porque sobrecargan la memoria de trabajo.

Hmelo-Silver, Duncan y Chinn (2007) respondieron que el aprendizaje basado en problemas y en indagación sí logra buenos resultados cuando incluye apoyos bien diseñados. Las dos posiciones coinciden en algo: la clave está en el apoyo.

El apoyo que se retira

Vygotsky (1978) describió la distancia entre lo que una persona puede hacer sola y lo que puede hacer con la ayuda de alguien con más experiencia, y la llamó zona de desarrollo próximo: es allí donde la enseñanza tiene más efecto.

Wood, Bruner y Ross (1976) observaron a una tutora que ayudaba a niñas y niños de 3 a 5 años a armar una pirámide de bloques. La ayuda eficaz se hacía cargo de las partes de la tarea que todavía no podían resolver, para que se concentraran en las que sí podían, y se retiraba a medida que ganaban dominio. Tomaron una imagen de la construcción para nombrarla: andamiaje (en inglés, scaffolding).

Por eso no se trata de «nunca escribir», sino de no empezar por escribir: empezar leyendo código que funciona y sostener cada tarea con apoyos que se retiran de a poco.

Para recordar

Carga cognitiva

Esfuerzo que una tarea exige a la memoria de trabajo. Puede venir del contenido (intrínseca), de un mal diseño de la tarea (extrínseca) o de la construcción de esquemas (pertinente).

Andamiaje

Apoyo temporal que se hace cargo de lo que la persona todavía no puede hacer sola y se retira a medida que gana dominio.

Seguir el código a mano

Imagina que tomas un programa y lo ejecutas tú, en papel: lees la primera línea, anotas qué valor queda guardado, pasas a la siguiente, decides si una condición se cumple, vuelves al comienzo del bucle. No adivinas el resultado: lo construyes paso a paso.

A esta práctica se la llama trazar el código (en inglés, tracing).

Lo que encontraron los estudios entre países

McCracken y colegas (2001) pidieron a estudiantes de primer año de universidades de varios países que escribieran programas sencillos: la mayoría no lo logró. Lister y colegas (2004) se preguntaron si el problema empezaba antes de escribir y, en otro estudio entre países, pidieron leer y trazar fragmentos cortos: muchos estudiantes tampoco pudieron.

Lopez, Whalley, Robbins y Lister (2008) y Venables, Tan y Lister (2009) midieron en las mismas personas la capacidad de trazar, de explicar y de escribir código, y encontraron que se relacionan: quienes no trazan ni explican bien tienden a escribir peor. Venables y colegas agregaron un matiz: la relación no es lineal, porque trazar bien es necesario, pero no suficiente, para escribir bien.

Una idea de cómo funciona la máquina

Para anticipar qué hará un programa hace falta una representación interna de cómo funciona la computadora al ejecutarlo. La psicología llama modelo mental a la representación interna que una persona tiene de cómo funciona algo (Johnson-Laird, 1983).

Trazar es la forma de construir ese modelo y de ponerlo a prueba.

Etapas en el razonamiento de quien aprende a programar

Piaget (1952) describió el desarrollo del pensamiento como una sucesión de etapas, en las que el razonamiento pasa de depender de la acción y de lo concreto a manejar ideas abstractas.

Lister (2011) propuso que al aprender a programar se recorre algo parecido, a cualquier edad: primero la persona no logra seguir con precisión lo que hace el código; después lo sigue, pero no ve el programa como un todo; más tarde razona sobre el programa completo y puede abstraer. Por tomar el modelo de Piaget y aplicarlo a un dominio nuevo, este enfoque se llama neopiagetiano. Su consecuencia para el aula es directa: quien todavía no traza con precisión no está en condiciones de abstraer ni de crear.

Programas que funcionan por casualidad

Perkins, Hancock, Hobbs, Martin y Simmons (1986) observaron a estudiantes mientras programaban y describieron un estilo frecuente: ajustar el código probando cambios hasta que funcione, sin una idea clara de lo que hace la computadora. Lo llamaron tinkering, algo así como «ir retocando». Un programa que funciona, entonces, no garantiza que haya comprensión.

Aprender a programar es acumulativo en dos sentidos: cada concepto (variable, condicional, bucle, función) se apoya en el anterior, y escribir se apoya en saber leer. Por eso conviene priorizar la comprensión lectora de código sobre la escritura a ciegas.

Para recordar

Trazar

Ejecutar un programa a mano, línea por línea, registrando cómo cambian los valores y decidiendo cuál es la línea siguiente.

Modelo mental

Representación interna de cómo funciona algo; en programación, de cómo la computadora ejecuta un programa.

Aprender primero con otras personas

Vygotsky (1978) sostuvo que las funciones mentales superiores aparecen dos veces en el desarrollo: primero entre personas, en la interacción mediada por el lenguaje, y después dentro de cada persona. Al primer momento lo llamó plano interpsicológico (o social) y al segundo, plano intrapsicológico (o individual). Al pasaje de uno a otro lo llamó internalización.

El lenguaje es la herramienta que lo hace posible: al poner en palabras lo que hace un programa, cada estudiante organiza su propio pensamiento.

Cuando lo esperado choca con lo que ocurre

Posner, Strike, Hewson y Gertzog (1982) estudiaron cómo cambian las ideas de estudiantes de ciencias. Una persona abandona una idea cuando esta deja de explicar lo que observa y aparece otra que le resulta comprensible, creíble y útil. A ese proceso lo llamaron cambio conceptual.

En programación, el choque se produce cuando alguien anticipó un resultado y la computadora muestra otro: la diferencia obliga a revisar la idea de cómo se ejecuta el código.

Una secuencia de clase en cinco fases

Sentance y Waite (2017), y luego Sentance, Waite y Kallia (2019), combinaron estas ideas con la evidencia sobre lectura y trazado en una secuencia para clases de programación con texto, que puede ocupar una clase o varias:

1. el grupo anticipa qué hará un programa dado, conversando en pares: predecir;
2. lo ejecuta y compara el resultado con lo que anticipó: ejecutar;
3. lo analiza: lo traza, lo anota, responde preguntas y busca errores: investigar;
4. le hace cambios cada vez mayores: modificar;
5. escribe un programa nuevo que reutiliza las mismas estructuras: crear.

Las iniciales de las fases en inglés (Predict, Run, Investigate, Modify, Make) forman la sigla con que se conoce esta secuencia: PRIMM.

Por qué predecir es la fase clave

Es la menos intuitiva y la más importante: obliga a comprometerse con una explicación antes de recibir la respuesta de la computadora, y así hace visible el modelo mental de cada estudiante, incluidos sus errores.

Además reduce la ansiedad por una razón estructural: la carga se comparte con un par, la respuesta es de bajo riesgo y, al leer código que ya funciona, no se pueden cometer errores en la forma de escribirlo, una fuente frecuente de frustración inicial.

Qué dice la evidencia

El grupo que trabajó con esta secuencia obtuvo mejores resultados en una prueba posterior que el grupo de comparación. Es evidencia de un contexto escolar concreto: no garantiza el mismo efecto en todos los grupos.

Para recordar

PRIMM

Secuencia de clase en cinco fases (predecir, ejecutar, investigar, modificar, crear) que empieza leyendo código ajeno y se apoya en la conversación entre pares.

Cambio conceptual

Revisión de una idea cuando deja de explicar lo que se observa y aparece otra más comprensible, creíble y útil.

La computadora que imaginamos

Para anticipar qué hará un programa no hace falta saber cómo funciona el procesador por dentro. Alcanza con una versión simplificada de la computadora que sigue las reglas del lenguaje, por ejemplo: «una asignación evalúa primero lo que está a la derecha del signo igual y guarda el resultado bajo el nombre de la izquierda». Du Boulay (1986) llamó máquina nocional a esa computadora imaginaria.

Sorva (2013) mostró que muchas dificultades de quienes empiezan a programar vienen de una máquina nocional incompleta o equivocada, y que conviene enseñarla de forma explícita en lugar de esperar que se deduzca.

Trazar es ejecutar a mano la máquina nocional

Fitzgerald, Simon y Thomas (2005) analizaron cómo trazan los estudiantes y encontraron estrategias muy diversas y, en muchos casos, ineficaces: intentar recordar los valores sin anotarlos, saltear vueltas de un bucle, suponer el resultado.

Xie, Nelson y Ko (2018) enseñaron una estrategia explícita, siempre igual, y quienes la usaron trazaron con más precisión.

Ponerle nombre al propósito de cada parte

Margulieux, Catrambone y Guzdial (2016) mostraron que agregar a un ejemplo resuelto rótulos que nombran el propósito de cada grupo de líneas (por ejemplo «inicializar», «recorrer», «acumular») mejora el desempeño en problemas nuevos. A esos rótulos los llamaron subobjetivos.

Qué hace y para qué sirve

Schulte (2008) propuso un modelo de comprensión de programas que distingue, entre otras dimensiones, entender la estructura y la ejecución del código (qué instrucciones tiene, qué pasa al correrlo) y entender su función (para qué sirve). Lo llamó modelo de bloques (en inglés, Block Model). Comprender un programa es poder moverse entre ambas.

Se ha señalado una precisión de trazado cercana al 50 % como umbral para empezar a escribir con confianza (Raspberry Pi Foundation, 2023; dato a verificar en la fuente original).

Para recordar

Máquina nocional

Versión simplificada e imaginaria de la computadora, que sigue las reglas del lenguaje y permite anticipar qué hará un programa.

Subobjetivos

Rótulos que nombran el propósito de cada grupo de líneas de un programa.

Dos clases de error

Un programa puede fallar porque no respeta las reglas de escritura del lenguaje: falta un signo, una palabra está mal escrita, la sangría no corresponde. El lenguaje no lo acepta y el programa no llega a ejecutarse. Esto se llama error de sintaxis.

Otro programa puede ejecutarse sin quejas y, sin embargo, hacer algo distinto de lo que se buscaba: es un error lógico. Los primeros producen un mensaje que señala la línea; los segundos no producen ningún mensaje.

Encontrar errores con método

Al proceso de localizar un error, explicar su causa y corregirlo se lo llama depurar (en inglés, debugging). McCauley y colegas (2008) revisaron la investigación sobre depuración en educación y concluyeron que depurar bien exige comprender el programa, formular hipótesis sobre la causa y ubicar el punto en que el comportamiento se aparta del esperado.

Quienes empiezan suelen saltear la comprensión y probar cambios al azar.

Aprender de errores puestos a propósito

Große y Renkl (2007) estudiaron ejemplos resueltos que contienen errores a propósito y encontraron que encontrarlos y corregirlos puede favorecer el aprendizaje, en especial cuando quien aprende tiene conocimientos previos suficientes o cuando el error está señalado.

En programación esto se traduce en programas con un error plantado: el foco está en razonar sobre el código, no en escribirlo. Un buen ejercicio de este tipo pide nombrar el tipo de error y la línea donde la ejecución se aparta de lo esperado.

Para recordar

Depurar

Comparar lo que el programa hace con lo que debería hacer, localizar dónde se separan, explicar la causa y corregirla.

Error plantado

Error puesto a propósito en un programa para que el grupo razone sobre el código y lo encuentre.

Sentir que el programa es propio

Quien recibe un programa ajeno y lo ejecuta lo usa como consumidor; quien lo cambia empieza a colaborar con quien lo escribió; quien lo construye es su autor. A esta relación creciente con el programa se la llama apropiación o sentido de propiedad (en inglés, ownership).

Al comienzo, un error es una mala lectura del código ajeno; al final, es una decisión de diseño propia. Trabajar primero con un programa que funciona ofrece, además, un modelo concreto de lo que significa «bien hecho».

Una progresión en tres etapas

Lee y colegas (2011) estudiaron cómo jóvenes desarrollaban formas de plantear y resolver problemas apoyadas en ideas de la computación (lo que se conoce como pensamiento computacional) y describieron una progresión en tres etapas: primero usar un artefacto computacional existente, después modificarlo y por último crear uno propio (datos del estudio a verificar).

En inglés se la conoce como Use-Modify-Create (UMC). Lytle y colegas (2019) la compararon con otras formas de secuenciar lecciones en clases de ciencias y matemáticas.

Usar lo aprendido en situaciones cada vez más distintas

Perkins y Salomon (1992) distinguieron dos formas de usar lo aprendido en una situación nueva: en un contexto muy parecido a aquel en que se aprendió (transferencia cercana) o en uno muy distinto (transferencia lejana). La segunda es más difícil y no ocurre sola: hay que prepararla.

Modificar el mismo programa es transferencia cercana; crear uno nuevo con el mismo patrón es un paso hacia la lejana.

Cómo se combina con la secuencia de cinco fases

Si la secuencia de la lección 2 organiza una clase, esta progresión organiza una unidad completa, y las dos encajan una dentro de la otra:

• usar abarca predecir, ejecutar e investigar;
• modificar corresponde a la cuarta fase;
• crear, a la quinta.

La apropiación también es afectiva

Ryan y Deci (2000) mostraron que la motivación crece cuando la persona siente autonomía, se siente competente y se siente en vínculo con otras; a este marco lo llamaron teoría de la autodeterminación.

Incluir elección en la etapa de crear (el tema, el contexto, el aspecto del producto) fortalece la autonomía. En un estudio con placas programables, estudiantes valoraron especialmente poder crear algo «genial» y personal (Sentance et al., 2017).

Para recordar

Use-Modify-Create

Progresión de una unidad en tres etapas (usar, modificar, crear) en la que se gana autonomía sobre el código de forma gradual.

Transferencia

Usar lo aprendido en una situación nueva: cercana si se parece a la original, lejana si es muy distinta.

Retirar el apoyo de a poco

El andamiaje de la lección 1 es temporal por definición: un apoyo ajustado a lo que la persona necesita, que se retira cuando ya no hace falta (Walqui, 2006).

Renkl y Atkinson (2003) estudiaron cómo pasar de estudiar ejemplos resueltos a resolver problemas sin ayuda. Propusieron quitar un paso resuelto por vez: primero el ejemplo completo, luego con un paso faltante, luego con dos, hasta que solo queda el enunciado. Llamaron a esta retirada gradual desvanecimiento (en inglés, fading).

Lo que ayuda a una persona estorba a otra

Kalyuga, Ayres, Chandler y Sweller (2003) mostraron que un apoyo que ayuda a quien recién empieza puede perjudicar a quien ya domina el tema, porque le obliga a procesar información que ya sabe y que se vuelve redundante. Lo llamaron efecto de inversión de la pericia.

Salden, Aleven, Schwonke y Renkl (2010) encontraron que retirar los apoyos según el desempeño de cada estudiante da mejores resultados que hacerlo en un orden fijo para todo el grupo: es el desvanecimiento adaptativo.

Ordenar en lugar de escribir

Parsons y Haden (2006) propusieron ejercicios en los que se entregan, desordenadas, las líneas de un programa correcto, y hay que armarlo. Hoy se los conoce como problemas de Parsons. Ericson, Foley y Rick (2018) encontraron que llevan menos tiempo que escribir el código equivalente, con ganancias de aprendizaje similares.

Admiten variantes: con líneas que sobran (llamadas distractores), con sangría que hay que decidir, con rótulos de subobjetivos o con huecos para completar. Después de armarlos conviene pedir siempre la traza y el propósito.

Cuidar la confianza

Bandura (1997) llamó autoeficacia a la creencia de una persona en su capacidad para lograr algo. Crece sobre todo con experiencias de logro y cae con fracasos repetidos.

Por eso conviene que nadie acumule más de dos fallos seguidos sin una salida: una pista, un apoyo más o un ejemplo parecido resuelto.

Para recordar

Desvanecimiento

Retiro gradual de los apoyos, paso a paso, hasta que la persona resuelve sola. Funciona mejor cuando se ajusta al desempeño de cada estudiante.

Inversión de la pericia

Un apoyo que ayuda a quien recién empieza puede estorbar a quien ya domina el tema.

El conocimiento que no se acumula

Karl Maton, sociólogo de la educación, se preguntó por qué en algunas aulas el conocimiento se acumula (lo aprendido hoy sirve para entender lo de mañana) y en otras queda segmentado: cada tema queda atado a la situación en que se aprendió y no se lleva a otras (Maton, 2009).

Retomó el trabajo de Bernstein (1999) sobre cómo se organizan los distintos saberes y desarrolló un marco para analizar prácticas educativas, que llamó Teoría de los Códigos de Legitimación (LCT, por su sigla en inglés).

Cuánto depende un significado de su contexto

La frase «este botón cambia este texto» solo tiene sentido frente a esa pantalla; la frase «un evento dispara una función registrada» vale para cualquier programa.

Maton (2013, 2014) llamó gravedad semántica a esa dependencia del contexto: es fuerte cuando el significado está atado a un caso concreto y débil cuando es general y abstracto.

Cuánto significado condensa una palabra

La palabra «iteración» condensa muchas ideas: repetición, contador, condición de corte, cuerpo del bucle. La palabra «repetir» condensa pocas. Maton llamó densidad semántica a esa condensación: es alta en los términos técnicos y baja en el lenguaje cotidiano.

Quien tiene experiencia pasa de un extremo al otro sin esfuerzo y a menudo no advierte cuánto significado comprime en una sola palabra. El o la joven estudiante necesita, sobre todo, aprender a hacer ese recorrido.

Para recordar

Gravedad semántica

Cuánto depende un significado de su contexto. Fuerte: atado a un caso concreto. Débil: general y abstracto.

Densidad semántica

Cuánto significado condensa un término. Alta: técnico y denso. Baja: cotidiano y simple.

Bajar y volver a subir

Maton (2013) observó que en las clases donde el conocimiento se acumula aparece un movimiento característico. El o la docente parte de un concepto técnico y abstracto y lo descompone con palabras simples, ejemplos o analogías: aumenta la gravedad y baja la densidad. A este primer movimiento lo llamó desempaquetar (unpacking).

Después vuelve al término técnico, ahora cargado de sentido, y lo usa en otro contexto: reempaquetar (repacking). Dibujado en un gráfico, el recorrido parece una ola, y así lo llamó: ola semántica.

En las clases de computación

Curzon, McOwan, Donohue, Wright y Mars (2018) llevaron la idea a la enseñanza de la computación. Las actividades que enseñan ideas de computación con juegos, tarjetas o el cuerpo, sin computadoras, se conocen como computación desenchufada (unplugged; Bell, Witten y Fellows, 1998).

Waite, Maton, Curzon y Tuttiett (2019) analizaron con olas semánticas una de ellas, en la que una persona describe un dibujo para que otra lo reproduzca sin verlo. Curzon, Waite, Maton y Donohue (2020) mostraron que la efectividad de estas actividades depende de que se reconecten con el concepto.

Toda analogía tiene un límite

Gentner (1983) explicó que una analogía funciona porque traslada relaciones de un dominio conocido a uno nuevo, pero dos dominios nunca coinciden en todo.

La caja sirve para la variable hasta que aparece x = x + 1: una caja no explica que primero se evalúa el lado derecho y después se guarda el resultado.

Formas de la ola

La ola puede empezar y terminar en el término técnico, para que se sepa a dónde se va: forma de U. O puede partir de un ejemplo concreto, subir a la técnica y volver a aplicarla: forma de n.

También se pueden anidar olas pequeñas dentro de una mayor, una por cada subconcepto (Raspberry Pi Foundation, 2025b).

Recorridos problemáticos

Cuando el recorrido no ondula aparecen tres perfiles problemáticos:

Una cautela sobre la evidencia

Los propios autores presentan buena parte de estos consejos como experiencia de aula y no como hallazgos de estudios controlados (Raspberry Pi Foundation, 2025b). Son una herramienta para analizar y planificar, no una fórmula demostrada.

Waite, Kolaiti, Thomas y Maton (2023) propusieron usarlos también para escribir la devolución de preguntas de opción múltiple: si una respuesta se queda en lo concreto, la devolución invita a subir; si se queda en lo técnico, a bajar. La evaluación final usa esa idea.

Para recordar

Ola semántica

Recorrido de una explicación que baja de lo técnico a lo concreto (desempaquetar) y vuelve a subir al término técnico, ahora con sentido (reempaquetar).

Plano bajo

Explicación que se queda en lo concreto y no vuelve al concepto: el riesgo más habitual de las actividades lúdicas.

Quedarse con lo esencial

Un mapa del transporte público conserva las estaciones y sus conexiones y omite las distancias reales y las calles: se queda con lo que importa para un propósito y deja de lado lo demás. A esa operación se la llama abstraer.

Wing (2006, 2008) la ubicó en el centro de lo que llamó pensamiento computacional: la forma de plantear y resolver problemas apoyada en ideas de la computación. Kramer (2007) la señaló como la habilidad clave de toda la disciplina.

Cuatro planos para pensar un programa

Perrenet, Groote y Kaasenbrood (2005) estudiaron cómo entienden estudiantes el concepto de algoritmo y distinguieron distintos planos desde los que se lo puede pensar: el problema, el algoritmo, el programa y su ejecución.

Cutts, Esper, Fecho, Foster y Simon (2012) describieron los pasajes entre el lenguaje del problema, el de la computación y el código, en lo que llamaron Taxonomía de Transición de Abstracción. Waite, Curzon, Marsh y Sentance (2018) adaptaron estas ideas a la enseñanza escolar en cuatro planos, que llamaron niveles de abstracción.

Ir y volver

Lo que debe dominar el o la estudiante es el movimiento en ambos sentidos: del problema al diseño, del diseño al código, del código a la ejecución, y también al revés: comparar lo que ocurre al ejecutar con el problema original, o comprobar el código contra el plan.

La Raspberry Pi Foundation (2025a) recomienda tres prácticas: no mezclar planos en una misma conversación, usar el vocabulario propio de cada plano (los nombres del lenguaje, solo en el plano del código) y empezar por el plano más alto antes de bajar.

Con la secuencia de la lección 2: predecir y ejecutar conectan el código con la ejecución; investigar recorre los cuatro planos al preguntar qué hace el código y para qué sirve; crear exige subir hasta el problema y el diseño antes de bajar al código.

Para recordar

Abstraer

Quedarse con lo esencial para un propósito y dejar de lado los detalles que no importan.

Niveles de abstracción

Cuatro planos desde los que se piensa un programa: problema, diseño, código y ejecución. Programar es moverse entre ellos en ambos sentidos.

Cómo se organiza una respuesta

Biggs y Collis (1982) propusieron clasificar las respuestas de estudiantes no por si son correctas, sino por cómo están organizadas. Distinguieron cinco niveles: la respuesta no capta el punto (preestructural); maneja un solo elemento relevante (uniestructural); maneja varios elementos, pero sueltos (multiestructural); los integra en un todo con sentido (relacional), o además generaliza a casos nuevos (abstracto extendido).

Por las iniciales en inglés de «estructura del resultado de aprendizaje observado», se la conoce como taxonomía SOLO.

Aplicada a la lectura de código

Lister, Simon, Thompson, Whalley y Prasad (2006) y Whalley y colegas (2006) pidieron a estudiantes que explicaran fragmentos de código y clasificaron las respuestas con esa taxonomía. Quienes describían el propósito general del código (respuesta relacional) comprendían mejor y rendían mejor en otras tareas que quienes lo narraban línea por línea (respuesta multiestructural).

A este tipo de consigna se la conoce como pregunta de explicar en lenguaje llano (en inglés, explain in plain English; Murphy, McCauley y Fitzgerald, 2012). El modelo de bloques de Schulte (2008), de la lección 2, distingue justamente qué hace el código de para qué sirve.

Explicarse a uno mismo

Chi, Bassok, Lewis, Reimann y Glaser (1989) observaron a estudiantes de física mientras estudiaban ejemplos resueltos. Quienes se explicaban a sí mismos por qué se daba cada paso aprendían más que quienes solo lo leían. Lo llamaron autoexplicación.

Preguntas como «¿por qué se hace este paso?» o «¿para qué sirve este bloque?» la estimulan.

Una escala para el aula

De esta evidencia se desprende una escala de cinco niveles para registrar cómo explica cada estudiante un programa. El nivel E3 es el objetivo central: decir para qué sirve el programa sin nombrar sus variables.

Una advertencia metodológica

Explicar el código es más un paso previo que un resultado: quien no logra decir qué hace un programa difícilmente escribirá uno que haga algo concreto.

Pero la relación entre explicar y escribir es correlacional en los estudios citados (Venables, Tan y Lister, 2009): muestra que van juntas y sugiere una secuencia didáctica, pero no prueba por sí sola que enseñar a explicar cause mejor escritura.

Para recordar

Taxonomía SOLO

Clasificación de respuestas según su organización: de no captar el punto, a manejar elementos sueltos, a integrarlos en un todo y generalizar.

Autoexplicación

Explicarse a uno mismo por qué se da cada paso; mejora la comprensión.

Programas que salen de la pantalla

Hay placas pequeñas que se programan desde la computadora y después funcionan solas. Leen el entorno con dispositivos que miden luz, temperatura, movimiento o si se pulsó un botón, llamados sensores, y actúan sobre él con luces, sonidos o motores, llamados actuadores.

Programar estas placas para que interactúen con el mundo físico se conoce como computación física (physical computing). La micro:bit, una placa con 25 luces, dos botones y varios sensores, es una de las más usadas en escuelas.

Aprender construyendo objetos

Papert (1980), y luego Papert y Harel (1991), propusieron que se aprende especialmente bien cuando se construye un objeto que se puede mostrar, compartir y discutir; llamaron a esta idea construccionismo.

Hodges, Sentance, Finney y Ball (2020) defendieron la computación física como un elemento clave de la educación en computación. Sentance, Waite, Hodges, MacLeod y Yeomans (2017) y Kalelioğlu y Sentance (2020) describieron su uso en escuelas desde la experiencia de estudiantes y docentes.

Un puente con las lecciones anteriores

Un sensor y un actuador hacen visible la estructura de entrada, proceso y salida de todo programa: recibe datos, los transforma y produce un resultado.

Pulsar un botón es una experiencia física de lo que en programación se llama evento: algo que ocurre y dispara una acción registrada de antemano. Y un programa con un error plantado se vuelve visible cuando el dispositivo no hace lo previsto.

Para recordar

Computación física

Programar placas que leen el entorno con sensores y actúan sobre él con actuadores, para que el programa interactúe con el mundo físico.

Construccionismo

Se aprende especialmente bien construyendo un objeto que se puede mostrar, compartir y discutir.

Información sobre el propio desempeño

Hattie y Timperley (2007) definieron la retroalimentación como la información sobre el propio desempeño que permite reducir la distancia entre dónde se está y a dónde se quiere llegar. La más útil responde a tres preguntas: ¿a dónde voy?, ¿cómo voy?, ¿qué sigue?

Una placa ofrece una respuesta inmediata: el resultado del programa se ve en segundos.

El estado afuera de la cabeza

Zhang y Norman (1994) mostraron que lo que está anotado, dibujado o visible alivia a la memoria de trabajo, porque parte del problema queda «afuera»; lo llamaron representación externa.

En una placa, el resultado de ejecutar el programa (una luz, un número en la matriz) es visible: el o la estudiante no tiene que sostenerlo solo en la cabeza y puede contrastarlo con lo que anticipó.

Dos representaciones del mismo programa

Muchos entornos muestran el programa en bloques encastrables y en texto a la vez. Ainsworth (2006) mostró que aprender con varias representaciones de lo mismo ayuda cuando se enseña a pasar de una a otra; lo llamó aprendizaje con representaciones múltiples.

Weintrop y Wilensky (2017) compararon clases que programaban con bloques y con texto y reportaron ventajas de los bloques en el aprendizaje inicial (a verificar).

Tres cautelas

1. La reducción de carga por la respuesta física inmediata es una inferencia razonable desde la teoría de la lección 1, no un resultado medido de forma directa en los trabajos citados (a verificar).
2. El objeto físico agrega su propia carga extrínseca: cables, conexiones, calibración, fallas. Un error que no está en el código puede confundir a quien todavía no distingue entre ambos.
3. El riesgo de plano bajo (lección 4) es alto: construir el dispositivo no equivale a comprender la estructura de control. Conviene cerrar cada proyecto con traza y explicación del propósito.

Para recordar

Retroalimentación

Información sobre el propio desempeño que permite reducir la distancia entre dónde se está y a dónde se quiere llegar.

Representación externa

Lo que queda anotado, dibujado o visible y alivia a la memoria de trabajo.