Enseñar tecnología en comunidad

Cómo crear y dar lecciones que funcionen
y construir una comunidad docente a su alrededor

Greg Wilson

Taylor & Francis, 2019, 978-0-367-35328-5

Comprar en línea

Las reglas

1. Sé amable: todo lo demás son detalles.
   

2. Recuerda que tú no eres tus estudiantes…
   

3. …que la mayoría de la gente prefiere fracasar antes que cambiar…
   

4. …y que el 90% de la magia consiste en saber una cosa más (que tu público).
   

5. Nunca enseñes solo/a.
   

6. Nunca dudes en sacrificar la verdad por la claridad.
   

7. Haz de cada error una lección.
   

8. Recuerda que ninguna clase sobrevive al primer contacto con estudiantes…
   

9. …que cada clase es demasiado corta para quien enseña y demasiado larga para quien la recibe…
   

10. …y que nadie tendrá más entusiasmo que tú por tu clase.

Sobre la traducción

Este es el sitio web de la versión en español de Teaching Tech Together de Greg Wilson. La traducción de Enseñar Tecnología en Comunidad es un proyecto colaborativo de voluntarias de la comunidad de MetaDocencia y R-Ladies en Latinoamérica, que tiene por objetivo traducir al español material actualizado y de calidad para hacerlo accesible a hispanohablantes. Iniciamos el proceso de traducción en marzo del año 2020 y lo completamos en marzo del 2021.

El trabajo se organizó de manera que cada capítulo tuvo una persona asignada a cargo de la traducción y dos personas que realizaron las revisiones correspondientes. Se buscó que el idioma de las traductoras y revisoras tuviera origen en diferentes países para poder considerar las diferentes y hermosas formas en que hablamos español en todo el mundo. Al finalizar todo el proceso se realizó una edición final del libro en su conjunto.

Las decisiones que tomamos durante el proceso de traducción se basaron en experiencias previas del equipo y en otras guías de traducciones colaborativas al español como R para Ciencia de Datos y The Carpentries:

La variedad dialéctica del español (castellano) utilizada en la traducción corresponde a Latinoamérica y se utilizó una voz conversacional en lugar de una voz formal o académica.

Decidimos intentar ajustar la redacción para evitar la marca de género, pero en caso de no poder evitar su uso, decidimos utilizar lenguaje no sexista que implica el uso del femenino y masculino privilegiando la agilidad y fluidez del texto, que el mismo se entienda y que sea claro el mensaje. Para que haya coherencia a lo largo del texto y mostrar que no hay una determinada jerarquía alternamos el uso del femenino/masculino o masculino/femenino entre capítulos y el uso fue consistente durante todo el capítulo.

También decidimos buscar las versiones al español de referencias como entradas en Wikipedia y lecciones de The Carpentries. En caso que no existieran se dejaron las versiones en inglés.

Finalmente, se decidió cambiar algunos ejemplos a realidades más regionales, para que sean más cercanos a la región de origen de la mayoría de las traductoras.

Quienes trabajamos en este proyecto somos (en orden alfabético): Laura Acion, Mónica Alonso, Zulemma Bazurto, Alejandra Bellini, Yanina Bellini Saibene, Juliana Benitez Saldivar, Lupe Canaviri Maydana, Silvia Canelón, Ruth Chirinos, Paola Corrales, María Dermit, Ana Laura Diedrich, Patricia Loto, Priscilla Minotti, Natalia Morandeira, Lucía Rodríguez Planes, Paloma Rojas, Yuriko Sosa, Natalie Stroud, Yara Terrazas-Carafa y Roxana Noelía Villafañe.

En cada capítulo encontrarás el detalle de las personas que estuvieron a cargo de traducirlo y revisarlo.

La coordinación del trabajo estuvo a cargo de Yanina Bellini Saibene y la edición final a cargo de Yanina Bellini Saibene y Natalia Morandeira.

Malena Zabalegui nos aconsejó sobre el uso de lenguaje no sexista e inclusivo para la realización de esta traducción y Francisco Etchart diseñó el hex sticker.

También generamos un glosario y diccionario bilingüe de términos de educación y tecnología a partir del glosario del libro y del listado de términos a traducir (o no) del libro. El desarrollo de este glosario estuvo a cargo de Yanina Bellini Saibene utilizando glosario.

Todos los detalles del proceso de traducción se pueden consultar en la documentación del proyecto.

Como citar este trabajo

Puedes citar este trabajo de esta manera:

Wilson, G. (2021). Enseñar tecnología en comunidad. Cómo crear y dar lecciones que funcionen y construir una comunidad docente a su alrededor [Teaching Tech Together. How to create and deliver lessons that work and build a teaching community around them] (Traducción al español: Y. Bellini Saibene, N. S. Morandeira, P. Corrales, L. Acion, M. Dermit, Y. Sosa, J. Benitez Saldivar, Z. Bazurto, S. Canelón, L. Canaviri Maydana, M. Alonso, A. Bellini, P. Minotti, R. Chirinos, P. Rojas, N. Stroud, R. N. Villafañe, P. Loto, A. L. Diedrich, Y. Terrazas-Carafa & L. Rodríguez Planes). https://teachtogether.tech/es/ (Trabajo original publicado en 2019).

Este estilo de cita está basado en la sección Book, republished in translation de la guía para citar trabajos de traducciones de APA. Incluimos el titulo en Inglés, siguiendo esta sugerencia de APA (ver ejemplo para Piaget (1950)).

Introducción

En todo el mundo han surgido comunidades de práctica para enseñar programación, diseño web, robótica y otras habilidades a estudiantes free-range.¹. Estos grupos existen para que la gente no tenga que aprender estas cosas por su cuenta, pero, irónicamente, sus fundadoras/es y docentes están muchas veces enseñándose a sí mismas/os cómo enseñar.

Hay una forma más conveniente. Así como conocer un par de cuestiones básicas sobre gérmenes y nutrición te puede ayudar a permanecer saludable, conocer un par de cosas sobre psicología cognitiva, diseño instruccional, inclusión y organización comunitaria te puede ayudar a aumentar tu efectividad como docente. Este libro presenta ideas clave que puedes usar inmediatamente, explica por qué creemos que son ciertas y te señala otros recursos que te ayudarán a profundizar tus conocimientos.

Re-uso

Algunas secciones de este libro fueron originalmente creadas para el programa de entrenamiento de instructores/as de Software Carpentry. Cualquier parte del libro puede ser libremente distribuida y re-utilizada bajo la licencia Creative Commons Atribución-NoComercial 4.0 (Anexo 16). Puedes usar la versión online disponible en http://teachtogether.tech/es/ en cualquier clase (gratuita o paga), y puedes citar pequeños extractos bajo el criterio de uso justo, pero no puedes re-publicar largos fragmentos en trabajos comerciales sin permiso previo.

Las contribuciones, correcciones y sugerencias son bienvenidas, y cada vez que una nueva versión del libro sea publicada se les agradecerá a quienes contribuyan. Por favor consulta el Anexo 18 para detalles sobre como contribuir y el Anexo 17 para conocer nuestro código de conducta.

Quién eres

La Sección 6.1 explica cómo averiguar quiénes son tus estudiantes. Los cuatro tipos de personas a las que está destinado este libro son docentes usuarias/os finales: la enseñanza no es su ocupación primaria, tienen poco o ningún conocimiento sobre pedagogía y posiblemente trabajan fuera de clases institucionales.

Emilia

está entrenada como bibliotecaria y actualmente trabaja como diseñadora web y gestora de proyectos en una pequeña empresa consultora. En su tiempo libre, ayuda a impartir clases de diseño para mujeres que ingresan a la tecnología como una segunda carrera. Se encuentra reclutando colegas para dar más clases en su área y quiere saber cómo preparar lecciones que otras personas puedan usar, a la par de hacer crecer una organización de enseñanza voluntaria.

David

es un programador profesional, cuyos dos hijos adolescentes asisten a una escuela que no ofrece clases de programación. Se ha ofrecido como voluntario para dirigir un club de programación mensual después del horario de clases. A pesar de que expone presentaciones frecuentemente a sus colegas, no tiene experiencia de enseñanza en el aula. Quiere aprender a enseñar cómo construir lecciones efectivas en un tiempo razonable, y le gustaría aprender más acerca de los pros y contras de las clases en línea en las que cada asistente cursa a su propio ritmo.

Samira

es una estudiante de robótica, que está considerando ser docente luego de graduarse. Quiere ayudar a sus pares en los talleres de robótica de fin de semana, pero nunca ha enseñado en una clase antes, y en gran medida siente el síndrome de la impostora. Quiere aprender más acerca de educación en general para decidir si la enseñanza es para ella y también está buscando sugerencias específicas que la ayuden a dar lecciones de forma más efectiva.

René

es docente de ciencias de la computación en una universidad. Ha estado enseñando cursos de grado sobre sistemas operativos por seis años y cada vez se convence más de que tiene que haber una mejor manera de enseñar. El único entrenamiento disponible a través del centro de enseñanza y aprendizaje de su universidad es sobre publicar tareas y enviar evaluaciones en el sistema en línea de gestión del aprendizaje, por lo que quiere descubrir qué otro entrenamiento podría pedir.

Estas personas tienen una variedad de conocimientos técnicos previos y alguna experiencia previa con la enseñanza, pero carecen de entrenamiento formal en enseñanza, diseño de lecciones u organización comunitaria. La mayoría trabaja con estudiantes free-range y están enfocadas en adolescentes y personas adultas más que en niñas/os; todas estas personas tienen tiempo y recursos limitados. Esperamos que nuestro cuarteto use este material de la siguiente manera:

Emilia

tomará parte de un grupo de lectura semanal en línea con sus voluntarias.

David

va a abordar parte de este libro en un taller de un día durante un fin de semana y estudiará el resto por su cuenta.

Samira

usará este libro en un curso de grado de un semestre que incluirá tareas, un proyecto y un examen final.

René

leerá el libro por su cuenta en su oficina o mientras viaja en el transporte público, deseando entretanto que las universidades hagan más para apoyar la enseñanza de alta calidad.

Qué otras cosas leer

Si tienes prisa o quieres tener una idea de lo que cubrirá este libro, [Brow2018] presenta diez sugerencias basadas en evidencias para enseñar computación². También puedes disfrutar³:

• El entrenamiento para instructoras/es de The Carpentries (Las/los carpinteras/os), en el cual está basado este libro.

• [Lang2016] y [Hust2012], que son textos cortos y accesibles, que conectan las cosas que puedes aplicar inmediatamente con la investigación que hay detrás de ellas y las fundamenta.

• [Berg2012,Lemo2014,Majo2015,Broo2016,Rice2018,Wein2018b] están repletos de sugerencias prácticas sobre cosas que puedes hacer en tu clase, pero pueden cobrar más sentido una vez que tengas un marco conceptual para entender por qué sus ideas funcionan.

• [DeBr2015], quien plantea qué cosas son ciertas sobre la educación al explicar qué cosas no lo son y [Dida2016], que fundamenta la teoría del aprendizaje en psicología cognitiva.

• [Pape1993], que continúa siendo una visión inspiradora sobre cómo las computadoras pueden cambiar la educación. La excelente descripción de Amy Ko es una síntesis de las ideas de Papert, mejor que la que podría hacer yo, y  [Craw2010] es una compañía provocadora y estimulante a ambos textos.

• [Gree2014,McMi2017,Watt2014] explican por qué tantos intentos de reformas educativas han fallado a lo largo de los últimos cuarenta años, cómo colegas que trabajan solo por dinero han explotado y exacerbado la desigualdad en nuestra sociedad, y cómo la tecnología repetidamente ha fracasado en revolucionar la educación.

• [Brow2007] y [Mann2015], porque no puedes enseñar bien sin cambiar el sistema en el que enseñamos y no puedes lograr este cambio trabajando de forma solitaria.

Quienes deseen material más académico pueden encontrar gratificante leer a  [Guzd2015a,Hazz2014,Sent2018,Finc2019,Hpl2018], mientras que el blog de Mark Guzdial ha sido consistentemente informativo, sugerente y motivador.

Agradecimientos

Este libro no existiría sin las contribuciones de Laura Acion, Jorge Aranda, Mara Averick, Erin Becker, Yanina Bellini Saibene, Azalee Bostroem, Hugo Bowne-Anderson, Neil Brown, Gerard Capes, Francis Castro, Daniel Chen, Dav Clark, Warren Code, Ben Cotton, Richie Cotton, Karen Cranston, Katie Cunningham, Natasha Danas, Matt Davis, Neal Davis, Mark Degani, Tim Dennis, Paul Denny, Michael Deutsch, Brian Dillingham, Grae Drake, Kathi Fisler, Denae Ford, Auriel Fournier, Bob Freeman, Nathan Garrett, Mark Guzdial, Rayna Harris, Ahmed Hasan, Ian Hawke, Felienne Hermans, Kate Hertweck, Toby Hodges, Roel Hogervorst, Mike Hoye, Dan Katz, Christina Koch, Shriram Krishnamurthi, Katrin Leinweber, Colleen Lewis, Dave Loyall, Paweł Marczewski, Lenny Markus, Sue McClatchy, Jessica McKellar, Ian Milligan, Ernesto Mirt, Julie Moronuki, Lex Nederbragt, Aleksandra Nenadic, Jeramia Ory, Joel Ostblom, Nicolás Palopoli, Elizabeth Patitsas, Aleksandra Pawlik, Sorawee Porncharoenwase, Emily Porta, Alex Pounds, Thomas Price, Danielle Quinn, Ian Ragsdale, Erin Robinson, Rosario Robinson, Ariel Rokem, Pat Schloss, Malvika Sharan, Florian Shkurti, Dan Sholler, Juha Sorva, Igor Steinmacher, Tracy Teal, Tiffany Timbers, Richard Tomsett, Preston Tunnell Wilson, Matt Turk, Fiona Tweedie, Martin Ukrop, Anelda van der Walt, Stéfan van der Walt, Allegra Via, Petr Viktorin, Belinda Weaver, Hadley Wickham, Jason Williams, Simon Willison, Karen Word, John Wrenn, y Andromeda Yelton. También estoy agradecido a Lukas Blakk por el logotipo, a Shashi Kumar por la ayuda con LaTeX, a Markku Rontu por hacer que los diagramas se vean mejor, y a toda aquella persona que ha usado este material a lo largo de los años. Cualquier error que permanezca es mío.

Ejercicios

Cada capítulo finaliza con una variedad de ejercicios que incluyen un formato sugerido y cuánto tiempo toma usualmente hacerlos en persona. Muchos pueden ser usados en otros formatos —en particular, si estás avanzando en este libro por tu cuenta, puedes hacer muchos de los ejercicios que son destinados a grupos— y siempre puedes dedicar más tiempo a un ejercicio que el que sugiero.

Si estás usando este material en un taller de formación docente, puedes darles los siguientes ejercicios a quienes participen, con uno o dos días de anticipación, para que tengan una idea de quiénes son y cuál es la mejor manera en que les puedes ayudar. Por favor lee las advertencias en la Sección 9.4 antes de hacer estos ejercicios.

Altos y bajos (clase completa/5’)

Escribe respuestas breves a las siguientes preguntas y compártelas con tus pares. (Si estás tomando notas colaborativas en línea como se describe en la Sección 9.7, puedes escribir tus respuestas allí.)

1. ¿Cuál es la mejor clase o taller que alguna vez hayas tomado? ¿Qué la hacía tan buena?

2. ¿Cuál fue la peor? ¿Qué la hacía tan mala?

Conócete (clase completa/5’)

Comparte respuestas breves a las siguientes preguntas con tus pares. Guarda tus respuestas para que puedas regresar a ellas como referencia a la par que avanzas en el estudio de este libro.

1. ¿Qué es lo que más quieres enseñar?

2. ¿A quiénes tienes más ganas de enseñarles?

3. ¿Por qué quieres enseñar?

4. ¿Cómo sabrás si estás enseñando bien?

5. ¿Qué es lo que más ansías aprender acerca de enseñanza y aprendizaje?

6. ¿Qué cosa específica crees que es cierta acerca de enseñanza y aprendizaje?

¿Por qué aprender a programar? (individual/20’)

Las/los políticas/os, líderes de negocios y educadoras/es usualmente dicen que la gente debe aprender a programar porque los trabajos del futuro lo requerirán. Sin embargo, como Benjamin Doxtdator ha señalado, muchas de estas afirmaciones están construidas sobre cimientos débiles. Incluso si las afirmaciones fueran reales, la educación no debería preparar a la gente para los trabajos del futuro: les debería dar el poder de decidir qué tipos de trabajos hay y asegurarles que vale la pena hacer esos trabajos. Además, como señala Mark Guzdial, hay realmente muchas razones para aprender a programar:

1. Para entender nuestro mundo.

2. Para estudiar y entender procesos.

3. Para ser capaz de hacer preguntas sobre las cosas que influyen en nuestras vidas.

4. Para usar una importante nueva forma de alfabetización.

5. Para tener una nueva manera de aprender arte, música, ciencia y matemática.

6. Como una habilidad laboral.

7. Para usar mejor las computadoras.

8. Como un medio en el cual aprender resolución de problemas.

Dibuja una grilla de 3 × 3 cuyos ejes estén etiquetados: “baja,” “media,” y “alta” y coloca cada razón en un sector de acuerdo a la importancia que tienen para ti (el eje X) y para la gente a la que planeas enseñar (el eje Y).

1. ¿Qué puntos están estrechamente alineados en importancia (es decir, en la diagonal de tu grilla)?

2. ¿Qué puntos están desalineados (es decir, en las esquinas por fuera de la diagonal)?

3. ¿Cómo debería afectar esto lo que tú enseñas?

Modelos mentales y evaluación formativa

La primera tarea en la enseñanza es descifrar quiénes son tus estudiantes. Nuestra aproximación está basada en el trabajo de investigadores/as como Patricia Benner, quien estudió cómo las personas progresan de novatas a expertas en la carrera de enfermería  [Benn2000]. Benner identificó cinco etapas de desarrollo cognitivo que la mayor parte de la gente atraviesa de forma bastante consistente. Para nuestros propósitos, simplificamos esta evolución en tres etapas:

Personas novatas

no saben qué es lo que no saben, es decir, aún no tienen un modelo mental utilizable del dominio del problema.

Practicantes competentes

tienen un modelo mental que es adecuado para los propósitos diarios. Pueden llevar a cabo tareas normales con un esfuerzo normal bajo circunstancias normales y tienen algún entendimiento de los límites de su conocimiento (es decir, saben lo que no saben).

Personas expertas

tienen modelos mentales que incluyen excepciones y casos especiales, los cuales les permiten manejar situaciones que están por fuera de lo ordinario. Discutiremos sobre la experiencia o pericia en más detalle en el Capítulo 3.

Entonces, ¿qué es un modelo mental? Como el nombre lo sugiere, es una representación simplificada de las partes más importantes de algún dominio del problema; que a pesar de ser simplificada es suficientemente buena para permitir la resolución del problema. Un ejemplo es el modelo molecular de bolas y varillas que se usa en las clases de química de la escuela. Los átomos no son en realidad bolas y las uniones atómicas no son en realidad varillas, pero el modelo permite a la gente razonar sobre los componentes químicos y sus reacciones. Un modelo más sofisticado de un átomo es aquel con una bola pequeña en el centro (el núcleo) rodeada de electrones orbitantes. También es incorrecto, pero la complejidad extra permite explicar más y resolver más problemas. (Como con el software, los modelos mentales nunca están finalizados: simplemente son utilizados.)

Presentar a personas novatas un montón de hechos es contraproducente porque aún no tienen un modelo dónde ubicarlos. Incluso, apresurarse a presentar demasiados hechos puede reforzar el modelo mental incorrecto que han improvisado. Como observó  [Mull2007a] en un estudio sobre video-instrucción para estudiantes de ciencia:

Los/las estudiantes tienen ideas existentes acerca de… los fenómenos antes de ver un video. Si el video presenta… conceptos de una forma clara, bien ilustrada, los/las estudiantes creen que están aprendiendo, pero no se involucran con el video en un nivel suficientemente profundo como para darse cuenta de que lo que se les ha presentado difiere de sus conocimientos previos… Sin embargo, hay esperanza. Se ha demostrado que el aprendizaje aumenta al presentar en un video … los conceptos erróneos comunes de los/las estudiantes junto con los… conceptos a enseñar, ya que aumenta el esfuerzo mental que los/las estudiantes realizan mientras miran el video.

Tu objetivo cuando enseñes a personas novatas debe ser, por lo tanto, ayudarlas a construir un modelo mental para que tengan algún lugar en el que ordenar los hechos. Por ejemplo, la lección sobre la consola Unix de Software Carpentry (carpinteros/as de software, en español) introduce quince comandos en tres horas. Eso sería un comando cada doce minutos, lo que parece muy lento hasta que te das cuenta de que el propósito real de la lección no es enseñar esos quince comandos: es enseñar las rutas de acceso, la historia de comandos, el autocompletado con el tabulador, los comodines, los pipes los argumentos de la línea de comando y las redirecciones. Los comandos específicos no tienen sentido hasta que las personas novatas entienden estos conceptos; una vez que lo hacen, pueden empezar a leer manuales, pueden buscar las palabras claves correctas en la web, y pueden decidir si los resultados de sus búsquedas son útiles o no.

Las diferencias cognitivas entre personas novatas y practicantes competentes apuntalan las diferencias entre dos tipos de materiales educativos. Un tutorial ayuda a construir un modelo mental a quienes recién llegan a un determinado campo; un manual, por otro lado, ayuda a practicantes competentes a llenar los baches de su conocimiento. Los tutoriales frustran a los/las practicantes competentes porque avanzan demasiado lento y dicen cosas que son obvias (aunque no son para nada obvias para personas novatas). De la misma manera, los manuales frustran a las personas novatas porque usan jergas y no explican las cosas. Este fenómeno se llama el efecto inverso de la experiencia  [Kaly2003], y es una de las razones por las que tienes que decidir tempranamente para quiénes son tus lecciones.

Un puñado de excepciones

Una de las razones por las que Unix y C se hicieron populares es que [Kern1978,Kern1983,Kern1988] de alguna manera consiguieron tener buenos tutoriales y buenos manuales al mismo tiempo. [Fehi2008] y  [Ray2014] están entre los otros pocos libros de computación que consiguieron esto; incluso luego de releerlos varias veces, no sé cómo lo lograron.

¿Están aprendiendo tus estudiantes?

Mark Twain escribió: “No es lo que no sabes lo que te mete en problemas. Es lo que tienes seguridad de saber y simplemente no es así.” Uno de los ejercicios al construir un modelo mental es, por lo tanto, despejar las cosas que no pertenecen al modelo. En sentido amplio, los conceptos erróneos de las personas novatas caen en tres categorías:

Errores fácticos

como creer que Río de Janeiro es la capital de Brasil (es Brasilia). Estos errores generalmente son fáciles de corregir.

Modelos rotos

como creer que el movimiento y la aceleración deben estar en la misma dirección. Podemos lidiar con estos errores haciendo que las personas novatas razonen a través de ejemplos en los que sus modelos den una respuesta incorrecta.

Creencias fundamentales

como por ejemplo “el mundo solo tiene algunos miles de años de antigüedad” o “algunos tipos de personas son naturalmente mejores en programación que otros” [Guzd2015b,Pati2016]. Estos errores están generalmente conectados profundamente con la identidad social del estudiante, por lo que resisten a las evidencias y racionalizan las contradicciones.

La gente aprende más rápido cuando los/las docentes identifican y aclaran los conceptos erróneos de sus estudiantes mientras se está dando la lección. Esto se llama evaluación formativa porque forma (o le da forma a) la enseñanza mientras se está llevando a cabo. Los/las estudiantes no aprueban o reprueban una evaluación formativa. En cambio, la evaluación formativa da, tanto a quien enseña como a quien aprende, retroalimentación sobre qué tan bien les está yendo y en qué se deberían enfocar en los próximos pasos. Por ejemplo, un/una docente de música le puede pedir a un/una estudiante que toque una escala muy lentamente para chequear su respiración. Entonces, el/la estudiante averigua si la respiración es correcta, mientras que el/la docente recibe una devolución sobre si la explicación que acaba de dar fue comprendida.

En resumen

El contrapunto de la evaluación formativa es la evaluación sumativa, que tiene lugar al final de la lección. La evaluación sumativa es como un examen de conducir: le dice a quien está aprendiendo a conducir si ha dominado el tópico y a quien le está enseñando si su lección ha sido exitosa. Una forma de pensar la diferencia entre los dos tipos de evaluaciones es realizando una analogía con la cocina: quien prueba la comida mientras cocina está haciendo evaluaciones formativas, mientras quien es comensal y prueba la comida cuando se le sirve está haciendo una evaluación sumativa. Desafortunadamente, la escuela ha entrenado a la mayoría de la gente para creer que toda evaluación es sumativa, es decir, que si algo se siente como un examen, resolverlo pobremente le jugaría en contra. Hacer que las evaluaciones formativas se sientan informales reduce esta ansiedad; en mi experiencia, usar cuestionarios en línea, o donde deba hacerse click, o cualquier cosa semejante parece aumentar la ansiedad, ya que hoy en día la mayoría de la gente cree que todo lo que hace en internet está siendo mirado y grabado.

Para ser útil durante la enseñanza, una evaluación formativa debe ser rápida de administrar (de manera que no rompa el flujo de la lección) y debe tener una respuesta correcta no ambigua (de manera que pueda ser usada en grupos). Probablemente, el tipo de evaluación formativa que más ampliamente se usa es la pregunta de opción múltiple. Muchos/as docentes tienen una mala opinión sobre ellas, pero cuando las preguntas de opción múltiple están bien diseñadas pueden revelar mucho más si alguien sabe o no algunos hechos específicos. Por ejemplo, si estás enseñando a niños/as cómo hacer sumas de números con múltiples dígitos [Ojos2015] y les das esta pregunta de opción múltiple:

¿Cuánto es 37 + 15?
a) 52
b) 42
c) 412
d) 43

La respuesta correcta es 52, pero las otras respuestas proporcionan información valiosa:

• Si el/la niño/a elige 42, no entiende qué significa “llevarse” una unidad. (Podría escribir 12 como respuesta a 7+5, pero luego reemplazaría el 1 con el 4 que obtiene de la suma de 3+1.)

• Si elige 412, está tratando a cada columna de números como un problema separado. Esto sigue siendo incorrecto, pero es incorrecto por un motivo distinto.

• Si elige 43, entonces sabe que tiene que llevarse el 1, pero lo lleva de vuelta a la columna de la que viene. De nuevo, es un error distinto que requiere de una explicación clarificadora diferente por parte de quien enseña.

Cada una de estas respuestas incorrectas es un distractor plausible con poder diagnóstico. Un distractor es una respuesta incorrecta o peor que la mejor respuesta; “plausible” significa que parece que podría ser correcta, mientras que “poder diagnóstico” significa que cada uno de los distractores ayuda al/a la docente a darse cuenta de qué explicar a continuación a estudiantes puntuales.

La variedad de respuestas a una evaluación formativa te guía cómo continuar. Si una cantidad suficiente de la clase tiene la respuesta correcta, avanzas. Si la mayoría de la clase elige la misma respuesta incorrecta, deberías retroceder y trabajar en corregir el concepto erróneo que ese distractor señala. Si las respuestas de la clase se dividen equitativamente entre varias opciones, probablemente están arriesgando, entonces deberías retroceder y re-explicar la idea de una manera distinta. (Repetir exactamente la misma explicación probablemente no será útil, lo cual es uno de los motivos por los que tantos cursos por video son pedagógicamente ineficientes.)

¿Qué pasa si la mayoría de la clase vota por la respuesta correcta pero un grupo pequeño vota por las incorrectas? En ese caso, tienes que decidir si deberías destinar tiempo a que la minoría entienda o si es más importante mantener a la mayoría cautivada. No importa cuán duro trabajes o qué prácticas de enseñanza uses, no siempre vas a conseguir darle a todo tu curso lo que necesita; es tu responsabilidad como docente tomar la decisión.

¿De dónde vienen las respuestas incorrectas?

Para diseñar distractores plausibles, piensa en las preguntas que tus estudiantes hicieron o en los problemas que tuvieron la última vez que enseñaste esa temática. Si no la has enseñado antes, piensa en tus propios conceptos erróneos, pregúntale a colegas sobre sus experiencias o busca la historia de tu campo temático: si las demás personas han tenido los mismos malentendidos sobre la temática cincuenta años atrás, hay chances de que la mayoría de tus estudiantes aún malentiendan la temática de la misma forma al día de hoy. También puedes hacer preguntas abiertas en clase para recoger los conceptos erróneos sobre los temas que vas a abarcar en una clase posterior, o consultar sitios de preguntas y respuestas como Quora o Stack Overflow para ver con qué se confunden quienes aprenden la temática en cualquier otro lugar.

Desarrollar evaluaciones formativas mejora tus lecciones porque te fuerza a pensar en los modelos mentales de tus estudiantes. En mi experiencia, al pensar evaluaciones formativas automáticamente escribo la lección de forma de abarcar los baches y errores más probables. Las evaluaciones formativas, por lo tanto, dan buenos resultados incluso si no son utilizadas (aunque la enseñanza es más efectiva cuando sí se utilizan).

Las preguntas de opción múltiple no son el único tipo de evaluación formativa: el Capítulo 12 describe otros tipos de ejercicios que son rápidos y no son ambiguos. Cualquiera sea la evaluación que escojas, deberías hacer alguna que tome un minuto o dos cada 10–15 minutos de manera de asegurarte de que tus estudiantes están realmente aprendiendo. Este ritmo no está basado en un límite de atención intrínseco:  [Wils2007] encontró poca evidencia a favor de la afirmación usualmente repetida de que los/las estudiantes solo pueden prestar atención durante 10–15 minutos. En cambio, la guía asegura que, si un número significativo de personas se ha quedado atrás, solo tienes que repetir una pequeña porción de la lección. Las evaluaciones formativas frecuentes también mantienen el compromiso de tus estudiantes, particularmente si se involucran en una discusión en un grupo pequeño (Sección 9.2).

Las evaluaciones formativas también pueden ser usadas antes de las lecciones. Si comienzas una clase con una pregunta de opción múltiple y toda la clase la contesta correctamente, puedes evitar explicar algo que tus estudiantes ya saben. Este tipo de enseñanza activa te da más tiempo para enfocarte en las cosas que tus estudiantes no saben. También le muestra a tus estudiantes que respetas su tiempo lo suficiente como para no desperdiciarlo, lo que ayuda a la motivación (Capítulo 10).

Inventario de conceptos

Con una cantidad de datos suficiente, las preguntas de opción múltiple pueden ser sorprendentemente precisas. El ejemplo más conocido es el inventario del concepto de fuerza [Hest1992], que evalúa la comprensión sobre los mecanismos básicos newtonianos. Al entrevistar a un gran número de participantes, correlacionando sus conceptos erróneos con los patrones de respuestas correctas e incorrectas, así como mejorando las preguntas, los creadores de este inventario construyeron una herramienta de diagnóstico que permite identificar conceptos erróneos específicas. Las personas que investigan pueden utilizar dicha herramienta para medir el efecto de los cambios en los métodos de enseñanza  [Hake1998]. Tew y colaboradores desarrollaron y validaron una evaluación independiente del lenguaje para programación introductoria  [Tew2011]; [Park2016] la replicaron y  [Hamo2017] está desarrollando un inventario de conceptos sobre la recursividad. Sin embargo, es muy costoso construir herramientas de este tipo y su validez está cada vez más amenazada por la habilidad de los/las estudiantes para buscar respuestas en línea.

Desarrollar evaluaciones formativas en una clase solo requiere un poco de preparación y práctica. Puedes darles a tus estudiantes tarjetas coloreadas o numeradas para que respondan una pregunta de opción múltiple simultáneamente (en lugar de que tengan que levantar sus manos en turnos), incluyendo como una de las opciones “No tengo idea” y alentando que hablen un par de segundos con sus pares más cercanos antes de responder. Todas estas prácticas te ayudarán a garantizar que el flujo de enseñanza no sea interrumpido. La Sección 9.2 describe un método de enseñanza poderoso y basado en evidencias, construido a partir de estas simples ideas.

Humor

Los/las docentes a veces incluyen respuestas supuestamente tontas en las preguntas de opción múltiple, como “¡mi nariz!”, particularmente en los cuestionarios destinados a estudiantes jóvenes. Sin embargo, estas respuestas no proveen ninguna idea sobre los conceptos erróneos de los/las estudiantes y la mayoría de la gente no las encuentran graciosas. Como regla, deberías solo incluir un chiste en una lección si lo encuentras gracioso la tercera vez que lo relees.

Las evaluaciones formativas de una lección deberían preparar a los/las estudiantes para una evaluación sumativa: nadie debería encontrar nunca una pregunta en un examen para la cual la enseñanza no lo/la ha preparado. Esto no significa que nunca debes incluir nuevos tipos de problemas en un examen, pero, si lo haces, deberías haber ejercitado de antemano a tus estudiantes para abordar problemas nuevos. El Capítulo 6 explora este punto en profundidad.

Máquina nocional

El término pensamiento computacional está muy extendido, en parte porque la gente coincide en que es importante aún cuando con el mismo término se suele referir a cosas muy distintas. En vez de discutir qué incluye y qué no incluye el término, es más útil pensar en la máquina nocional que quieres que tus estudiantes entiendan  [DuBo1986]. De acuerdo a  [Sorv2013], una máquina nocional:

• es una abstracción idealizada del hardware de computadora y de otros aspectos de los entornos de ejecución de los programas;

• permite describir la semántica de los programas; y

• refleja correctamente qué hacen los programas cuando son ejecutados.

Por ejemplo, mi máquina nocional para Python es:

1. Ejecutar programas en el momento en la memoria, la cual se divide en la pila de llamadas y la cola de montículo (heap en inglés).

2. La memoria para los datos siempre es asignada desde la cola del montículo.

3. Cada conjunto de datos se almacena en una estructura de dos partes. La primera parte dice de qué tipo de datos se trata y la segunda parte es el valor real.

4. Booleanos, números y caracteres de texto nunca son modificados una vez que se crean.

5. Las listas, conjuntos y otras colecciones almacenan referencias a otros datos en lugar de almacenar estos valores directamente. Pueden ser modificados una vez que se crean, es decir, una lista puede ser ampliada o nuevos valores pueden ser agregados a un conjunto.

6. Cuando un código se carga a la memoria, Python lo convierte a una secuencia de instrucciones que son almacenadas como cualquier otro tipo de dato. Este es el motivo por el que es posible asignar funciones a variables y luego pasarlas como parámetros.

7. Cuando un código es ejecutado, Python sigue las instrucciones paso a paso, haciendo lo que cada instrucción le indica de a una por vez.

8. Algunas instrucciones hacen que Python lea datos, haga cálculos y cree nuevos datos. Otras, controlan qué instrucciones va a ejecutar, como los bucles y condicionales; también hay instrucciones que le indican a Python que llame a una función.

9. Cuando se llama a una función, Python coloca un nuevo marco de pila en la pila de llamadas.

10. Cada marco de pila almacena los nombres de las variables y las referencias a los datos. Los parámetros de las funciones son simplemente otro tipo de variable.

11. Cuando una variable es utilizada, Python la busca en el marco de la pila superior Si no la encuentra allí, busca en el último marco en la memoria global.

12. Cuando la función finaliza, Python la borra del marco de la pila y vuelve a las instrucciones que estaba ejecutando antes de llamar a la función. Si no encuentra un “antes,” el programa ha finalizado.

Uso esta versión caricaturizada de la realidad siempre que enseño Python. Después de 25 horas de instrucción y 100 horas de trabajar por su cuenta, espero que la mayor parte del grupo tenga un modelo mental que incluya todas o la mayoría de estas características.

Ejercicios

Tus modelos mentales (pensar-parejas-compartir/15’)

¿Cuál es el modelo mental que usas para entender tu trabajo? Escribe unas pocas oraciones para describirlo y hazle una devolución a tu pareja sobre su modelo mental. Una vez que has hecho esto en pareja, algunas pocas personas de la clase compartirán sus modelos con el grupo completo. ¿Está todo el grupo de acuerdo sobre qué es un modelo mental? ¿Es posible dar una definición precisa?, ¿o el concepto es útil justamente porque es difuso?

Síntomas de ser una persona novata (toda la clase/5’)

Decir que las personas novatas no tienen un modelo mental de un dominio particular no es equivalente a decir que no tienen ningún modelo mental. Las personas novatas tienden a razonar por analogía y arriesgan conjeturas: toman prestado fragmentos y partes de modelos mentales de otros dominios que superficialmente parecen similares.

La gente que hace esto generalmente dice cosas que ni siquiera son falsas. Como clase, discutan qué otros síntomas tiene una persona novata. ¿Qué dice o hace una persona para llevarte a clasificarla como novata en algún dominio?

Modelar modelos mentales de las personas novatas (parejas/20’)

Crea una pregunta de opción múltiple relacionada a un tópico que has enseñado o pretendas enseñar y explica el poder diagnóstico de cada uno de sus distractores (es decir, qué concepto erróneo pretende ser identificado con cada distractor).

Una vez que hayas finalizado, intercambia las preguntas de opción múltiple con tu pareja. ¿Son sus preguntas ambiguas? ¿Son los conceptos erróneos plausibles? ¿Los distractores realmente evalúan esos conceptos erróneos? ¿Hay otros posibles conceptos erróneos que no sean evaluados?

Pensar en las cosas (toda la clase/15’)

Una buena evaluación formativa requiere que la gente piense profundamente en un problema. Por ejemplo, imagina que has colocado un bloque de hielo en un recipiente y luego llenas de agua este recìpiente, hasta el borde. Cuando el hielo se derrite, ¿el nivel de agua aumenta (de manera que el recipiente rebasa)?, ¿el nivel de agua baja?, ¿o se mantiene igual (Figura 2.1)?

La solución correcta es que el nivel del recipiente permanece igual: el hielo desplaza a su propio peso en el agua, por lo que completa exactamente el “agujero” que ha dejado al derretirse. Para darse cuenta del porqué la gente construye un modelo de la relación entre el peso, el volumen y la densidad  [Epst2002].

Describe otra evaluación formativa que conozcas o hayas utilizado, alguna que consideres que lleve a los/las estudiantes a pensar profundamente en algo, y por lo tanto ayude a identificar los defectos en sus razonamientos.

Cuando hayas finalizado, explícale tu ejemplo a otra persona de tu grupo y dale una devolución sobre su ejemplo.

Una progresión diferente (individual/15’)

El modelo de desarrollo de habilidades de persona novata-competente-experta es a veces llamado modelo Dreyfus. Otra progresión comúnmente utilizada es el modelo de las cuatro etapas de la competencia:

Incompetencia inconsciente:

la persona no sabe lo que no sabe.

Incompetencia consciente:

la persona se da cuenta de que no sabe algo.

Competencia consciente:

la persona ha aprendido cómo hacer algo, pero solo lo puede hacer mientras mantiene su concentración y quizás aún deba dividir la tarea en varios pasos.

Competencia inconsciente:

la habilidad se ha transformado en una segunda naturaleza y la persona puede realizarla reflexivamente.

Identifica una temática en la que te encuentres en cada uno de los niveles de desarrollo de habilidades. En la materia que enseñas, ¿en qué nivel están usualmente la mayoría de tus estudiantes? ¿Qué nivel estás tratando que alcancen? ¿Cómo se relacionan estas cuatro etapas con la clasificación persona novata-competente-experta?

¿Qué tipo de computación? (individual/10’)

[Tedr2008] resume tres tradiciones en computación:

Matemática:

Los programas son la encarnación de los algoritmos. Son correctos o incorrectos, así como más o menos eficientes.

Científica:

Los programas son modelos de procesos de información más o menos adecuados que pueden ser estudiados usando el método científico.

Ingenieril:

Los programas son objetos que se construyen, tales como los diques y los aviones, y son más o menos efectivos y confiables.

¿Cuál de estas tradiciones coincide mejor con tu modelo mental de la computación? Si ninguna de ellas coincide, ¿qué modelo tienes?

Explicar por qué no (parejas/5’)

Una persona de tu curso piensa que hay algún tipo de diferencia entre el texto que tipea carácter por carácter y el texto idéntico que copia y pega. Piensa en una razón por la que tu estudiante puede creer esto o en algo que pueda haber sucedido para darle esa impresión. Luego, simula ser esa persona mientras tu pareja te explica por qué no es así. Intercambia roles con tu pareja y vuelve a probar.

Tu modelo ahora (toda la clase/5’)

Como clase, creen una lista de elementos clave de tu modelo mental de enseñanza. ¿Cuáles son los seis conceptos más importantes y cómo se relacionan?

Tus máquinas nocionales (grupos pequeños/20’)

En grupos pequeños, escriban una descripción de la máquina nocional que quieren que sus estudiantes usen para entender cómo corren sus programas. ¿En qué difiere una máquina nocional para un lenguaje basado en bloques como Scratch de la máquina nocional para Python? ¿Y en qué difiere de una máquina nocional para hojas de cálculo o para un buscador que está interpretando HTML⁴ y CSS⁵ cuando renderiza una página web?

Disfrutar sin aprender (individual/5’)

Muchos estudios han mostrado que las evaluaciones de la enseñanza no se correlacionan con los resultados de la enseñanza  [Star2014,Uttl2017], es decir, cuán alto sea el puntaje del grupo de estudiantes en un curso no predice cuánto recuerdan. ¿Alguna vez has disfrutado de una clase en la que en realidad no has aprendido nada? Si la respuesta es sí, ¿qué hizo que disfrutes esa clase?

Revisión

Pericia y memoria

La memoria es el remanente del pensamiento.
— Daniel Willingham, Por qué a las/los estudiantes no les gusta la escuela (Why Students Don’t Like School)

El capítulo anterior explicaba las diferencias entre personas novatas y practicantes competentes. En este capítulo se aborda la pericia: qué es, cómo se puede adquirir, y cómo puede ser tanto perjudicial como de ayuda. Luego haremos una introducción sobre uno de los límites más importantes en el aprendizaje y analizaremos cómo dibujar nuestros modelos mentales nos puede ayudar a convertir el conocimiento en lecciones.

Para empezar, ¿a qué nos referimos cuando decimos que alguien es una persona experta? La respuesta habitual es que puede resolver problemas mucho más rápido que la persona que es “simplemente competente”, o que puede reconocer y entender casos donde las reglas normales no se pueden aplicar. Es más, de alguna manera una persona experta hace que parezca que resolver ciertos problemas no requiere esfuerzo alguno: en muchos casos, parece saber la respuesta correcta de un vistazo [Parn2017].

Pericia es más que solo conocer más hechos: las/los practicantes competentes pueden memorizar una gran cantidad de trivialidades sin mejorar notablemente sus desempeños. En cambio, imagina por un momento que almacenamos conocimiento como una red o grafo en el cual los hechos son nodos y las relaciones son arcos⁶. La diferencia clave entre personas expertas y practicantes competentes es que los modelos mentales de las personas expertas están mucho más densamente conectados, es decir, es más probable que conozcan una conexión entre dos hechos cualesquiera.

La metáfora del grafo explica por qué ayudar a tus estudiantes a hacer conexiones es tan importante como presentarles los hechos: sin esas conexiones la gente no puede recordar y usar aquello que sabe. Esta metáfora también explica varios aspectos observados del comportamiento experto:

• Las personas expertas pueden saltar directamente de un problema a una solución porque realmente existe una conexión directa entre ambas cuestiones en sus mentes. Mientras una/un practicante competente debería razonar A → B → C → D → E, una persona experta puede ir de A a E en un único paso. Esto lo llamamos intuición: en vez de razonar su camino hacia una solución, la persona experta reconoce una solución de la misma manera que reconocería una cara familiar.

• Los grafos densamente conectados son también la base para la representación fluida de las personas expertas, es decir, sus habilidades para cambiar una y otra vez entre distintas formas de ver un problema [Petr2016]. Por ejemplo, tratando de resolver un problema en matemáticas, una persona experta puede cambiar entre abordarlo de manera geométrica a representarlo como un conjunto de ecuaciones.

• Esta metáfora también explica por qué las personas expertas son mejores en diagnósticos que las/los practicantes competentes: mayor cantidad de conexiones entre hechos hace más fácil razonar hacia atrás, de síntomas a causas. (Esta es la razón por la cual durante una entrevista de trabajo de desarrollo de software es preferible pedirle a las/los candidatas/os que depuren un programa a pedirles que programen: da una impresión más precisa de su habilidad.)

• Finalmente, las personas expertas están muchas veces tan familiarizadas con su tema que no pueden imaginarse cómo es no ver el mundo de esa manera. Esto implica que muchas veces están menos capacitadas para enseñar un tema que aquellas personas con menos experiencia, pero que aún recuerdan cómo lo aprendieron.

El último de estos puntos se llama punto ciego de las personas expertas. Como se definió originalmente en [Nath2003], es la tendencia de las personas expertas a organizar una explicación de acuerdo a los principios fundamentales del tema, en lugar de guiarse por aquello que ya conocen quienes están aprendiendo. Esto se puede superar con entrenamiento, pero es parte de la razón por la cual no hay correlación entre lo bien que investiga alguien en un área y lo bien que esa misma persona enseña la temática [Mars2002].

La letra S

Las personas expertas a menudo caen en sus puntos ciegos usando la palabra “solo,” como en, “Oh, es fácil, solo enciendes una nueva máquina virtual y luego solo instalas estos cuatro parches a Ubuntu y luego solo reescribes todo tu programa en un lenguaje funcional puro.” Como discutimos en el Capítulo 10, hacer esto indica que quien habla piensa que el problema es trivial y por lo tanto la persona que lucha con el problema debe ser estúpida: entonces, no tengas esta actitud.

Mapas conceptuales

La herramienta que elegimos para representar el modelo mental de alguien es un mapa conceptual, en el cual los hechos son burbujas y las conexiones son relaciones etiquetadas. Como ejemplos, la Figura 3.1 muestra por qué la Tierra tiene estaciones (de IHMC), y el Anexo 22 presenta mapas conceptuales de una biblioteca desde tres puntos de vista distintos.

Para mostrar cómo pueden ser usados los mapas conceptuales para enseñar programación, considera este bucle for en Python:

for letra in "abc":
    print(letra)

cuya salida es:

a
b
c

Las tres “cosas” claves en este bucle se muestran al principio de la Figura 3.2, pero son solo la mitad de la historia. La versión ampliada en la parte derecha de la figura muestra las relaciones entre esas cosas, las cuales son tan importantes para la comprensión como los conceptos en sí mismos.

Los mapas conceptuales pueden ser usados de varias maneras:

Para ayudar a docentes a descubrir qué están tratando de enseñar.

Un mapa conceptual separa el contenido del orden: en nuestra experiencia, las personas rara vez terminan enseñando las cosas en el orden en que las dibujaron por primera vez.

Para mejorar la comunicación entre quienes diseñan las lecciones

Si dos docentes tienen ideas muy diferentes de aquello que están tratando de enseñar, es probable que arrastren a sus estudiantes en diferentes direcciones. Dibujar y compartir mapas conceptuales puede ayudar a prevenirlo. Y sí: personas diferentes pueden tener mapas conceptuales diferentes para el mismo tema, pero el mapeo conceptual hace explícitas estas diferencias.

Para mejorar la comunicación con estudiantes.

Si bien es posible dar a tus estudiantes un mapa pre-dibujado al inicio de la lección para que puedan anotar, es mejor dibujarlo parte por parte mientras se está enseñando, para reforzar la relación entre lo que muestra el mapa y lo que tú dices. Volveremos a esta idea en la Sección 4.1.

Para evaluación.

Hacer que las/los estudiantes dibujen lo que creen que acaban de aprender le muestra a quien enseña lo que se pasó por alto y lo que se comunicó mal. Revisar los mapas conceptuales de estudiantes insume demasiado tiempo para utilizarlo como una evaluación formativa durante las clases, pero es muy útil en clases semanales una vez que tus estudiantes están familiarizadas/os con la técnica. La calificación es necesaria porque cualquier manera nueva de hacer algo, inicialmente enlentece a la gente—si quien está aprendiendo intenta encontrarle el sentido a la programación básica, pedirle que se imagine cómo esquematizar sus pensamientos al mismo tiempo es una carga que no conviene realizar.

Algunas/os docentes son escépticas/os a que las personas novatas puedan mapear efectivamente lo que entendieron, dado que la introspección y la explicación de lo entendido son generalmente habilidades más avanzadas que la comprensión en sí misma. Por ejemplo, [Kepp2008] observó el uso del mapeo conceptual en la enseñanza de computación. Uno de los hallazgos fue que “… el mapeo conceptual es problemático para muchas/os estudiantes porque evalúa la comprensión personal en lugar del conocimiento que simplemente se aprendió de memoria.” Como alguien que valora la comprensión sobre el conocimiento de memoria, lo considero un beneficio.

Comienza por cualquier lugar

Cuando se pide por primera vez dibujar un mapa conceptual, muchas personas no saben por dónde empezar. Si esto ocurre, escribe dos palabras asociadas con el tema que estás tratando de mapear, luego dibuja una línea entre ellas y agrega una etiqueta explicando cómo estas dos ideas están relacionadas. Puedes entonces preguntarte qué otras cosas están relacionadas en el mismo sentido, qué partes tienen esas cosas, o qué sucede antes o después con los conceptos que ya están en la hoja a fin de descubrir más nodos y arcos. Después de eso, casi siempre la parte más difícil está terminada.

Los mapas conceptuales son solo una forma de representar nuestro conocimiento de un tema [Eppl2006]; otros incluyen diagramas de Venn, diagramas de flujo y árboles de decisión [Abel2009]. Todos estos esquemas externalizan la cognición, es decir, hacen visibles los modelos mentales de manera que pueden ser comparados y combinados⁷.

Trabajo crudo y honestidad

Muchas/os diseñadoras/es de interfaces de usuaria/o creen que es mejor mostrar bocetos de sus ideas en lugar de maquetas pulidas, porque es más probable que las personas den una opinión honesta sobre algo que presumen que tiene pocos minutos de elaboración. Si parece que el trabajo requirió horas, la mayoría de las personas suavizará sus críticas. Al dibujar mapas conceptuales para motivar un intercambio de ideas, deberías entonces usar lápices y papel borrador (o marcadores y una pizarra) en lugar de sofisticadas herramientas de dibujo por computadora.

Siete más o menos dos

Mientras el modelo gráfico de conocimiento es incorrecto pero útil, otro modelo simple tiene bases fisiológicas profundas. Como una aproximación rápida, la memoria humana se puede dividir en dos capas distintas. La primera, llamada memoria a largo plazo o memoria persistente, es donde almacenamos cosas como los nombres de nuestra gente amiga, nuestra dirección, y lo que hizo un payaso en nuestra fiesta de cumpleaños de ocho que nos asustó mucho. La capacidad de esta capa de memoria es esencialmente ilimitada, pero es de acceso lento—demasiado lento para ayudarnos a lidiar con leones hambrientos y familiares descontentos.

La evolución entonces nos ha dado un segundo sistema llamado memoria a corto plazo o memoria de trabajo. Es mucho más rápida, pero también más pequeña: [Mill1956] estimó que la memoria de trabajo del adulto promedio solo podía contener 7 ± 2 elementos a la vez. Esta es la razón por la cual los números de teléfono son de 7 u 8 dígitos de longitud: antes los teléfonos tenían un disco en vez de teclado y esa era la cadena de números más larga que la mayoría de los adultos podía recordar con precisión durante el tiempo que tardaba el disco en girar varias veces.

Participación

El tamaño de la memoria de trabajo a veces se usa para explicar por qué los equipos deportivos tienden a formarse con aproximadamente media docena de miembros o se separan en sub-grupos como delanteras/os y línea de tres cuartos en rugby. También se usa para explicar por qué las reuniones solo son productivas hasta un cierto número de participantes: si veinte personas tratan de discutir algo, o bien se arman tres reuniones al mismo tiempo o media docena de personas hablan mientras los demás escuchan. El argumento es que la habilidad de las personas para llevar registro de sus pares está limitada al tamaño de la memoria de trabajo, pero hasta donde sé, esta aseveración jamás fue probada.

7±2 es simplemente el número más importante al enseñar. Quien enseña no puede colocar información directamente en la memoria a largo plazo de una/un estudiante. En cambio, cualquier cosa que presente se almacena primero en la memoria a corto plazo de cada estudiante y solo se transfiere a la memoria a largo plazo después que ha sido mantenida ahí y ensayada (Sección 5.1). Si quien enseña presenta demasiados contenidos y muy rápidamente, la vieja información no llega a transferirse a tiempo antes de ser desplazada por la nueva información.

Esta es una de las maneras de usar mapas conceptuales al diseñar una lección: sirve para asegurarse que la memoria a corto plazo de tus estudiantes no estará sobrecargada. Con el mapa ya diseñado, la/el docente elige un fragmento apropiado para la memoria a corto plazo, el cual llevará a una evaluación formativa (Figura 3.3); en la próxima lección continuará con otro fragmento del mapa conceptual, y así sucesivamente.

Construyendo juntos mapas conceptuales

La próxima vez que tengas una reunión de equipo, entrega a cada persona una hoja de papel y pídeles que pasen unos minutos dibujando sus propios mapas conceptuales sobre el proyecto en el que están trabajando. A la cuenta de tres, haz que todos revelen sus mapas conceptuales al grupo. La discusión que sigue puede ayudar a las personas a comprender por qué han estado tropezando.

Ten en cuenta que el modelo simple de memoria presentado aquí ha sido reemplazado en gran medida por uno más sofisticado, en el que la memoria a corto plazo se divide en varios almacenamientos (p. ej. para memoria visual versus memoria lingüística), cada uno de los cuales realiza un preprocesamiento involuntario [Mill2016a]. Nuestra presentación es entonces un ejemplo de un modelo mental que ayuda al aprendizaje y al trabajo diario.

Reconocimiento de patrones

Investigaciones recientes sugieren que el tamaño real de la memoria a corto plazo podría ser tan bajo como 4±1 elementos [Dida2016]. Para manejar conjuntos de información más grandes, nuestras mentes crean fragmentos. Por ejemplo, en general recordamos a las palabras como elementos simples más que como secuencia de letras. Del mismo modo, el patrón formado por cinco puntos en cartas o dados se recuerda como un todo en lugar de cinco piezas de información separadas.

Las personas expertas tienen más fragmentos y de mayor tamaño que las no-expertas, p.ej.`̀ven” patrones más grandes y tienen más patrones con los que contrastar cosas. Esto les permite razonar a un nivel superior y buscar información de manera más rápida y precisa. Sin embargo, la fragmentación también puede engañarnos si identificamos mal las cosas: quienes recién llegan a veces pueden ver cosas que personas expertas han visto y pasado por alto.

Dada la importancia de la fragmentación para pensar, es tentador identificar patrones de diseño y enseñarlos directamente. Estos patrones ayudan a practicantes competentes a pensar y dialogar en varios dominios (incluida la enseñanza [Berg2012]), pero los catálogos de patrones son demasiado duros y abstractos para que personas novatas les encuentren sentido por su cuenta. Dicho esto, asignar nombres a un pequeño número de patrones parece ayudar con la enseñanza, principalmente dando a tus estudiantes un vocabulario más rico para pensar y comunicarse [Kuit2004,Byck2005,Saja2006]. Volveremos a este tema en la Sección 7.5.

Convirtiéndose en una persona experta

Entonces, ¿cómo se convierte alguien en una persona experta? La idea de que hacen falta diez mil horas de práctica para conseguirlo es ampliamente citada, pero probablemente no sea verdad: hacer lo mismo una y otra vez es más probable que fortalezca los malos hábitos a que mejore la práctica. Lo que realmente funciona es hacer cosas similares pero sutilmente diferentes, prestando atención a qué funciona y qué no, y luego cambiando el comportamiento en respuesta a esta retroalimentación, para así mejorar de forma acumulativa. Esto se llama práctica deliberada o práctica reflectiva, y es común que las personas atraviesen tres etapas:

Actuar según la devolución de otros.

Las/los estudiantes pueden escribir un ensayo sobre qué hicieron en sus vacaciones de verano y recibir devoluciones de una/un docente que les indique cómo mejorarlo.

Dar devoluciones sobre el trabajo de otras/os.

Las/los estudiantes pueden realizar críticas de la evolución de un personaje en la novela de Jorge Amado Doña Flor y sus dos maridos. y recibir una devolución de una/un docente sobre esas críticas.

Darse devoluciones a sí misma/o.

En algún punto, las/los estudiantes empiezan a criticar sus propios trabajos con las habilidades que ya han construido. Dado que autocriticarse es mucho más rápido que esperar los comentarios de otras personas, esta aptitud comenzará a desarrollarse de un momento a otro.

¿Qué cuenta como práctica deliberada?

[Macn2014] descubrió que “…la práctica deliberada explicaba el 26% de la varianza en el rendimiento de los juegos, 21% para música, 18% para deportes, 4% para educación, y menos del 1% para profesiones.” Sin embargo, [Eric2016] criticó este hallazgo diciendo: “Resumir cada hora de cualquier tipo de práctica durante la carrera de un individuo implica que el impacto de todos los tipos de actividad práctica respecto a rendimiento es igual ——una suposición que…es inconsistente con la evidencia.” Para ser efectiva, la práctica deliberada requiere tanto un objetivo de rendimiento claro como una devolución informativa inmediata. Se trata de dos cosas que las/los docentes deberían esforzarse en conseguir.

Ejercicios

Mapear conceptos (parejas/30’)

Dibuja un mapa conceptual sobre algo que puedas enseñar en cinco minutos. Discute con tu colega y critiquen el mapa que cada cual elaboró. ¿Presentan conceptos o detalles superficiales? ¿Cuáles de las relaciones en el mapa de tu colega consideras conceptos y viceversa?

Mapeo de conceptos (nuevamente) (grupos pequeños/20’)

La clase se divide en grupos de 3–4 personas. En cada grupo, cada persona diseña por su cuenta un mapa conceptual que muestre un modelo mental sobre qué sucede en un aula. Cuando todas las personas del grupo hayan terminado, comparen los mapas conceptuales. ¿En qué coinciden y difieren sus modelos mentales?

Mejora de la memoria a corto plazo (individual/5’)

[Cher2007] sugiere que la razón principal por la que las personas dibujan diagramas cuando discuten cosas es para ampliar su memoria a corto plazo: señalar una burbuja dibujada hace unos minutos provoca el recuerdo de varios minutos de debate. Cuando intercambiaste mapas conceptuales en el ejercicio anterior, ¿qué tan fácil fue para otras personas entender lo que significaba tu mapa? ¿qué tan fácil sería para ti si lo dejas de lado por un día o dos y luego lo miras de nuevo?

Eso es un poco autorreferencial, ¿no? (toda la clase/30’)

Trabajando independientemente, dibuja un mapa conceptual sobre mapas conceptuales. Compara tu mapa conceptual con aquellos dibujados por las demás personas. ¿Qué incluyeron la mayoría de las personas? ¿Cuáles fueron las diferencias más significativas?

Notar tus puntos ciegos (grupos pequeños/10’)

Elizabeth Wickes listó todo lo que necesitas saber para entender y leer esta línea de Python:

respuestas = ['tuatara', 'tuataras', 'bus', "lick"]

• Los corchetes rodeando el contenido significan que estamos trabajando con una lista (a diferencia de los corchetes inmediatamente a la derecha de algo, que es la notación utilizada para extraer datos).

• Los elementos se separan por comas fuera de las comillas (si las comas estuvieran dentro de las comillas, sería la cita de un texto).

• Cada elemento es una cadena de caracteres, y lo sabemos por las comillas. Aquí podríamos tener números u otro tipo de datos si quisiéramos; necesitamos comillas porque estamos trabajando con cadenas de caracteres.

• Estamos mezclando el uso de comillas simples y dobles; a Python no le importa eso siempre que estén balanceadas alrededor de las cadenas individuales (por cada comilla que abre, una comilla que cierre).

• A cada coma le sigue un espacio, lo cual no es obligatorio para Python, pero lo preferimos para una lectura más clara.

Cada uno de estos detalles no sería ni percibido por una persona experta. Trabajando en grupos de 3–4 personas, selecciona algo igualmente corto de una lección que hayas enseñado o aprendido y divídelo a este nivel de detalle.

Qué enseñar a continuación (individual/5’)

Vuelve al mapa conceptual para la fotosíntesis de la Figura 3.3. ¿Cuántos conceptos y relaciones hay en los fragmentos seleccionados? ¿Qué incluirías en el próximo fragmento de la lección y por qué?

El poder de fragmentación (individual/5’)

Mira la Figura 3.4 por 10 segundos, luego mira hacia otro lado e intenta escribir tu número de teléfono con estos símbolos⁸. (Usa un espacio para ’0’.) Cuando hayas terminado, mira la representación alternativa en el Anexo 23. ¿Cuánto más fáciles de recordar son los símbolos cuando el patrón se hace explícito?

Arquitectura cognitiva

Hemos hablado acerca de modelos mentales como si fueran cosas reales, pero ¿qué es lo que realmente sucede en el cerebro de una persona cuando está aprendiendo? La respuesta corta es que no lo sabemos, la respuesta larga es que sabemos mucho más que antes. Este capítulo profundizará en qué hace el cerebro mientras el aprendizaje sucede y en cómo podemos aprovecharlo para diseñar y brindar lecciones de manera más efectiva.

¿Qué es lo que sucede allí?

La Figura 4.1 es un modelo simplificado de la arquitectura cognitiva humana. El núcleo de este modelo es la separación entre la memoria a corto y a largo plazo vistas en la Sección 3.2. La memoria a largo plazo es como tu sótano: almacena objetos de forma más o menos permanente pero tu conciencia no puede acceder a ella directamente. En cambio, confías en tu memoria a corto plazo, que es como el escritorio de tu mente.

Cuando necesitas algo, tu cerebro lo rescata de la memoria a largo plazo y lo coloca en la memoria a corto plazo. Por el contrario, la nueva información que llega a la memoria a corto plazo debe codificarse para poder ser almacenada en la memoria a largo plazo. Si esa información no está codificada y almacenada, no se recuerda y esto significa que no se ha aprendido.

La información ingresa a la memoria a corto plazo principalmente a través de tu canal verbal (para el habla) y del canal visual (para las imágenes)⁹. Si bien la mayoría de las personas confía principalmente en su canal visual, cuando las imágenes y las palabras se complementan entre sí el cerebro hace un mejor trabajo al recordarlas: se codifican juntas, de modo que el recuerdo de una ayuda a activar el recuerdo de la otra.

Las entradas lingüísticas y visuales son procesadas por diferentes partes del cerebro humano y a su vez los recuerdos lingüísticos y visuales son almacenados también de manera separada. Esto significa que correlacionar flujos de información lingüísticos y visuales requiere esfuerzo cognitivo: si alguien lee algo mientras lo escucha en voz alta, su cerebro no puede evitar comprobar que obtiene la misma información por ambos canales.

Por lo tanto, el aprendizaje aumenta cuando la información se presenta de manera simultánea por dos canales diferentes, pero se reduce cuando esa información es redundante, en lugar de ser complementaria: tal fenómeno es conocido como efecto de atención dividida [Maye2003]. Por ejemplo, en general las personas encuentran más difícil aprender de un video que tiene narración y capturas de pantalla que aprender de un video que únicamente tiene narración ó capturas (pero no ambos elementos), porque en el primer caso parte de su atención ha sido utilizada para chequear que la narración y las capturas se correspondan entre sí. Dos notables excepciones son las personas que aún no hablan bien un idioma y las que tienen algún impedimento auditivo u otras necesidades especiales, quienes quizás encuentren que el valor de la información redundante supera el esfuerzo de procesamiento adicional.

Fragmento a fragmento

El efecto de la atención dividida explica por qué es más efectivo dibujar un diagrama fragmento a fragmento mientras enseñas, en lugar de presentar todo el gráfico de una sola vez. Si las partes de un diagrama aparecen al mismo tiempo en que los gráficos son explicados, el/la estudiante correlaciona ambos elementos en su memoria. Así que luego, al enfocarte en una parte del diagrama, es más probable que tu estudiante active la recuperación de lo que fue dicho cuando esa parte fue dibujada.

El efecto de la atención dividida no significa que los/las estudiantes no deberían intentar conciliar múltiples flujos de información entrantes —después de todo, esto es lo que tienen que hacer en el mundo real [Atki2000]—. En cambio, significa que la instrucción no debería solicitar a las personas que lo hagan mientras están incorporando habilidades por primera vez: el uso de múltiples fuentes de información de manera simultánea debe tratarse como una tarea de aprendizaje separada.

No todos los gráficos son equivalentes

[Sung2012] presenta un elegante estudio que distingue los gráficos seductores (los cuales son altamente interesantes pero no son directamente relevantes al objetivo de la enseñanza), los gráficos decorativos (los cuales son neutros pero no son directamente relevantes al objetivo de la enseñanza), y por último los gráficos instructivos (los cuales sí son directamente relevantes al objetivo de la enseñanza). Los/las estudiantes que recibieron cualquier tipo de gráfico calificaron al material con un mayor puntaje, pero en verdad solo quienes recibieron gráficos instructivos obtuvieron mejores resultados.

Del mismo modo, [Stam2013,Stam2014] descubrió que tener más información en realidad puede disminuir el rendimiento. Les mostraron a niños/as: imágenes, imágenes más números, o simplemente números, para que realicen dos tareas. Para algunos/as niños/as, recibir imágenes o bien imágenes más números fue mejor que recibir únicamente números; pero para otros/as, recibir imágenes superó a recibir imágenes más números, lo que superó a solo tener números.

Carga cognitiva

En [Kirs2006], Kirschner, Sweller y Clark escribieron:

Aunque los enfoques educativos no guiados o mínimamente guiados son muy populares e intuitivamente atractivos…estos enfoques ignoran las estructuras que constituyen la arquitectura cognitiva humana así como la evidencia de estudios empíricos de los últimos cincuenta años. Dichas evidencias indican sistemáticamente que la instrucción guiada mínimamente es menos eficaz y menos eficiente que los enfoques educacionales con un fuerte énfasis en la orientación del proceso de aprendizaje del estudiante. La ventaja de la orientación disminuye sólo cuando los/las estudiantes tienen un conocimiento previo suficientemente elevado para proporcionar una orientación “interna”.

Más allá de la jerga, lo que estos autores afirmaban es que el hecho de que los/las estudiantes hagan sus propias preguntas, establezcan sus propias metas y encuentren su propio camino a través de un tema es menos efectivo que mostrarles cómo hacer las cosas paso a paso. El enfoque “elige tu propia aventura” se conoce como aprendizaje basado en la indagación y es intuitivamente atractivo: después de todo, ¿quién se opondría a tener estudiantes que utilicen su propia iniciativa para resolver problemas del mundo real de forma realista? Sin embargo, pedir a los/las estudiantes que lo hagan en un nuevo dominio es una sobrecarga, ya que les exige que dominen al mismo tiempo el contenido fáctico de un dominio y las estrategias de resolución de problemas. Más específicamente, la teoría de la carga cognitiva propone que las personas tienen que lidiar con tres cosas cuando está aprendiendo:

Carga intrínseca

es lo que las personas tienen que tener en cuenta para aprender el material nuevo.

Carga pertinente

es el esfuerzo mental (deseable) requerido para vincular la nueva información con la antigua, que es una de las distinciones entre el aprendizaje y la memorización.

Carga extrínseca

es cualquier cuestión que distraiga del aprendizaje.

La teoría de la carga cognitiva sostiene que las personas tienen que dividir una cantidad fija de memoria de trabajo entre estas tres cosas. Nuestro objetivo como docentes es maximizar la memoria disponible para manejar la carga intrínseca, lo cual significa reducir la carga pertinente en cada paso y eliminar la carga extrínseca.

Problemas de Parsons

Un tipo de ejercicio que puede ser explicado en términos de carga cognitiva se utiliza a menudo en la enseñanza de idiomas. Supongamos que le pides a alguien que traduzca la frase “¿Cómo está tu rodilla hoy?” de castellano a catalán. Para resolver el problema, necesitan recordar tanto el vocabulario como la gramática, que es una carga cognitiva doble. Si, en lugar de traducir desde cero, les pides que pongan “com”, “està”, “el”, “teu”, “genoll” y “avui” en el orden correcto, les permites que se centren únicamente en el aprendizaje de la gramática. Sin embargo, si escribes estas palabras en seis fuentes o colores diferentes, has aumentado la carga cognitiva extrínseca, porque involuntariamente (y posiblemente de manera inconsciente) invertirán algo de esfuerzo tratando de averiguar si las diferencias entre las palabras son significativas de acuerdo a sus colores (Figura 4.2).

El equivalente en programación de este ejemplo se llama problema de Parsons¹⁰ [Pars2006].

Cuando enseñes a programar, puedes darles a tus estudiantes las líneas de código que necesitan para resolver un problema y pedirles que las ordenen en el orden correcto. Esto les permite concentrarse en el flujo de control y en las dependencias de datos, sin distraerse con la denominación de las variables o tratando de recordar qué funciones llamar. Múltiples estudios han demostrado que los problemas de Parsons demandan menos tiempo de resolución y producen resultados educativos equivalentes [Eric2017].

Ejemplos desvanecidos (o con espacios en blanco)

Otro tipo de ejercicio que se puede explicar en términos de carga cognitiva es dar a tus estudiantes una serie de ejemplos desvanecidos (faded examples en inglés). El primer ejemplo de una serie presenta un uso completo de una estrategia particular de resolución de problemas. El siguiente problema es del mismo tipo, pero tiene algunas lagunas que tu estudiante debe llenar. Cada problema sucesivo da menos andamiaje (scaffolding en inglés), hasta que se pide resolver un problema completo desde cero. Al enseñar álgebra en la escuela secundaria, por ejemplo, podríamos comenzar con esto:

y luego pedir que los/las estudiantes resuelvan esto:

y esto:

y, finalmente, esto:

Un ejercicio similar para enseñar Python podría comenzar mostrando a estudiantes cómo encontrar la longitud total de una lista de palabras:

# largo_total(["rojo", "verde", "azul"]) => 12
define largo_total(lista_de_palabras):
    total = 0
    for palabra in lista_de_palabras:
        total = total + length(palabra)
    return total

y luego pidiendo que llenen los espacios en blanco en este otro código (lo que centra su atención en las estructuras de control):

# largo_palabra(["rojo", "verde", "azul"]) => [3, 5, 4]
define largo_palabra(lista_de_palabras):
    lista_de_longitudes = []
    for ____ in ____:
        append(lista_de_longitudes, ____)
    return lista_de_longitudes

El siguiente problema podría ser este (que centra su atención en actualizar el resultado final):

# juntar_todo(["rojo", "verde", "azul"]) => "rojoverdeazul"
define juntar_todo(lista_de_palabras):
    palabras_unidas = ____
    for ____ in ____:
        ____
    return palabras_unidas

Finalmente, los/las estudiantes tendrán que escribir una función completa por su cuenta:

# generar_acronimo(["rojo", "verde", "azul"]) => "RVA"
define generar_acronimo(lista_de_palabras):
    ____

Los ejemplos desvanecidos funcionan porque presentan la estrategia de resolución de problemas fragmento por fragmento. En cada paso, los/las estudiantes tienen un nuevo problema que abordar, lo cual es menos intimidante que una pantalla en blanco o una hoja de papel en blanco (Sección 9.11). También anima a que los/las estudiantes piensen en las similitudes y diferencias entre varios enfoques, lo que ayuda a crear los vínculos en sus modelos mentales y de ese modo facilita la recuperación de la información.

La clave para construir un buen ejemplo desvanecido es pensar en la estrategia de resolución de problemas que se pretende enseñar. Por ejemplo, los problemas de programación sobre todo utilizan el patrón de diseño acumulativo, en el que los resultados del procesamiento de elementos de una colección se agregan repetidamente a una sola variable de alguna manera para crear el resultado final.

Aprendizaje cognitivo

Un modelo alternativo de aprendizaje e instrucción que también usa andamiaje y desvanecimiento es el aprendizaje cognitivo, que enfatiza la forma en que un/a docente transmite habilidades y conocimientos a un/a estudiante. El/la docente proporciona modelos de desempeño y resultados, luego entrena a las personas novatas explicando qué están haciendo y por qué [Coll1991,Casp2007]. El/la estudiante reflexiona sobre su propia resolución de problemas, por ejemplo, pensando en voz alta o criticando su propio trabajo, y finalmente explora problemas de su propia elección.

Este modelo nos dice que los/las docentes deben presentar varios ejemplos al explicar una nueva idea para que los/las estudiantes puedan ver qué generalizar, y que deben variar la forma del problema para dejar en claro cuáles son y cuáles no son características superficiales¹¹. Los problemas deben presentarse en contextos del mundo real, y debemos fomentar la autoexplicación para ayudar a los/las estudiantes a organizarse y dar sentido a lo que se les acaba de enseñar (Sección 5.1).

Sub-objetivos etiquetados

Etiquetar sub-objetivos significa dar nombre a los pasos en una descripción paso a paso de un proceso de resolución de problemas. [Marg2016,Morr2016] descubrieron que al etiquetar los subobjetivos, los/las estudiantes resolvían mejor los problemas de Parsons, y se observa el mismo beneficio en otros dominios [Marg2012]. Volviendo al ejemplo de Python usado anteriormente, los objetivos secundarios para encontrar la longitud total de una lista de palabras o construir un acrónimo son:

1. Crea un valor vacío del tipo a obtener.

2. A partir de la variable del bucle, obtén el valor que se agregará al resultado.

3. Actualiza el resultado con ese valor.

Etiquetar subobjetivos funciona porque agrupar los pasos relacionados en fragmentos con nombre (Sección 3.2) ayuda a tus estudiantes a distinguir lo que es genérico de lo que es específico del problema en cuestión. También les ayuda a construir un modelo mental de ese tipo de problema, de modo que luego pueden resolver otros problemas de ese tipo, y les da una oportunidad natural para la autoexplicación (Sección 5.1).

Manuales mínimos

La aplicación más pura de la teoría de la carga cognitiva puede ser el manual mínimo de John Carroll [Carr1987,Carr2014]. Su punto de partida es una cita de un usuario: “Quiero aprender a hacer algo, no aprender a hacer todo”. Carroll y sus colegas rediseñaron la capacitación para presentar cada idea como una tarea autónoma de una sola página: un título que describa de qué trata la página, instrucciones paso a paso sobre cómo hacer una sola cosa (por ejemplo, cómo eliminar una línea en blanco en un editor de texto) y luego varias notas sobre cómo reconocer y resolver problemas comunes. Descubrieron que reescribir los materiales de capacitación de esta manera los hacía más cortos en general y que las personas que los usaban aprendían más rápido. Estudios posteriores confirmaron que este enfoque superó al enfoque tradicional independientemente de la experiencia previa con computadoras [Lazo1993]. [Carr2014] resumieron este trabajo diciendo:

Nuestros diseños “minimalistas” buscaban aprovechar la iniciativa de cada usuario/a y el conocimiento previo, en lugar de controlarlo mediante advertencias y pasos ordenados. Se enfatizaba que los/las usuarios/as generalmente aportan mucha experiencia y conocimiento a este aprendizaje, por ejemplo, conocimiento sobre el dominio de la tarea, y que dicho conocimiento podría ser un recurso para los/as diseñadores/as de instructivos. El minimalismo aprovechó los episodios de reconocimiento, diagnóstico y corrección de errores, en lugar de intentar simplemente prevenirlos. Es decir, enmarcó la resolución de problemas y la corrección como oportunidades de aprendizaje en lugar de aberraciones.

Otros modelos de aprendizaje

Quienes critican la teoría de la carga cognitiva a veces han argumentado que cualquier resultado puede justificarse a posteriori al etiquetar como carga extrínseca a aquello que perjudica el rendimiento y como carga intrínseca o pertinente a aquello que no lo perjudica. Sin embargo, la instrucción basada en la teoría de la carga cognitiva es innegablemente efectiva. Por ejemplo, [Maso2016] rediseñó un curso de base de datos para eliminar la atención dividida y los efectos de redundancia y para proporcionar ejemplos prácticos y con subobjetivos. El nuevo curso redujo la tasa de reprobación del examen en un 34% y aumentó la satisfacción de los/las estudiantes.

Una década después de la publicación de [Kirs2006], un número creciente de personas cree que la teoría de la carga cognitiva y los enfoques basados en la investigación son compatibles si se ven de la manera correcta. [Kaly2015] sostiene que la teoría de la carga cognitiva es básicamente una microgestión del aprendizaje dentro de un contexto más amplio que considera cuestiones como la motivación, mientras que [Kirs2018] extiende la teoría de la carga cognitiva para incluir aspectos colaborativos del aprendizaje. Al igual que con [Mark2018] (discutido en la Sección 5.1), las perspectivas de los/las investigadores/as pueden diferir, pero la implementación práctica de sus teorías a menudo termina siendo la misma.

Uno de los desafíos en la investigación educativa es que lo que queremos decir con “aprendizaje” resulta complicado una vez que se mira más allá del aula occidental estandarizada. Dos perspectivas específicas de la psicología educacional han influido en este libro. La que hemos utilizado hasta ahora es el cognitivismo, que se centra en conceptos como el reconocimiento de patrones, la formación de la memoria y el recuerdo. Es bueno para responder preguntas de bajo nivel, pero generalmente ignora cuestiones más importantes como, “¿Qué queremos decir con ’aprendizaje’?” y “¿Quién tiene poder de decisión?” La segunda perspectiva utilizada es el aprendizaje situado, que se centra en integrar a las personas en una comunidad y reconoce que la enseñanza y el aprendizaje siempre están arraigados en quiénes somos y quiénes aspiramos a ser. Lo discutiremos con más detalle en el Capítulo 13.

El sitio web de Teorías de Aprendizaje (Learning Theories en inglés) y [Wibu2016] tienen buenos resúmenes de estas y otras perspectivas. Además del cognitivismo, las que se encuentran con mayor frecuencia incluyen el conductismo (que trata la educación como un condicionamiento de estímulo/respuesta), el constructivismo (que considera al aprendizaje como un proceso activo durante el cual los/las estudiantes construyen conocimiento por sí mismos/as) y el conectivismo (que sostiene que el conocimiento se distribuye, que el aprendizaje es el proceso de navegar, crecer y podar conexiones, y que enfatiza los aspectos sociales del aprendizaje que internet hace posible). Estas perspectivas pueden ayudarnos a organizar nuestros pensamientos, pero en la práctica siempre tenemos que probar nuevos métodos en clase, con estudiantes reales, para descubrir qué tan bien equilibran las muchas fuerzas en juego.

Ejercicios

Crear un ejemplo desvanecido (parejas/30’)

Es muy común que en los programas se cuenten cuántas cosas caen en diferentes categorías: por ejemplo, cuántas veces aparecen colores diferentes en una imagen o cuántas veces aparecen palabras diferentes en un párrafo de texto.

1. Crea un ejemplo breve (no más de 10 líneas de código) que muestre a las personas cómo hacer esta tarea. Luego, crea un segundo ejemplo que resuelva un problema similar de una manera similar, pero que tenga un par de espacios en blanco para que los/las estudiantes los completen. ¿Cómo decides qué desvanecer? ¿Cuál sería el siguiente ejemplo de la serie?

2. Define el público de tus ejemplos. Por ejemplo, ¿son personas novatas que solo conocen algunos conceptos básicos de programación? ¿O son estudiantes con alguna experiencia en programación?

3. Muestra tu ejemplo a tu pareja, pero no le digas para qué nivel crees que es. Una vez que tu pareja haya llenado los espacios en blanco, pídele que adivine el nivel de estudiante previsto.

Si entre tus estudiantes hay personas que no programan en absoluto, intenta ubicarlos en diferentes grupos y pídeles que hagan el papel de estudiantes en sus grupos. Alternativamente, elige un dominio de problema diferente con el que desarrollar tu ejemplo desvanecido.

Clasificación de carga (grupos pequeños/15’)

1. Elige una lección corta que alguna persona de tu grupo haya enseñado o tomado recientemente.

2. Haz un listado con viñetas de las ideas, instrucciones y explicaciones que contiene la lección.

3. Clasifica cada elemento de tu listado como carga intrínseca, pertinente o extrínseca. ¿En qué ítems todas las personas del grupo estuvieron de acuerdo? ¿En cuáles estuvieron en desacuerdo y por qué?

(El ejercicio “Notar tus puntos ciegos” en la Sección 3.4 te dará una idea de cuán detallado debe ser tu listado de ítems).

Crear un problema de Parsons (en parejas/20’)

Escribe cinco o seis líneas de código que hagan algo útil, mézclalas y pídele a tu pareja que las ponga en orden. Si estás utilizando un lenguaje basado en indentación como Python, no utilices sangría en ninguna de las líneas; si estás utilizando un lenguaje de llaves como Java, no incluyas ninguna de las llaves. (Si tu grupo incluye personas que no programan, usa un dominio de problema diferente, como, por ejemplo, hacer budín de pan).

Manuales mínimos (individual/20’)

Escribe una guía de una página para hacer algo que tus estudiantes puedan encontrar en una de tus clases, como centrar el texto horizontalmente o imprimir un número con un cierto número de dígitos después del punto decimal. Intenta enumerar al menos tres o cuatro resultados incorrectos que tu estudiante pueda obtener e incluye una explicación de una o dos líneas de por qué ocurre cada uno y cómo corregirlo.

Aprendizaje cognitivo (parejas/15’)

Elige un problema de codificación que puedas resolver en dos o tres minutos y piensa en voz alta mientras lo resuelves, al mismo tiempo tu pareja te hace preguntas sobre lo que estás haciendo y por qué. No solo explica lo que estás haciendo, sino también por qué lo estás haciendo, cómo sabes que es lo correcto y qué alternativas has considerado pero descartado. Cuando hayas terminado, intercambia roles con tu pareja y repite el ejercicio.

Ejemplos resueltos (parejas/15’)

Ver ejemplos resueltos ayuda a las personas a aprender a programar más rápido que simplemente escribiendo mucho código [Skud2014], y desconstruir el código rastreándolo o depurándolo también aumenta el aprendizaje [Grif2016]. Trabajando en parejas, revisa un fragmento de código de 10 a 15 líneas y explica qué hace cada declaración y por qué es necesaria. ¿Cuánto tiempo demoras? ¿Cuántas cosas crees que necesitas explicar por línea de código?

Gráficos críticos (individual/30’)

[Maye2009,Mill2016a] presentan seis principios para una buena enseñanza de gráficos:

Señalización:

resalta visualmente los puntos más importantes para que se destaquen del material menos crítico.

Contigüidad espacial:

coloca los subtítulos lo más cerca posible de los gráficos para compensar el costo de cambiar entre la imagen y el texto.

Contigüidad temporal:

Presenta narraciones habladas y gráficos tan seguidos en el tiempo como sea práctico. (Presentar ambos a la vez es mejor que presentarlos uno tras otro).

Segmentación:

Cuando presentes una secuencia larga de material o cuando tus estudiantes no tengan experiencia en el tema, divide la presentación en segmentos cortos y deja que los/las estudiantes controlen la rapidez con que avanzan al siguiente.

Pre-entrenamiento:

Si tus estudiantes no conocen los conceptos y la terminología principales que utilizas en la presentación, enseña solo esos conceptos y términos de antemano.

Modalidad:

las personas aprenden mejor de las imágenes con narración que de las imágenes con texto, a menos que no sean hablantes nativas del idioma de la lección o que haya palabras o símbolos técnicos.

Elige un video de una lección o charla en línea que utilice diapositivas u otras presentaciones estáticas y califica sus gráficos como “deficientes”, “promedio” o “buenos” de acuerdo con estos seis criterios.

Revisión

Aprendizaje individual

Los capítulos previos han explorado cómo las/los docentes pueden ayudar a sus estudiantes. Este capítulo se enfoca en cómo las/los estudiantes pueden ayudarse a sí mismas/os al cambiar sus estrategias de estudio y descansar lo necesario.

La estrategia más efectiva es hacer un cambio de aprendizaje pasivo a aprendizaje activo [Hpl2018], ya que mejora la tasa de rendimiento y reduce la tasa de fracaso [Free2014]:

Pasivo	Activo
Leer sobre un tema	Hacer ejercicios
Mirar un video	Discutir un tema
Asistir a una clase	Tratar de explicar un tema

Si hacemos referencia a nuestro modelo simplificado de arquitectura cognitiva (Figura 4.1), el aprendizaje activo es más efectivo porque retiene la información nueva en la memoria a corto plazo por más tiempo, lo cual aumenta la probabilidad que sea codificada con éxito y almacenada en la memoria a largo plazo. Al usar la nueva información a medida que llega, tus estudiantes pueden construir y fortalecer los lazos entre la información nueva y la información que ya poseen, lo cual a su vez incrementa las chances de que puedan recuperarla más tarde.

La otra clave para poder sacarle más provecho al aprendizaje es la metacognición o, en otras palabras, pensar sobre lo que una/uno está pensando. Así como las/los músicas/os escuchan lo que están tocando, y las/los buenas/os docentes reflexionan sobre su enseñanza (Capítulo 8), tus estudiantes aprenderán mejor y más rápido si hacen planes, fijan metas y monitorean su progreso. Para tus estudiantes es difícil dominar estas habilidades en abstracto—no tiene ningún efecto decirles simplemente que planifiquen—pero las lecciones pueden diseñarse para motivar buenas prácticas de estudio. Al hacer referencia a dichas prácticas en la clase, ayudas a tus estudiantes a darse cuenta de que aprender es una habilidad que pueden mejorar, como cualquier otra [McGu2015,Miya2018].

El gran premio es la transferencia del aprendizaje, que ocurre cuando algo que hemos aprendido nos ayuda a aprender algo nuevo más rápido. Las investigaciones distinguen entre transferencia cercana, que ocurre entre áreas similares o relacionadas como las fracciones y decimales en matemáticas, y transferencia lejana, que ocurre entre dominios diferentes—por ejemplo, la idea de que aprender ajedrez ayudará al razonamiento matemático y viceversa.

La transferencia cercana ocurre indudablemente—ningún tipo de aprendizaje más allá de la simple memorización podría ocurrir si no fuera así—y las/los docentes la utilizan todo el tiempo al dar a sus estudiantes ejercicios similares al material que acaba de ser presentado en la lección. Sin embargo, [Sala2017] analizó varios estudios sobre la transferencia lejana y concluye que:

…los resultados muestran un efecto pequeño a moderado. Sin embargo, el tamaño del efecto está inversamente relacionado a la calidad del diseño experimental.… Concluimos que la transferencia lejana raramente sucede.

Los casos en que la transferencia lejana sí sucede parecen ocurrir solamente cuando el tema ya ha sido dominado [Gick1987]. En la práctica, esto significa que aprender a programar no ayudará a jugar ajedrez y viceversa.

Seis estrategias

Las/los psicólogas/os estudian el aprendizaje en una amplia variedad de formas, pero han llegado a conclusiones similares sobre qué funciona realmente [Mark2018]. Las/Los Learning Scientists (Científicos/as del aprendizaje) han catalogado seis de estas estrategias y las resumieron en una serie de afiches para descargar¹². Si enseñas estas estrategias a tus estudiantes, y las mencionas por su nombre cuando las utilices en la clase, estarás ayudando a que aprendan cómo aprender más rápido y mejor [Wein2018a,Wein2018b].

Práctica distribuida

Diez horas de estudio repartidas en cinco días es más efectivo que dos días de estudio con cinco horas, y mucho mejor que un día de diez horas. Por lo tanto, deberías crear un cronograma de estudio en el que distribuyas tus actividades de estudio a lo largo del tiempo: reserva al menos media hora para estudiar cada tema, cada día, en vez de amontonar todo para la noche antes del examen [Kang2016].

También deberías revisar los materiales después de cada clase, pero no inmediatamente después—toma al menos media hora de receso. Cuando repases, asegúrate de incluir aunque sea un pequeño porcentaje del material anterior: por ejemplo, utiliza veinte minutos para revisar las notas de la clase de hoy y luego cinco minutos para revisar material de los días anteriores y de la semana pasada. Esto te ayudará a identificar algún vacío o errores en tus apuntes previos cuando todavía haya tiempo para corregirlos o hacer preguntas: es doloroso darse cuenta la noche del examen de que no tienes idea por qué subrayaste “¡¡Evaluación no estándar!!” tres veces.

Al repasar, haz notas sobre las cosas que te hayas olvidado: por ejemplo, haz una tarjeta de memoria para cada concepto que no pudiste recordar o que recordaste incorrectamente [Matt2019]. Esto te ayudará a enfocarte en aquello que necesite más atención cuando vuelvas a estudiar.

El valor de las clases magistrales

Según [Mill2016a], “Las clases magistrales que predominan en los cursos presenciales son formas relativamente ineficientes de enseñar, pero probablemente contribuyen a distribuir el material en los momentos correctos, porque se desenvuelven en un cronograma preestablecido. Por el contrario, dependiendo de cómo se organicen los cursos, las/los estudiantes en línea a veces pueden evitar exponerse al material por completo hasta que una tarea esté cerca.”

La práctica de recordar lo aprendido

El factor limitante de la memoria a largo plazo no es retener (qué se almacena) sino recordar (qué puede accederse). La habilidad de recordar una información específica puede entrenarse, asi que para mejorar los resultados en situaciones reales es útil hacer exámenes de práctica o resumir en detalle un tema de memoria y luego revisar qué has recordado y qué no. Por ejemplo, [Karp2008] encontró que hacer exámenes de forma repetida mejora el recuerdo de listas de palabras, de un 35% a un 80%.

La habilidad de recordar mejora cuando en la práctica se utilizan actividades similares a las que se evalúan. Por ejemplo, escribir entradas en un diario personal ayuda con las preguntas de opción múltiple, aunque menos que hacer exámenes de práctica [Mill2016a]. Este fenómeno se llama transferencia apropiada de procesamiento.

Una manera de ejercitar las habilidades para recordar es resolver un mismo problema dos veces. La primera vez, hacerlo completamente de memoria, sin notas o discusiones con pares. Después de evaluar tu propio trabajo con una rúbrica de respuestas distribuidas por la/el docente, resuelve el problema de nuevo, utilizando el material de apoyo que quieras. La diferencia entre ambos te muestra qué tan bien pudiste recordar y aplicar el conocimiento.

Otro método (mencionado previamente) es crear tarjetas de estudio. Las tarjetas físicas tienen una pregunta en un lado y la respuesta en el otro, y existen muchas aplicaciones para generarlas disponibles para teléfono móvil. Si estás estudiando en grupo, intercambiar las tarjetas de estudio con tus colegas te ayudará a descubrir ideas importantes que tal vez habías obviado o malinterpretado.

Leer-cubrir-recordar es una alternativa rápida a las tarjetas de estudio. Mientras lees algo, cubre los términos clave o secciones con notas adhesivas pequeñas. Cuando hayas terminado, vuelve a leer y ve qué tan bien puedes adivinar las palabras cubiertas por las notas adhesivas. Independientemente del método que uses, no sólo practiques recordar datos y definiciones: asegúrate de evaluar la comprensión de grandes ideas y de las conexiones entre ellas. Una forma rápida de hacer esto es diseñar un mapa conceptual y compararlo con tus apuntes o con un mapa conceptual dibujado previamente.

Hipercorrección

Un descubrimiento poderoso en la investigación del aprendizaje es el fenómeno de hipercorrección [Metc2016]. A la mayoría de las personas no le gusta que le digan cuando dicen algo incorrecto, así que sería razonable asumir que mientras más confianza tenga una persona en la respuesta que da en un examen, más difícil será cambiar su opinión si el resultado era incorrecto. Y resulta que lo opuesto es cierto: mientras más confianza tenga una persona en que tiene la razón, más probable será que no repita el error si recibe una corrección.

Práctica intercalada

Una forma de espaciar la práctica es intercalar el estudio de diferentes temas: en vez de dominar un tema, luego el segundo y el tercero, alterna las sesiones de estudio. Aún mejor, cambia el orden: A-B-C-B-A-C es mejor que A-B-C-A-B-C, que a la vez es mejor que A-A-B-B-C-C [Rohr2015]. Esto funciona porque intercalar permite la creación de más vínculos entre los diferentes temas, lo cual mejora el aprendizaje.

Cuánto deberías tardar en cada ítem depende del tema y de qué tan bien lo conozcas. Entre 10 y 30 minutos es un tiempo suficiente para entrar en tema (Sección 5.2) pero no para deambular. Al principio, intercalar el estudio parecerá más difícil que enfocarse en un único tema, pero ese es un signo de que está funcionando. Si usas tarjetas de estudio o haces exámenes de práctica para medir tu progreso, deberías ver una mejora después de un par de días.

Elaboración

Explicarte los temas a tí misma/o mientras estudias permite entenderlos y recordarlos. Una forma de hacer esto es complementar la respuesta en un examen práctico con la explicación de por qué la respuesta es correcta o, al contrario, con una explicación de por qué otras respuestas plausibles no serían correctas. Otra alternativa es decirte a tí misma/o cómo una nueva idea es similar o diferente a una que ya hayas visto previamente.

Si bien hablarte a tí misma/o puede parecer una forma extraña de estudiar,  [Biel1995] encontró que las personas entrenadas en auto-explicarse destacan cuando se comparan con quienes no se entrenaron. De manera similar, [Chi1989] encontró que algunas/os estudiantes simplemente frenan cuando se encuentran con un paso que no entienden al tratar de resolver problemas. Otras personas paran y generan una explicación de lo que está pasando: así aprenden más rápido. Un ejercicio para construir esta habilidad es revisar un ejemplo de programación línea por línea con una clase, de modo que diferentes personas expliquen cada línea y digan por qué está ahí y qué es lo que produce.

Ejemplos concretos

Una forma particularmente útil de la estrategia de aprendizaje de elaboración es el uso de ejemplos concretos. Cuando se tiene una definición de un principio general, intenta proveer uno o más ejemplos de su uso o, por el contrario, toma un problema en particular y enuncia los principios generales que representa. [Raws2014] encontró que intercalar ejemplos y definiciones de esta forma permite que las/los estudiantes puedan recordar las definiciones correctamente.

Una forma estructurada de hacer esto es con el método ADEPT: da una Analogía, dibuja un Diagrama, presenta un Ejemplo, describe la idea en un lenguaje Sencillo (del inglés "Plain Language"), y luego da los detalles Técnicos. De nuevo, si estás estudiando con otra persona o en grupo, puedes intercambiar y revisar el trabajo: ve si estás de acuerdo con el ejemplo que tus pares eligieron para representar el principio que se está discutiendo, o analiza qué principios se usan en un ejemplo que no hayan anotado.

Otra técnica útil es enseñar por contraste, p.ej. mostrar a tus estudiantes cuál no es la solución o cuál es la técnica que no resolverá un problema. Por ejemplo, al mostrar a las/los niñas/os cómo simplificar fracciones, es importante darles a menos un par de ejemplos que no puedan simplificarse, como 5/7, para que no se frustren buscando respuestas que no existen.

Codificación Dual

La última de las seis estrategias principales descriptas en Learning Scientists es presentar palabras e imágenes juntas. Como discutimos en la Sección 4.1, diferentes subsistemas en nuestro cerebro manejan y almacenan la información lingüística y visual, de tal manera que, si se presenta información complementaria por ambos canales, se refuerzan mutuamente. Sin embargo, aprender es menos efectivo cuando la misma información se presenta de forma simultánea por dos canales diferentes, porque el cerebro tiene que hacer un esfuerzo para comparar los canales entre sí [Maye2003].

Una forma de aprovechar la codificación dual es dibujar o etiquetar líneas de tiempo, mapas o árboles familiares, o cualquier otro material que sea relevante. (Personalmente, me gustan las imágenes que muestran qué funciones llaman a qué otras en un programa.) Dibujar un diagrama sin etiquetas, y después volver atrás para etiquetarlo, es una práctica excelente para recordar.

Gestión del tiempo

Solía presumir sobre la cantidad de horas que trabajaba. No en muchas palabras, obviamente—tenía algunas habilidades sociales—pero me presentaba en clases alrededor del mediodía, sin rasurar y bostezando, y casualmente mencionaba a quien sea que pudiera escuchar que había trabajado toda la noche.

Haciendo memoria, no puedo recordar a quién trataba de impresionar. Pero lo que sí recuerdo es que tuve que desechar gran parte del trabajo que hice durante esas trasnochadas una vez que lo revisé después de dormir un poco. Para peor, el trabajo que no descarté le hizo bastante daño a mis calificaciones.

Mi error fue confundir “trabajar” con “ser productivo.” No puedes producir software (o cualquier otra cosa) sin hacer algo de trabajo, pero se puede hacer mucho trabajo sin producir nada de valor. Convencer de esto a otras personas es difícil, especialmente cuando son adolescentes o tienen alrededor de veinte años, pero paga tremendos dividendos.

Los estudios científicos sobre el trabajo en exceso y la deprivación del sueño se remontan, al menos, a la década de 1890s—puedes ver [Robi2005] para un resumen breve y legible. Los resultados más importantes para estudiantes son:

1. Trabajar más de 8 horas al día por un periodo extendido de tiempo disminuye la productividad total, no sólo la productividad por hora —es decir, haces menos en total (no sólo por hora) cuando tienes trabajo acumulado y estás cerca de una fecha límite de entrega.

2. Trabajar durante 21 horas seguidas aumenta la posibilidad de que tengas un error catastrófico tanto como estar legalmente en estado de ebriedad.

3. La productividad varía a lo largo de la jornada laboral, con la mayor productividad en las primeras 4 a 6 horas. Después de cierta cantidad de horas, la productividad disminuye a cero; y eventualmente se vuelve negativa.

Estos hechos se han reproducido y verificado durante más de un siglo, y los datos detrás de ellos son tan sólidos como los que relacionan el tabaquismo con el cáncer de pulmón. El problema es que las personas generalmente no notan que sus habilidades disminuyen. Al igual que las personas que en estado de ebriedad creen que todavía pueden conducir, las personas que están deprivadas de sueño no se dan cuenta de que no están terminando sus oraciones (o pensamientos). Se ha demostrado que cinco días de 8 horas por semana maximizan la producción total a largo plazo en todas las industrias que se han analizado; estudiar o programar no es diferente.

Pero, ¿qué pasa con las rachas que surgen de vez en cuando, como trabajar toda la noche para cumplir con un plazo? Eso también se ha estudiado y los resultados no son agradables. La habilidad de pensar disminuye en un 25% por cada 24 horas sin dormir. Puesto de otra forma, el coeficiente intelectual de una persona promedio es sólo 75 después de una trasnochada, lo que la desplaza al 5% inferior de la población. Si haces dos trasnochadas seguidas, tu coeficiente intelectual es de 50, que es el nivel en el que las personas suelen ser consideradas incapaces de vivir de forma independiente.

“Pero—pero—, ¡tengo tantas tareas que hacer!” dices. “¡Y todas tienen que ser entregadas al mismo tiempo! ¡Tengo que trabajar horas extra para completarlas!” No: para ser productivas las personas tienen que priorizar tareas y enfocarse, lo cual se les debe enseñar. Una técnica ampliamente utilizada es hacer una lista de tareas a hacer, organizadas por prioridad, y luego desconectarse del correo electrónico u otras interrupciones por 30–60 minutos y completar una de esas tareas. Si una de las tareas de la lista lleva más de una hora, sepárala en actividades más pequeñas y priorízalas de forma separada.

La parte más importante de esto es apagar las interrupciones. A pesar de lo que mucha gente quiere creer, los seres humanos no somos buenos haciendo múltiples tareas a la vez.. En lo que sí podemos volvernos buenos es en la automaticidad, es decir, la habilidad de hacer algo de forma rutinaria de fondo, mientras realizamos otra tarea [Mill2016a]. La mayoría de las personas puede hablar mientras corta una cebolla, o tomar café mientras lee; con la práctica, también podemos tomar notas mientras escuchamos, pero no podemos estudiar de forma efectiva, programar o hacer otra tarea mentalmente exigente mientras prestamos atención a algo más—solo creemos que podemos.

El objetivo de organizarse y prepararse es entrar en el estado mental más productivo posible. Las/los psicólogas/os lo llaman flujo [Csik2008]; las/los atletas lo llaman “estar en la zona,” y las/los músicos hablan de perderse en lo que están tocando. Cualquiera sea el nombre que uses, las personas producen mucho más por unidad de tiempo en este estado que en un estado normal. La mala noticia es que se tarda aproximadamente 10 minutos en volver a entrar en este estado después de tener una interrupción, sin importar lo corta que haya sido la interrupción. Lo que significa que si te interrumpieron seis veces por hora, nunca llegaste al máximo de tu productividad.

¿Cómo lo supo?

En su breve historia en 1961 “Harrison Bergeron”, Kurt Vonnegut describió un futuro en el que las personas están obligadas a ser iguales. Las personas atractivas tienen que usar máscaras, las personas atléticas tienen que cargar pesas—y las personas inteligentes están obligadas a llevar radios que interrumpen sus pensamientos en intervalos aleatorios. A veces me pregunto si—oh, un momento, mi teléfono acaba de—perdón, ¿de qué estábamos hablando?

Evaluación de pares

Pedirle a las personas de un equipo que evalúen a sus pares es una práctica común en la industria. [Sond2012] revisaron la literatura sobre evaluación de pares, distinguiendo entre calificar y evaluar. Descubrieron que la evaluación de pares aumentaba la cantidad, la diversidad y la puntualidad de la retroalimentación, ayudaba a las/los estudiantes a ejercitar el pensamiento de nivel superior, fomentaba la práctica reflexiva, y promovía el desarrollo de habilidades sociales. Las preocupaciones fueron predecibles: validez y confiabilidad, motivación y procrastinación, agresión, confabulación y plagio.

Sin embargo, la evidencia muestra que estas preocupaciones no fueron significativas en la mayoría de las clases. Por ejemplo, [Kauf2000] comparó las evaluaciones y calificaciones confidenciales de pares en varios ejes para dos cursos en licenciatura en ingeniería, y descubrió que la auto-calificación y la evaluación de pares tuvo una concordancia estadística, que la confabulación no fue significativa (es decir, no dieron irrespectivamente la nota más alta a todos sus pares), que las/los estudiantes no inflaron sus auto-calificaciones y, lo más importante, que las calificaciones no estaban sesgadas por cuestiones de género ni por racismo.

Una forma de implementar la evaluación de pares es contribuyendo a la pedagogía estudiantil, en la cual tus estudiantes producen artefactos para contribuir al aprendizaje de otros. Esto puede hacerse desarrollando una lección corta y compartiéndola con la clase, contribuir a un banco de preguntas, o escribir notas de una lección en particular para una publicación durante la clase. Por ejemplo, [Fran2018] evidenció que las/los estudiantes que realizan videos cortos para enseñar conceptos a sus pares tuvieron un incremento significativo de su propio aprendizaje comparado al de aquellas personas que sólo estudiaron el material o vieron los videos. He observado que pedir a diario a mis estudiantes que compartan a la clase un error en su código y cómo lo solucionaron ayuda en sus habilidades analíticas y disminuye su síndrome del impostor/a.

Otra alternativa es la revisión por pares calibrada, en la cual tus estudiantes revisan uno o más ejemplos utilizando una rúbrica y comparan su evaluación con la evaluación del cuerpo docente [Kulk2013]. Una vez que la evaluación de tu estudiante sea similar a la del cuerpo docente, pueden empezar a evaluar el trabajo de sus pares. Si se combinan muchas evaluaciones de pares, este método puede ser tan preciso como la evaluación del cuerpo docente  [Pare2008].

Como todo lo demás, la evaluación es ayudada por rúbricas. La planilla de evaluación de la Sección 21.2 muestra un ejemplo para que puedas empezar. Para usarla, evalúate y luego evalúa a tus colegas, luego calcula y compara las notas. Una diferencia grande generalmente indica la necesidad de más conversación.

Ejercicios

Estrategias de aprendizaje (individual/20’)

1. ¿Cuál de las seis estrategias de aprendizaje generalmente usas? ¿Cuáles generalmente no usas?

2. Escribe tres conceptos generales que quieras que tus estudiantes aprendan y da dos ejemplos específicos para cada caso (practica ejemplos concretos). Para cada uno de estos conceptos, trabaja al revés: parte de uno de los ejemplos y elabora sobre el concepto que lo explica (elaboración).

Conectando ideas (parejas/5’)

Este ejercicio es un ejemplo de utilizar la elaboración para mejorar la retención. Tú y tu pareja deben elegir una idea de manera independiente. Luego de contarse sus ideas, trata de encontrar una cadena de cuatro eslabones que las conecte.

Por ejemplo, si las dos ideas son “Titicaca” y “estadística,” los eslabones pueden ser:

• El lago Titicaca se encuentra en territorios de Bolivia y Perú;

• Bolivia y Perú son países;

• los países tienen gobiernos;

• los gobiernos utilizan estadísticas para analizar la opinión pública.

Evolución convergente (parejas/15’)

Una práctica que no hemos abordado anteriormente son las notas guiadas. Se trata de notas preparadas por la/el docente, quien solicita a sus estudiantes que respondan preguntas respecto a la información clave de una clase magistral o discusión. Estas preguntas pueden ser espacios en blancos donde tus estudiantes agregan información, asteriscos junto a términos que deben definir, etcétera.

Crea entre dos y cuatro tarjetas con notas guiadas para una lección que hayas enseñado recientemente o que vas a enseñar. Intercambia tarjetas con tu colega: ¿Qué tan fácil es entender lo que se está preguntando? ¿Cuánto tiempo te lleva completar las respuestas? ¿Qué tan bien funciona esto para ejemplos de programación?

Cambiando de opinión (parejas/10’)

[Kirs2013] argumentan que los mitos sobre personas nativas digitales, estilos de aprendizaje, y personas autodidactas se derivan de una misma creencia equivocada: que las/los estudiantes saben lo que es mejor para ellas/os. Los autores advierten que podemos estar en una espiral descendente en la que todos los intentos de las personas que investigan en educación para refutar estos mitos, confirmen la creencia de sus oponentes de que la ciencia de aprendizaje es pseudociencia. Elige algo que hayas aprendido hasta ahora en este libro, que te haya sorprendido o haya contradecido algo que creías previamente, y practica explicar esa idea a tu colega en 1–2 minutos. ¿Cuán convincente eres?

Tarjetas de estudio (individual/15’)

Utiliza notas adhesivas, o algo similar que tengas a mano, para hacer seis tarjetas de estudio para un tema que recientemente hayas enseñado o aprendido. Intercambia con tu colega y ve cuánto tiempo tardas en recordar al 100% cada tarjeta. Deja las tarjetas a un lado cuando termines y vuelve media hora después para evaluar cuál es tu tasa de retención.

Utilizando ADEPT (toda la clase/15’)

Elige un tema que recién hayas enseñado o aprendido, y delinea una pequeña lección que utilice los cinco pasos del método ADEPT para introducir el tema.

El costo de la multitarea (parejas/10’)

El blog de The Learning Scientists describe un experimento simple que puedes hacer con solo un cronómetro para demostrar el costo de hacer múltiples tareas a la vez. En parejas, mide cuánto tarda cada persona en hacer cada una de estas tres tareas:

• Contar del 1 al 26 dos veces.

• Recitar el alfabeto de la A a la Z dos veces.

• Intercalar números y letras, es decir, “1, A, 2, B, …” y continuar.

Luego, cada pareja informa sus tiempos a la clase. Sin práctica específica, intercalar números y letras siempre toma significativamente más tiempo que cada uno de los componentes por separado.

Mitos en la educación de computación (toda la clase/20’)

[Guzd2015b] presenta una lista de las 10 creencias erróneas más comunes sobre educación en computación, que incluye:

1. La ausencia de mujeres en ciencias de la computación es similar a lo que ocurre en otras áreas de ciencias, tecnología, ingeniería y matemáticas.

2. Para tener más mujeres en las ciencias de la computación necesitamos más docentes mujeres en el área.

3. Las evaluaciones de estudiantes son la mejor forma de evaluar la enseñanza.

4. Las/los buenas/os docentes personalizan la educación a los estilos de aprendizaje de sus estudiantes.

5. Las/los buenas/os docentes en ciencias de la computación deberían modelar buenas prácticas de desarrollo de software porque su trabajo es producir ingenieras/os de software excelentes.

6. Algunas personas son naturalmente mejores programadoras que otras.

Cada persona de la clase es invitada a votar +1 (de acuerdo), -1 (en desacuerdo) o 0 (neutro) para cada punto. Luego, la/el docente lee la explicación completa en el artículo original y se vuelve a hacer la votación. ¿En cuáles preguntas las personas cambiaron de parecer? ¿Cuáles todavía creen que son verdad, y por qué?

Revisión por pares calibrada (parejas/20’)

1. Crea una rúbrica de 5–10 puntos con entradas como “buenos nombres de variables,” “sin código redundante,” y “flujo de control propiamente anidado” para calificar el tipo de programa que esperarías que tus estudiantes escriban.

2. Elige o crea un pequeño programa que contenga 3–4 violaciones a estas entradas.

3. Califica el programa de acuerdo a la rúbrica.

4. Pide a tu colega que califique el mismo programa con la misma rúbrica. ¿Qué aceptó tu colega pero tú no aceptaste? ¿Qué criticó tu colega pero tú no criticaste?

Revisión

Un proceso para diseñar lecciones

La mayoría de las personas diseñan lecciones de esta manera:

1. Alguien te pide que enseñes algo que sabes muy poco o que no has pensado en años.

2. Empiezas escribiendo diapositivas para explicar lo que sabes sobre el tema.

3. Después de dos o tres semanas, preparas una tarea basada en lo que has enseñado hasta ahora.

4. Repites el tercer paso varias veces.

5. Permaneces sin dormir hasta altas horas de la mañana para crear un examen final y te prometes que la próxima vez serás más organizado/a.

Un método más efectivo es similar en esencia a una práctica de programación llamada desarrollo impulsado por pruebas (Test Driver Development (TDD) en inglés). Los/las programadores/as que usan desarrollo impulsado por pruebas no escriben software y luego prueban que funcione correctamente. En su lugar, escriben la prueba primero, luego escriben suficiente software nuevo para que esas pruebas pasen.

Este método de programación funciona porque escribir pruebas obliga a tener más precisión acerca de lo que están intentando lograr y cómo se ve “finalizado”. El desarrollo impulsado por pruebas también evita el pulido sin fin: cuando pasan las pruebas, dejas de programar. Finalmente, esto reduce el riesgo de sesgo de confirmación: una persona que aún no ha escrito un fragmento de software será más objetiva que alguien que acaba de dedicar varias horas al trabajo duro y realmente quiere terminar.

Un método similar denominado reingeniería funciona muy bien para el diseño de lecciones. Este método fue desarrollado en forma independiente en  [Wigg2005,Bigg2011,Fink2013] y está resumido en [McTi2013]. En forma simplificada, sus pasos son:

1. Crea o recicla personas tipo (concepto discutido en la siguiente sección) para imaginar a quiénes estás intentando ayudar y qué les atraerá.

2. Haz una tormenta de ideas para tener una idea aproximada de lo que quieres cubrir, cómo lo vas a hacer, qué problemas o conceptos erróneos esperas encontrar, qué no no se va a incluir, etcétera. Dibujar mapas conceptuales puede ayudar mucho en esta etapa (Sección 3.1).

3. Crea una evaluación sumativa (Sección 2.1) para definir tu objetivo general. Dicha evaluación puede ser el examen final para un curso o el proyecto final para un taller de un día. Independientemente de su forma o extensión, la evaluación sumativa te mostrará lo lejos que esperas llegar más claramente que una lista puntual de objetivos.

4. Crea evaluaciones formativas, lo cual le dará a tus estudiantes una oportunidad para practicar lo que están aprendiendo. Las evaluaciones formativas también te dirán a ti (y a tus estudiantes) si están progresando y dónde deben centrar su atención. El mejor camino para hacer esto es listar los conocimientos y las habilidades involucradas en la evaluación sumativa que desarrollaste en el paso anterior: luego, deberás crear una evaluación formativa para cada ítem.

5. Ordena las evaluaciones formativas para crear un esquema del curso en función de su complejidad, sus dependencias, y cuán bien los temas motivarán a tus estudiantes (Sección 10.1).

6. Escribe material para conseguir que tus estudiantes pasen de una evaluación formativa a la siguiente. Cada hora de instrucción debe constar de tres a cinco de estos episodios.

7. Escribe una descripción resumida del curso para ayudar a que tu público objetivo lo encuentre y averigue si es el curso adecuado.

Este método ayuda a mantener la enseñanza enfocada en sus objetivos. También asegura que tus estudiantes no se enfrenten al final del curso a nada para lo que no tengan preparación.

Incentivos perversos

La reingeniería no es lo mismo que enseñar para el examen. Cuando se usa reingeniería, los/las docentes establecen objetivos para ayudar en el diseño de sus lecciones: es posible que nunca den el examen final que preparan durante este proceso. En muchos sistemas escolares, por otro lado, una autoridad externa define los criterios de evaluación para todos/as los/las estudiantes, independientemente de sus situaciones individuales. Los resultados de esas evaluaciones sumativas afectan directamente los salarios y las promociones de los/las docentes, lo que significa que el plantel docente tiene un incentivo para que sus estudiantes pasen las pruebas, y no en ayudarles a aprender.

[Gree2014] argumenta que, si bien enfocarse en las evaluaciones y la medición es atractivo para quienes tienen el poder de establecer las pruebas, es poco probable mejorar así los resultados del curso —salvo que las evaluaciones se acompañen con apoyo para que los/las docentes realicen mejoras basadas en los resultados de las pruebas. Sin embargo, este tipo de apoyo no suele ocurrir ya que las grandes organizaciones usualmente valoran la uniformidad por sobre la productividad  [Scot1998].

El diseño inverso (o diseño en retrospectiva) se describe como una secuencia, pero casi nunca se hace de esa manera. Podemos, por ejemplo, cambiar nuestra opinión acerca de lo que queremos enseñar en base a algo que se nos ocurre mientras estamos escribiendo preguntas de opción múltiple, o re-evaluar a quién estamos intentando ayudar una vez que tengamos un esqueleto de la lección. Sin embargo, las notas que elaboremos deben presentar las tareas desarrolladas en el orden descripto anteriormente, para que quien tenga que usar o mantener la lección pueda seguir nuestros razonamientos  [Parn1986].

Personas tipo

El primer paso en el proceso de diseño inverso es averiguar quién es tu público. Una manera para hacer esto es escribir dos o tres personas tipo como los de la Sección 1.1. Esta técnica es tomada de diseñadores/as de experiencia de usuario/a, quienes crean perfiles breves de usuarios/as típicos/as para ayudarse a pensar en su público. Una persona tipo consiste en:

1. antecedentes generales de la persona;

2. lo que ya sabe;

3. lo que quiere hacer; y

4. cualquier necesidad especial que tenga.

Las personas en la Sección 1.1 tienen los cuatro puntos listados anteriormente, junto con un breve resumen de cómo este libro las ayudará. Una persona tipo para un grupo de voluntarios/as que realiza talleres de Python los fines de semana sería:

1. Jorge se acaba de mudar de Costa Rica a Canadá para estudiar ingeniería agrícola. Se ha unido al equipo de fútbol de la universidad y espera aprender a jugar hockey sobre hielo.

2. Aparte de usar Excel, Word e internet, la experiencia previa más significativa de Jorge con computadoras es ayudar a su hermana a construir un sitio en WordPress para su negocio familiar.

3. Jorge quiere medir las propiedades del suelo en granjas cercanas usando un dispositivo de mano que envía datos a su computadora. Por el momento, Jorge tiene que abrir cada archivo de datos en Excel, eliminar la primera y la última columna y calcular algunas estadísticas de los datos restantes. Recopilará al menos 600 mediciones en los próximos meses y realmente no quiere tener que hacer estos pasos a mano mes a mes.

4. Jorge puede leer en inglés, pero a veces le cuesta sostener una conversación hablada que involucre mucha jerga.

En lugar de escribir nuevas personas tipo para cada lección o curso, los/las docentes usualmente crean y comparten una media docena de personas tipo, que cubren a todas las personas a las que probablemente enseñan. Luego, eligen a algunas de esas personas tipo para describir al público de un material en particular. Las personas tipo utilizadas de esta manera se convierten en un atajo conveniente para los problemas de diseño: al hablar entre docentes, se pueden pensar en términos del estilo “¿Jorge entendería por qué estamos haciendo esto?” o “¿Qué problemas de instalación enfrentaría Jorge?”

Sus metas, no las tuyas

Las personas tipo deberían siempre describir lo que cada estudiante quiere hacer en lugar de lo que tú crees que necesitan. Pregúntate lo que tus estudiantes están buscando en línea; probablemente no incluirá jerga que no conocen aún, así que parte de lo que tienes que hacer al diseñar lecciones es descubrir cómo hacer que tu curso sea visible y pueda ser encontrado por tu público.

Objetivos de aprendizaje

Las evaluaciones formativas y sumativas ayudan a los/las docentes a descubrir qué van a enseñar, pero comunicarle eso a sus estudiantes y a otro conjunto de docentes implica tener también una descripción del curso. Los objetivos de aprendizaje ayudan a asegurar que todos/as tus estudiantes tengan el mismo entendimiento de lo que se supone que una lección debe lograr. Por ejemplo, el enunciado “Entender Git” podría significar cualquiera de los siguientes ítems:

• Los/las estudiantes pueden describir tres cuestiones en las cuales los sistemas de versión de control como Git son mejores que herramientas para compartir archivos como Dropbox y dos cuestiones en que son peores.

• Los/las estudiantes pueden hacer commit a un archivo modificado en un repositorio de Git usando un software con interfaz gráfica instalado en su computadora.

• Los/las estudiantes pueden explicar qué es un HEAD por separado y recuperarlo usando operaciones de línea de comandos.

Objetivos versus resultados

Un objetivo de aprendizaje es lo que una lección se esmera por lograr. Un resultado de aprendizaje es lo que realmente se logra, es decir, lo que tus estudiantes realmente se llevan. El rol de la evaluación sumativa es, por lo tanto, comparar resultados de aprendizajes con objetivos de aprendizajes.

Un objetivo de aprendizaje describe cómo tu estudiante demostrará lo que ha aprendido una vez que ha completado exitosamente una lección. Más específicamente, un objetivo tiene un verbo medible o verificable que establece lo que cada estudiante hará y especifica los criterios aceptables de rendimiento. Escribir estos objetivos puede inicialmente parecer restrictivo, pero a largo plazo te hará más feliz a ti, a tus colegas docentes y a tus estudiantes: terminarás con guías claras tanto para la enseñanza como para la evaluación, y tus estudiantes apreciarán tener expectativas claras.

Una forma de comprender lo que constituye un buen objetivo de aprendizaje es ver cómo se puede mejorar uno pobre:

• El/la estudiante tendrá oportunidad para aprender buenas prácticas de programación.
  Este enunciado describe el contenido de la lección, no los atributos de éxito de tus estudiantes.
  

• El/la estudiante tendrá una mejor apreciación de las buenas prácticas de programación.
  Este enunciado no empieza con un verbo activo ni define el nivel de aprendizaje. El tema de aprendizaje no tiene contexto y no es específico.
  

• El/la estudiante comprenderá cómo programar en R.
  Si bien aquí se comienza con un verbo activo, no se define el nivel de aprendizaje, y el tema de aprendizaje es todavía demasiado vago para una evaluación.
  

• El/la estudiante escribirá scripts de análisis de datos para leer, filtrar y resumir datos tabulares usando R.
  Este objetivo comienza con un verbo activo, define el nivel de aprendizaje y provee contexto para asegurar que los resultados puedan evaluarse.

Cuando se trata de elegir verbos, la mayoría de los/las docentes usan la taxonomía de Bloom. Publicada por primera vez en 1956 y actualizada a principios de siglo  [Ande2001], es un marco ampliamente usado para discutir los niveles de comprensión. Su forma más reciente tiene seis categorías; la lista a continuación da algunos de los verbos típicamente usados en los objetivos de aprendizaje escritos para cada uno:

Recordar:

Exhibir memoria del material previamente aprendido recordando hechos, términos, conceptos básicos y respuestas. (reconocer, listar, describir, nombrar, encontrar.)

Comprender:

Demostrar comprensión de los hechos e ideas organizando, comparando, traduciendo, interpretando, dando descripciones y estableciendo ideas principales. (interpretar, resumir, parafrasear, clasificar, explicar)

Aplicar:

Resolver problemas nuevos aplicando de forma diferente los conocimientos, hechos, técnicas y reglas adquiridos. (construir, identificar, usar, planificar, seleccionar)

Analizar:

Examinar y dividir la información en partes identificando motivos o causas, hacer inferencias y encontrar evidencia para apoyar generalizaciones. (comparar, contrastar, simplificar)

Evaluar:

Presentar y defender opiniones emitiendo juicios sobre información, validez de las ideas o calidad del trabajo, en base a un conjunto de criterios. (comprobar, elegir, criticar, probar, calificar)

Crear:

Recopilar información de forma diferente combinando elementos en un nuevo patrón o proponiendo soluciones alternativas. (diseñar, construir, mejorar, adaptar, maximizar, resolver)

La taxonomía de Bloom aparece en casi todos los libros de texto sobre educación, pero  [Masa2018] encontró que incluso los/las educadores/as con mucha experiencia tienen problemas para ponerse de acuerdo en cómo clasificar cuestiones específicas. Sin embargo, los verbos siguen siendo útiles, al igual que la noción de desarrollar la comprensión por pasos: como ha dicho Daniel Willingham, la gente no puede pensar si no tiene algo en qué pensar  [Will2010], y esta taxonomía puede ayudar a los/las docentes a asegurarse que sus estudiantes tienen esas cosas en qué pensar cuando las necesiten.

Otra manera de conceptualizar los objetivos de aprendizaje proviene de  [Fink2013], el cual define aprendizaje en términos del cambio que se supone que debe producirse en el/la estudiante. La taxonomía de Fink también tiene seis categorías, pero a diferencia de las de Bloom ellas son complementarias y no jerárquicas:

Conocimiento fundamental:

comprender y recordar información e ideas. (recordar, comprender, identificar)

Aplicación:

habilidades, pensamiento crítico, gestión de proyectos. (usar, resolver, calcular, crear)

Integración:

conectar ideas, experiencias de aprendizaje y vida real. (conectar, relatar, comparar)

Dimensión humana:

aprender sobre sí mismo/a y sobre otras personas. (llegar a verse a sí mismo/a, entender a las demás personas en términos de, decidir transformarse en)

Cuidado:

desarrollar nuevos sentimientos, intereses y valores. (emocionarse, estar preparado/a para, valorar)

Aprendiendo a aprender:

convertirse en mejor estudiante. (identificar la fuente de información para, enmarcar preguntas útiles sobre)

Un conjunto de objetivos de aprendizaje basados en la taxonomía de Fink para un curso introductorio sobre HTML y CSS sería:

• Explicar qué son las propiedades de CSS y cómo funcionan los selectores de CSS.

• Diseñar una página web usando etiquetas comunes y propiedades de CSS.

• Comparar y contrastar escribir en HTML y CSS con escribir con herramientas de escritorio de edición y publicación.

• Identificar y corregir problemas en páginas web de muestra que dificultarían la interacción de las personas con discapacidad visual.

• Describir las características de los sitios web favoritos cuyo diseño te atraiga de forma particular y explicar el por qué.

• Describir tus dos fuentes de información en línea favoritas sobre CSS y explicar qué te gusta de ellas.

Mantenimiento

Una vez que una lección ha sido creada alguien debe mantenerla y hacerlo es mucho más fácil si se ha construido de manera que se pueda mantener. Pero, ¿qué significa exactamente “mantenible´´? La respuesta corta es que una lección es mantenible si es más barato actualizarla que reemplazarla. Esta ecuación depende de cuatro factores:

Qué tan bien documentado está el diseño del curso

Si la persona que realiza el mantenimiento no conoce (o no recuerda) lo que se supone que la lección debe lograr o por qué los temas son presentados en un orden en particular, le llevará más tiempo actualizarla. Una razón para usar el diseño inverso es captar decisiones sobre por qué cada curso es como es.

Qué tan fácil es para los/las colaboradores ayudar

Los/las docentes suelen compartir material enviándose por correo archivos de PowerPoint o dejándolos en una unidad compartida. Herramientas de escritura colaborativa como Google Docs y wikis son una gran mejora, ya que permiten que muchas personas actualicen el mismo documento y comenten las actualizaciones de otras personas. Los sistemas de control de versiones usados por programadores/as, tales como GitHub, son otro enfoque. Permiten que cualquier número de personas trabaje de forma independiente, para luego unir sus cambios en forma controlada y revisable. Desafortunadamente, los sistemas de control de versión tienen una curva de aprendizaje pronunciada y no manejan formatos de documentos de oficina comunes.

Qué tan dispuestas están las personas a colaborar.

Las herramientas necesarias para construir una Wikipedia para lecciones existen hacen veinte años, pero la mayoría de los/las docentes no escriben ni comparten sus lecciones de la misma manera en que escriben y comparten las entradas de enciclopedias.

Qué tan útil es compartir en realidad.

La paradoja de la reusabilidad establece que cuanto más reutilizable es un objeto de aprendizaje, menos efectivo pedagógicamente es  [Wile2002]. La razón es que una buena lección se parece más a una novela que a un programa: sus partes están estrechamente acopladas en lugar de ser cajas negras independientes. Por lo tanto, la reutilización directa de las lecciones puede ser un objetivo equivocado; podríamos llegar más lejos tratando de hacerlas más fáciles de combinar.

Si la paradoja de la reusabilidad es cierta, la colaboración será más probable si las cosas en las que se colabora son pequeñas. Esto se ajusta a la teoría de Mike Caulfield de las explicaciones corales, que sostiene que sitios como Stack Overflow tienen éxito porque proporcionan un coro de respuestas para cada pregunta, cada una de las cuales es más adecuada para una persona que pregunta y que es ligeramente diferente a las demás personas que preguntan. Si esto es correcto, las lecciones del futuro pueden ser visitas guiadas de repositorios de preguntas y respuestas seleccionados por la comunidad, diseñados para estudiantes en niveles muy diferentes.

Ejercicios

Crear personas tipo (grupos pequeños/30’)

Trabajando en grupos pequeños, crea una persona tipo descripta con cuatro puntos que reseñe a un/a de tus estudiantes típicos.

Clasificar objetivos de aprendizaje (parejas/10’)

Mira el ejemplo de los objetivos de aprendizaje para un curso introductorio sobre HTML y CSS en la Sección 6.2 y clasifica cada uno de acuerdo a la taxonomía de Bloom. Compara tus respuestas con las de tu pareja. ¿En qué estuvieron de acuerdo y en qué en desacuerdo?

Escribir objetivos de aprendizaje (parejas/20’)

Escribe uno o más objetivos de aprendizaje para un tema que actualmente enseñes o planees enseñar utilizando la taxonomía de Bloom. Con tu pareja, critica y mejora los objetivos. ¿Cada objetivo tiene un verbo verificable y establece claramente los criterios para evaluar el desempeño aceptable?

Escribir más objetivos de aprendizaje (parejas/20’)

Escribe uno o más objetivos de aprendizaje para algo que actualmente enseñes o planees enseñar utilizando la taxonomía de Fink. Con tu pareja, critica y mejora los objetivos.

Ayúdame a hacerlo por mi cuenta (grupos pequeños/15’)

El teórico de la educación Lev Vygotsky introdujo la noción de una zona de desarrollo próximo, la cual incluye los problemas que las personas no pueden resolver aún por sí mismas pero que son capaces de resolver con la ayuda de un mentor/a. Se trata de problemas que resulta fructífero abordar a corto plazo, ya que aún están fuera del alcance de tu estudiante pero son alcanzables.

Trabajando en grupos pequeños, escoge una persona tipo que hayas desarrollado y describe dos o tres problemas que se encuentran en su zona de desarrollo próximo.

Restar complejidad al construir lecciones (individual/20’)

Una forma para construir una lección de programación es escribir el programa que deseas que tus estudiantes terminen, luego eliminar la parte más compleja que deseas que escriban y convertirla en el último ejercicio. A continuación puedes eliminar la siguiente parte más compleja que deseas que escriban y convertirla en el penúltimo ejercicio, etcétera. Todo lo que quede después de haber retirado los ejercicios, como cargar librerias o leer datos, se convierte en el código que les das al inicio. Elige un programa o página web que desees que tus estudiantes puedan crear y trabaja hacia atrás para dividirlo en fragmentos que se asimilen. ¿Cuántos fragmentos hay? ¿Qué idea clave introduce cada uno?

Rareza no esencial (individual/15’)

Betsy Leondar-Wright acuñó la frase “rareza no esencial” para describir cosas que hacen los grupos que no son realmente necesarias y que alienan a personas que aún no son integrantes de ese grupo. Sumana Harihareswara luego usó esta noción como base para una charla sobre rarezas no esenciales en el software de código abierto, lo que incluye, por ejemplo, el uso de herramientas de línea de comandos con nombres crípticos. Toma unos minutos para leer estos artículos, luego haz una lista de las rarezas no esenciales que crees que tus estudiantes podrían encontrar cuando les enseñes por primera vez ¿Cuántas de estas rarezas no esenciales puedes evitar?

Un patrón: problema, ejemplo, teoría y elaboración (individual/15’)

Un patrón que trabaja bien para lecciones de programación es: presentar un problema, trabajar a través de un ejemplo, explicar la teoría, y luego elaborar un segundo ejemplo para que los/las estudiantes puedan ver qué es específico en cada caso y qué se aplica a todos los casos. (En inglés se lo conoce por su sigla PETE: Problem, Example, Theory, Elaborate.) Elige algo que ya hayas enseñado o les hayan enseñado y delinea una pequeña lección que siga estos cuatro pasos.

Otro patrón: predecir, ejecutar, investigar, modificar y crear (individual/15’)

Otro patrón de lección es  [Sent2019]: predecir el comportamiento o salida de un programa, ejecutar el programa para ver lo que realmente hace, investigar por qué lo hace, pasando a través del mismo en un depurador o dibujando el flujo de control, modificar el programa (o sus entradas), y luego crear algo similar desde cero. (En inglés se lo conoce por su sigla PRIMM: Predict, Run, Investigate, Modify, Make.) Elige algo que hayas enseñado o te hayan enseñado recientemente y bosqueja una breve lección que siga estos cinco pasos.

Concreto-representativo-abstracto (parejas/15’)

Concreto-representativo-abstracto (abreviado CRA) es un enfoque para introducir nuevas ideas usado principalmente con estudiantes más jóvenes: manipular físicamente un objeto concreto, representar el objeto con una imagen, luego realizar las mismas operaciones usando números, símbolos o algo abstracto.

1. Escribe cada uno de los números 2, 7, 5, 10, 6 en una nota adhesiva diferente.

2. Simula un bucle que encuentre el valor más grande buscando cada uno por turno (concreto).

3. Dibuja un diagrama del proceso que usaste etiquetando cada paso (representativo).

4. Escribe instrucciones que alguien más podría seguir por medio de los pasos (abstracto).

Compara tus materiales representativos y abstractos con los de tu colega.

Evaluación de un repositorio de lecciones (grupos pequeños/10’)

[Leak2017] explora por qué los/las docentes de ciencias de la computación no utilizan sitios para compartir lecciones y recomienda formas para hacerlas más atractivas:

1. La página de destino debe permitir a quienes visitan el sitio identificar sus antecedentes y sus intereses. Los sitios deben hacer dos preguntas: “¿Cuál es tu rol actual? ” y “¿En qué curso y nivel tienes interés? ”

2. Los sitios deben mostrar los recursos de aprendizaje en el marco de un curso completo para que los/las usuarios/as potenciales puedan comprender el contexto en que se prevé usar el material.

3. A muchos/as docentes les preocupa que sus pares juzguen su (falta de) conocimiento si publican en foros de discusión en línea. Por tanto, estos foros deberían permitir publicaciones anónimas.

En grupos pequeños, discute si estas tres características serían suficientes para convencerte de usar un sitio para compartir lecciones. Si no fueran suficientes, ¿qué te convencería?

Revisión

Conocimiento de la pedagogía del contenido

Cada docente necesita tres cosas:

conocimiento del contenido,

por ejemplo, como programar;

conocimiento pedagógico general,

por ejemplo, comprensión de la psicología del aprendizaje; y

conocimiento de la pedagogía del contenido,

que es el conocimiento específico acerca de cómo enseñar un concepto particular a un público en particular. En informática, el conocimiento de la pedagogía del contenido incluye qué ejemplos usar cuando se enseña, cómo se incluyen parámetros en una función o qué conceptos erróneos sobre etiquetas HTML anidadas son los más comunes.

Podemos agregar conocimiento técnico a este conjunto [Koeh2013], pero eso no cambia el punto clave: no es suficiente saber sobre el tema y cómo enseñar—tienes que saber cómo enseñar ese tema en particular [Maye2004]. Este capítulo resume algunos resultados de investigaciones sobre enseñanza de informática para añadir a tu colección sobre el conocimiento de la pedagogía del contenido.

Como con toda investigación, se requiere cierta precaución al interpretar los resultados:

Las teorías cambian a medida que se obtienen más datos.

La investigación sobre educación en informática es una disciplina nueva: la Sociedad Americana de Educación en Ingeniería fue fundada en 1893 y el Consejo Nacional de Docentes de Matemática en 1920, pero la Asociación de Docentes de Informática no se creó hasta 2005. Mientras que existe un flujo constante de nuevo conocimiento en conferencias como SIGCSE, ITiCSE e ICER, simplemente no sabemos tanto sobre cómo aprender a programar como sí sabemos sobre aprender a leer, jugar un deporte o resolver cálculos simples.

La mayoría de las personas en estos estudios viven en sociedades occidentales, democráticas, industrializadas y con alto nivel de riqueza y educación

y se los denomina WEIRD por Western, Education, Industrialized, Rich, and Democratic (en inglés), tal como señala  [Henr2010]. Además, son principalmente jóvenes que estudian en instituciones educativas, ya que es la población a la que la mayoría de las personas que investigan tienen fácil acceso. Sabemos mucho menos sobre adultos, grupos marginados y estudiantes en ambientes educativos flexibles (estudiantes free-range), así como sobre usuarias/os finales programadoras/es, aún cuando son la mayoría.

Si esto fuera un ensayo académico, empezaría la mayoría de oraciones con frases como, “Algunas investigaciones parece indicar que…” Pero dado que las/los docentes reales que enseñan en aulas reales tienen que tomar decisiones independientemente de si las investigaciones tienen respuestas claras o no, este capítulo presenta las mejores conjeturas prácticas en lugar de sutiles posibilidades.

Jerga

Como cualquier especialidad, la investigación sobre educación en informática tiene jerga. CS1 refiere a un curso introductorio de un semestre de duración, donde las/los estudiantes aprenden variables, bucles y funciones por primera vez, mientras que CS2 refiere a un segundo curso que cubre las estructuras de datos básicas como pilas y colas, y CS0 se refiere a un curso introductorio para personas sin experiencia previa y que no tienen intención de continuar con computación de inmediato. Las definiciones completas de estos términos se encuentran en los lineamientos del programa ACM (Association for Computing Machinery, por sus siglas en inglés).

¿Qué les estamos enseñando ahora?

Se sabe muy poco sobre qué se enseña en entrenamientos de programación intensivo e iniciativas free-range, en parte porque muchas personas son reticentes a compartir los programas. Sabemos más sobre lo que se enseña en instituciones [Luxt2017]:

Temas	%	Temas	%
Proceso de programación	87%	Tipos de datos	23%
Pensamiento abstracto para programación	63%	Entrada/Salida	17%
Estructuras de datos	40%	Librerías	15%
Conceptos orientados a objetos	36%	Variables y asignación	14%
Estructuras de control	33%	Recursión	10%
Operaciones y funciones	26%	Punteros y administración de memoria	5%

Títulos de temas de alto nivel como estos pueden esconder una gran cantidad de fallas. Un resultado más tangible surge de [Rich2017], quienes revisaron cien artículos y encontraron trayectorias de aprendizaje para clases de computación en escuelas primarias y secundarias. Sus resultados para la secuenciación, la repetición y los condicionales son esencialmente mapas conceptuales colectivos que combinan y racionalizan el pensamiento implícito y explícito de gran cantidad de docentes (Figura 7.1).

¿Cuánto están aprendiendo?

Puede haber un mundo de distancia entre lo que enseñan las/los docentes y cuánto aprenden sus estudiantes. Para explorar cuánto se aprende, debemos usar otras medidas o hacer estudios directos. Tomando el enfoque tradicional, aproximadamente dos tercios de las/los estudiantes de nivel superior aprueban su primer curso de informática, con algunas variaciones dependiendo del tamaño de la clase, pero sin diferencias significativas a lo largo del tiempo o basadas en el lenguaje [Benn2007a,Wats2014].

¿Cómo afecta la experiencia previa a estos resultados? Para responder esto, [Wilc2018] compararon el desempeño y la confianza de personas novatas con y sin experiencia previa en programación en CS1 y CS2 (ver más abajo). Encontraron que personas novatas con experiencia previa superaron a personas sin experiencia en un 10% en CS1, pero esas diferencias desaparecieron hacia el final de CS2. También encontraron que las mujeres con experiencia previa superaron a sus pares masculinos en todas las áreas, pero siempre tenían menos confianza en sus habilidades (Sección 10.4).

En cuanto a estudios sobre cuánto aprenden las personas novatas, [McCr2001] presentaron un estudio internacional en múltiples espacios que luego fue replicado por [Utti2013]. De acuerdo al primer estudio, “…los decepcionantes resultados sugieren que muchas/os estudiantes no saben cómo programar al final de los cursos introductorios”. Más específicamente, “Para una muestra combinada de 216 estudiantes de cuatro universidades, la puntuación media fue de 22,89 sobre 110 puntos en los criterios generales de evaluación desarrollados para este estudio.” Este resultado puede hablar tanto de las expectativas de docentes como de la habilidad de las/los estudiantes, pero de cualquier manera, nuestra primera recomendación es mide y haz un seguimiento de los resultados de tal manera que se puedan comparar a través del tiempo para que puedas saber si tus lecciones se están volviendo más o menos efectivas.

¿Qué conceptos erróneos tienen las personas novatas?

El Capítulo 2 explicó por qué aclarar los conceptos erróneos a las personas novatas es tan importante como enseñarles estrategias para resolver problemas. La mayor confusión de las personas novatas —a veces llamada el “superbug” o “supererror” en programación —es la creencia de que las computadoras entienden lo que las personas quieren decir de la misma manera que cualquier ser humano lo haría [Pea1986]. Nuestra segunda recomendación es entonces enseña a las personas novatas que las computadoras no entienden los programas, es decir, que llamar a una variable “precio” no garantiza que su valor sea realmente un precio.

[Sorv2018] muestra más de cuarenta conceptos erróneos que las/los docentes también pueden intentar aclarar, muchos de los cuales también se discuten en el estudio de [Qian2017]. Uno es la creencia de que las variables en los programas funcionan de la misma manera que en planillas de cálculo, es decir, que luego de ejecutar:

nota = 65
total = nota + 10
nota = 80
print(total)

el valor de total será 90 en vez de 75 [Kohn2017]. Este es un ejemplo de la forma en que las personas novatas construyen un modelo mental plausible pero erróneo haciendo analogías. Otras confusiones incluyen:

• Una variable guarda la historia de los valores que le fueron asignados, es decir, recuerda cuál solía ser su valor.

• Está garantizado que dos objetos con el mismo valor para sus atributos nombre o identificación id son el mismo objeto.

• Las funciones son ejecutadas cuando se las define, o son ejecutadas en el orden en que son definidas.

• La condición de un bucle while se evalúa constantemente, y el bucle se detiene tan pronto como se vuelve falso. Por el contrario, la condición de las sentencias if es constantemente evaluada, y sus declaraciones son ejecutadas tan pronto como la condición se vuelve verdadera, independientemente de dónde se encuentre el flujo de control en ese momento.

• Las asignaciones modifican valores, es decir, después de a = b, la variable b queda vacía.

¿Qué errores cometen las personas novatas?

Los errores que cometen las personas novatas nos indican qué priorizar cuando enseñamos, pero resulta que la mayoría de las personas que enseñan no saben cuán comunes son los diferentes tipos de errores. El estudio más importante es el de [Brow2017], que encontró que la falta de paréntesis y comillas son el tipo de error más común en programas Java escritos por personas novatas, además de tratarse el error más sencillo de resolver. Por otro lado, algunos errores (como poner la condición de un if en {} en vez de ()) se cometen solo una vez. No extraña que los errores que producen problemas de compilación son resueltos mucho más rápido que aquellos que no lo hacen. Algunos errores, en cambio, se repiten muchas veces, como llamar métodos con los argumentos incorrectos (p. ej. pasar una cadena de caracteres en vez de un número entero).

No es correcto versus No está resuelto

Una dificultad en una investigación como esta es distinguir los errores del trabajo en proceso. Por ejemplo, una estructura if vacía o un método que se define pero aún no se ha usado puede ser señal de que el código está incompleto más que señal de un error.

[Brow2017] también comparó los errores que las personas novatas realmente cometen con los que sus docentes pensaron que cometieron. Descubrieron que, “…las/los docentes llegaron a un escaso consenso sobre cuáles son los errores más frecuentes. Sus calificaciones tenían solo una correspondencia moderada con la de las/los estudiantes en los…datos y la experiencia de las/los docentes no tuvo ningún efecto en este nivel de acuerdo.” Por ejemplo, confundir = (asignación) con == (igualdad) no eran tan común como la mayoría de las/los docentes creían.

No solo por el código

[Park2015] recopiló datos de un editor HTML en línea durante un curso introductorio de desarrollo web y encontró que la mayoría de las/los estudiantes cometieron errores de sintaxis que permanecieron sin ser resueltos por semanas durante el curso. El 20% de esos errores estaban relacionados con reglas relativamente complejas que indican cuándo es válido que los elementos HTML estén anidados entre sí, pero el 35% estaba relacionado a sintaxis de etiquetas más simples que determinan cómo los elementos HTML están anidados. La tendencia de muchas/os docentes a decir “Pero las reglas son simples,” es un buen ejemplo del punto ciego de las personas expertas que se analiza en el Capítulo 3…

¿Cómo programan las personas novatas?

[Solo1984,Solo1986] son trabajos pioneros en la exploración de las estrategias de programación de personas novatas y expertas. El hallazgo clave es que las personas expertas saben al mismo tiempo el “qué” y el “cómo,” es decir, entienden qué poner en los programas y tienen un conjunto de patrones o plan para guiar su construcción. Las personas principiantes no tienen ninguna de las dos cosas, pero la mayoría de las/los docentes se enfocan únicamente en lo primero, a pesar de que los errores son usualmente causados por no tener una estrategia para resolver el problema, en lugar de falta de conocimiento sobre el lenguaje. Un trabajo reciente mostró la efectividad de enseñar cuatro habilidades distintas en un orden específico [Xie2019]:

	semántica del código	plantillas asociadas a objetivos
leyendo	1. leer el código y predecir su comportamiento	3. reconocer plantillas y sus usos
escribiendo	2. escribir la sintaxis correcta	4. usar las plantillas para alcanzar objetivos

Por lo tanto, nuestras siguientes recomendaciones son: haz que tus estudiantes lean código, luego lo modifiquen, luego lo escriban y además preséntales explícitamente patrones comunes y haz que practiquen usándolos. [Mull2007b] es uno de los tantos estudios que muestran los beneficios de enseñar patrones comunes de manera explícita. Descomponer los problemas en patrones comunes crea oportunidades naturales para crear y etiquetar sub-objetivos [Marg2012,Marg2016].

¿Cómo identifican y resuelven errores las personas novatas?

Una década atrás, [McCa2008] escribieron: “Es sorprendente el poco espacio que se dedica a los errores y cómo resolverlos en la mayoría de los libros introductorios de programación.” Poco ha cambiado desde entonces: hay cientos de libros sobre compiladores y sistemas operativos, pero solo unos pocos sobre depuración de errores y nunca he visto un curso de pregrado dedicado a este tema.

[List2004,List2009] encontraron que a muchas personas novatas les cuesta predecir el resultado de pocas líneas de código y seleccionar la salida correcta del código a partir de un conjunto de posibilidades cuando les decían lo que se suponía que el código debía hacer. Más recientemente, [Harr2018] encontraron que la brecha entre poder entender el código y poder escribirlo se ha cerrado en gran medida gracias a CS2, pero que las personas novatas que aún tienen esa brecha es probable que les vaya mal.

Nuestra quinta recomendación es entonces enséñales explícitamente a las personas principiantes cómo depurar errores. [Fitz2008,Murp2008] encontraron que las personas que pueden resolver errores son buenas programando, pero no todas las personas que son buenas programando son buenas resolviendo errores. Aquellas personas que eran buenas programando usaron un depurador de errores simbólico para recorrer sus programas, rastrearon su ejecución manualmente, escribieron pruebas y releyeron las especificaciones frecuentemente; todos hábitos que se pueden enseñar. Sin embargo, rastrear la ejecución paso a paso a veces se usa de manera ineficaz: por ejemplo, una persona novata podría poner la misma declaración print en ambas partes de una estructura if-else. Las personas novatas también comentarían líneas de código que en realidad eran correctas al tratar de aislar un problema. Las/los docentes pueden cometer estos dos errores deliberadamente, señalarlos y corregirlos para ayudar a las personas novatas a aprender cómo resolverlos.

Enseñar a principiantes cómo depurar errores también puede ayudar a que las clases sean más simples de manejar. [Alqa2017] encontró que estudiantes con mayor experiencia resolvieron problemas de depuración de errores significativamente más rápido, pero que los tiempos variaron ampliamente: entre 4 a 10 minutos fue el rango típico para ejercicios individuales, lo cual significa que algunas/os estudiantes necesitan entre 2 y 3 veces más tiempo que otras/os para resolver el mismo ejercicio. Para ayudar a que el progreso de todo el grupo sea más uniforme, es conveniente enseñarles a quienes resuelven los ejercicios más lentamente qué están haciendo las personas más rápidas.

La depuración de errores depende de ser capaz de leer el código, algo que múltiples estudios han demostrado que es la forma más efectiva de encontrar errores [Basi1987,Keme2009,Bacc2013]. La rúbrica de calidad de código desarrollada por [Steg2014,Steg2016a] es una buena lista de verificación de elementos a revisar, aunque se presenta mejor de a partes en lugar de toda junta.

Hacer que las/los estudiantes lean código y resuman su comportamiento es un buen ejercicio (Sección 5.1), pero frecuentemente lleva mucho tiempo practicarlo en clase. Hacer que las/los estudiantes predigan la salida de un programa justo antes de que sea ejecutado, por otro lado, ayuda a reforzar el aprendizaje (Sección 9.11) y además les da la oportunidad ideal para hacer el tipo de preguntas “qué pasaría si”. Las/los docentes o estudiantes pueden además rastrear los cambios en las variables a medida que avanzan, algo que [Cunn2017] encontró efectivo (Sección 12.2).

¿Qué pasa con las pruebas (tests)?

Las personas novatas en programación parecen tan reacias a testear software como aquellas personas profesionales. No hay duda de que hacerlo es valioso—[Cart2017] encontró que las personas novatas con un alto rendimiento dedican mucho tiempo a testear el código, mientras que las personas novatas con un bajo rendimiento dedican mucho más tiempo a trabajar en el código con errores—y muchas/os docentes requieren que las/los estudiantes escriban tests en las actividades. ¿Pero qué tan bien lo hacen? Una posible respuesta proviene de [Bria2015], quienes calificaron el código de las/los estudiantes según la cantidad de situaciones, definidas por la/el docente, que pasaban correctamente las pruebas de los programas. A la inversa, estos autores también calificaron los casos de prueba escritos por las/los estudiantes de acuerdo a cuántos errores (deliberadamente introducidos en el código) podían detectar.

Los autores encontraron que los tests de las personas novatas usualmente tienen un bajo alcance (es decir, no testean gran parte del código) y que usualmente testean muchas cosas al mismo tiempo, lo que dificulta determinar las causas de los errores.

Otra posible respuesta a la pregunta "¿Qué tan bien testean código las personas novatas?" proviene de  [Edwa2014b], quienes examinaron todos los errores en el código programado por personas novatas y a su vez identificaron aquellos errores detectados por el conjunto de pruebas (test) de personas novatas. En este trabajo se encontró que las pruebas de personas novatas solo detectaban un promedio de 13,6% de los errores presentes en la totalidad de los programas. Además, el 90% de las pruebas de las personas novatas fueron muy parecidas, lo que indica que las personas novatas escriben pruebas principalmente para confirmar que el código está haciendo lo que se supone que debe hacer en lugar de encontrar situaciones en las que el código no hace lo que se supone que debe hacer.

Un enfoque para enseñar mejores prácticas para generar pruebas es definir un problema de programación proporcionando un conjunto de pruebas que deben ser pasadas en lugar de una descripción (Sección 12.1). Sin embargo, antes de hacerlo tómate un momento para ver cuántas pruebas has escrito en tu propio código recientemente y luego decide si estás enseñando lo que crees que las personas deberían hacer, o lo que ellos (y tú) realmente hacen.

¿Importa el lenguaje?

La respuesta corta es “sí”: las personas novatas aprenden a programar más rápido y aprenden más usando herramientas basadas en bloques como Scratch (Figura 7.2) [Wein2017]. Una razón es que esos sistemas basados en bloques reducen la carga cognitiva al eliminar la posibilidad de cometer errores de sintaxis. Otra razón es que esas interfaces de bloques promueven la exploración de una manera que el texto no hace: como todas las buenas herramientas, Scratch se puede aprender accidentalmente  [Malo2010].

Pero, ¿qué sucede luego de los bloques? [Chen2018] encontró que las personas cuyo primer lenguaje de programación fue gráfico, tenían calificaciones más altas en cursos introductorios de programación en comparación con las personas cuyo primer lenguaje era textual cuando los lenguajes se aprendieron durante o antes de los primeros años de adolescencia. Nuestra sexta recomendación es preséntales interfaces basadas en bloques a niñas/os y adolescentes antes de avanzar a sistemas basados en texto. La calificación de edad corresponde a que Scratch deliberadamente parece destinado a usuarias/os jóvenes, y puede ser difícil convencer a personas adultas de que lo tomen en serio.

Scratch probablemente ha sido estudiado más que cualquier otra herramienta de programación. Un ejemplo es  [Aiva2016], quienes analizaron más de 250.000 proyectos de Scratch y encontraron (entre otras cosas) que alrededor del 28% de esos proyectos tenían algunos bloques que nunca eran usados o activados. Como en la sección anterior sobre los programas en Java incompletos versus incorrectos, las autoras plantean la hipótesis de que las/los usuarias/os pueden estar utilizando estos bloques como borrador para hacer un seguimiento de las partes del código que no quieren eliminar (todavía). Otros ejemplos son [Grov2017,Mlad2017], que estudiaron a personas novatas aprendiendo sobre bucles en Scratch, Logo y Python. Encontraron que los conceptos erróneos sobre bucles se minimizan cuando se usa un lenguaje basado en bloques en lugar de un lenguaje basado en texto. Además, a medida que las tareas se vuelven más complejas (como el uso de bucles anidados) las diferencias son mayores.

Más difícil de lo necesario

Las personas que crean lenguajes de programación hacen que esos lenguajes sean más difíciles de aprender al no realizar pruebas básicas de usabilidad. Por ejemplo, [Stef2013] encontraron que, “…las tres palabras más comunes para generar bucles en ciencias de la computación, for, while y foreach, fueron calificadas como las tres opciones más anti-intuitivas por personas que no programan.” Su trabajo muestra que sintaxis al estilo de C (como se usa en Java y Perl) son tanto más difíciles de aprender para personas novatas como una sintaxis diseñada de manera aleatoria, pero que la sintaxis de lenguajes como Python y Ruby es significativamente más fácil de aprender, y la sintaxis de un lenguaje cuyas características son probadas antes de incorporarse es aún más fácil. [Stef2017] es un útil y breve resumen de lo que realmente sabemos sobre el diseño de lenguajes de programación y por qué creemos que es cierto, mientras que [Guzd2016] expone cinco principios que los lenguajes de programación para estudiantes deberían seguir.

Programación orientada a objetos

Los objetos y clases son herramientas poderosas para personas con experiencia en programación, y muchas/os docentes promueven un enfoque de primero objetos para enseñar a programar (aunque a veces no concuerdan exactamente con lo que eso significa [Benn2007b]). [Sorv2014] describen y motivan este enfoque, y [Koll2015] describe tres generaciones de herramientas designadas para apoyar a personas novatas para que programen en ambientes orientados a objetos.

Introducir objetos temprano tiene algunos desafíos. [Mill2016b] encontró que la mayoría de las personas novatas que usan Python tenían problemas para entender self (que refiere al objeto actual): las personas lo omitieron en las definiciones de métodos, no lo usaron cuando hacían referencia a los atributos del objeto, o tuvieron ambas dificultades. [Rago2017] encontró algo similar en estudiantes de nivel secundario, y además encontró que docentes de secundaria usualmente tampoco tenían claro el concepto. En resumen, recomendamos que, como docente, comiences con funciones en vez de objetos, es decir, que no les enseñes a tus estudiantes cómo definir clases hasta que comprendan las estructuras básicas de control y los tipos de datos.

Declaración de tipos

Las personas que programan han discutido durante décadas acerca de si los tipos de datos de variables deberían ser declarados o no, usualmente basándose en su experiencia personal como profesionales en lugar de tener en cuenta el tipo de datos. [Endr2014,Fisc2015] encontraron que pedir a personas novatas que declaren los tipos de variables suma cierta complejidad a los programas, pero se compensa rápidamente al actuar como documentación del uso de los métodos —en particular, evita preguntas sobre qué métodos están disponibles y cómo usarlos.

Nombrando variables

[Kern1999] escribieron: “A menudo se alienta a quienes programan a usar nombres de variables largos independientemente del contexto. Esto es un error: la claridad a menudo se logra siendo breves.” Muchas/os programadoras/es creen esto, pero [Hofm2017] encontraron que usar palabras completas en nombres de variables condujo, en promedio, a una comprensión un 19% más rápida en comparación con letras y abreviaturas. En contraste, [Beni2017] encontraron que el uso de nombres de variables de una sola letra no afectaba la capacidad de las personas principiantes de modificar el código. Esto puede deberse a que sus programas son más cortos que los de profesionales o porque algunos nombres de variables de una sola letra tienen tipos y significados implícitos. Por ejemplo, la mayoría de las personas que programan asumen que i, j y n son enteros y que s es una cadena de caracteres, mientras que x, y y z son números de punto flotante o enteros más o menos equivalentemente.

¿Qué tan importante es esto? [Bink2012] reportaron que leer y comprender el código es fundamentalmente distinto de leer prosa: “…la estructura más formal y la sintaxis del código fuente permite a quienes programan asimilar y comprender partes del código rápidamente independientemente del estilo. En particular…las guías y los planes de programación juegan un papel importante en la comprensión.” También encontró que a las/los desarrolladoras/es con experiencia no les afecta el estilo del identificador, entonces nuestra recomendación es utilizar un estilo coherente en todos los ejemplos. Dado que la mayoría de los lenguajes tienen guías de estilo (por ejemplo, PEP 8 para Python ) y herramientas para verificar que el código siga esas pautas, nuestra recomendación completa es utiliza herramientas para garantizar que todos los ejemplos de código se adhieran a un estilo consistente.

¿Ayudan mejores mensajes de error?

Los mensajes de error incomprensibles son una fuente importante de frustración para las personas novatas (y también para personas experimentadas). Por lo tanto, en varias investigaciones se exploró si mejores mensajes de error ayudan a evitar esta frustración. Por ejemplo, [Beck2016] reescribieron algunos de los mensajes del compilador de Java para que en lugar de:

C:\stj\Hola.java:2: error: cannot find symbol
        public static void main(string[ ] args)
^
1 error
Process terminated ... there were problems.

las personas vean:

Looks like a problem on line number 2.
If ``string'' refers to a datatype, capitalize the 's'!

Efectivamente, las personas novatas que recibieron estos mensajes repitieron menos los errores y cometieron menos errores en general.

[Bari2017] fueron más allá y usaron seguimiento ocular para mostrar que a pesar de las quejas de las personas que escriben los compiladores, las personas realmente leen los mensajes de error—de hecho, pasan del 13 al 25% de su tiempo haciendo eso. Sin embargo, leer mensajes de error resulta ser tan difícil como leer el código fuente, y la dificultad en leer los mensajes de error predice fuertemente el desempeño de la tarea. Por lo tanto, al enseñar muéstrales a tus estudiantes cómo leer e interpretar mensajes de error. [Marc2011] tiene una rúbrica con respuestas a los mensajes de error que puede ser útil para calificar ese tipo de ejercicios.

¿Ayuda la visualización?

Visualizar la ejecución de un programa es una idea siempre popular, y herramientas como el tutor de Python en línea [Guo2013] y Loupe (que muestra cómo funciona un bucle de eventos de JavaScript) son útiles para enseñar. Sin embargo, las personas aprenden más al construir visualizaciones que al ver visualizaciones construidas por otras personas [Stas1998,Ceti2016], entonces, ¿las visualizaciones realmente ayudan al aprendizaje?

Para responder esto, [Cunn2017] replicaron un estudio previo sobre los tipos de esquemas que realizan las/los estudiantes cuando rastrean la ejecución del código. Encontraron que no hacer esquemas se correlaciona con un menor éxito, mientras que el seguimiento de los cambios de valor de una variable escribiendo los nuevos valores cerca de su nombre a medida que cambian fue la estrategia más efectiva.

Un posible elemento de confusión que revisaron es el tiempo: dado que quienes hacen esquemas llevan significativamente más tiempo resolver los problemas, ¿lo hacen mejor solo porque piensan por más tiempo? La respuesta es no: no encontraron correlación entre el tiempo que se tomaron y el puntaje alcanzado. Nuestra recomendación es, por lo tanto, enseña a rastrear los valores que toman las variables al depurar errores.

Diagramas de flujo

Un hallazgo que a menudo se pasa por alto sobre la visualización es que las personas entienden mejor los diagramas de flujo que el pseudocódigo si ambos están igualmente bien estructurados [Scan1989]. Los estudios previos que señalaban que el pseudocódigo superaba a los diagramas de flujo, usaron pseudocódigo estructurado pero diagramas de flujo desordenados: cuando se niveló el campo de juego, se observó que a las personas novatas les fue mejor con la representación gráfica.

¿Qué más podemos hacer para ayudar?

[Viha2014] examinó la mejora promedio en las tasas de aprobación de varios tipos de intervenciones en clases de programación. Señalan que hay muchas razones para tomar sus conclusiones con cautela: las prácticas de enseñanza previas al cambio rara vez se establecen claramente, la calidad del cambio no es juzgada, y solo el 8.3% de los estudios reportaron resultados negativos. Entonces, o hay un sesgo al reportar resultados, o la forma en la que enseñamos en este momento es la peor posible y cualquier cosa sería una mejora. Como muchos otros estudios discutidos en este capítulo, en este trabajo sólo estaban observando clases universitarias, por lo que sus hallazgos pueden no ser generalizables a otros grupos.

Con esas advertencias en mente, los autores encontraron diez cosas que las/dos docentes puede hacer para mejorar los resultados (Figura 7.3):

Colaboración:

Actividades que fomenten la colaboración entre las/los estudiantes, ya sea en aulas o en laboratorios.

Cambio del contenido:

Se modificaron o actualizaron partes del material.

Contextualización:

El contenido y las actividades del curso se alinearon con un contexto específico, como juegos o medios.

CS0:

Creación de un curso preliminar a tomar antes del curso introductorio de programación; podría organizarse solo para algunas personas (por ejemplo, si están en riesgo de abandonar).

Temática de juego:

Se introdujo una componente de juego en el curso.

Esquema de calificación:

Un cambio en el sistema de calificación, como, por ejemplo, aumentar la importancia de las actividades de programación y reducir la del examen.

Trabajo en equipos:

Actividades con un mayor compromiso de trabajo en grupo, como el aprendizaje en equipo y cooperativo.

Recursos multimedia:

Actividades que usen explícitamente el uso de recursos multimedia (Capítulo 10).

Apoyo de colegas:

El apoyo de pares en forma de parejas, grupos, mentoras/es contratadas/os o tutorías.

Otro apoyo:

Un término general para todas las actividades de apoyo, por ejemplo, mayor cantidad de horas docentes, canales de ayuda adicionales, etc.

Esta lista destaca la importancia del aprendizaje cooperativo. [Beck2013] analizaron este tipo de aprendizaje específicamente durante tres años académicos en cursos a cargo dos docentes diferentes y encontraron beneficios significativos en general y para muchos subgrupos. Las personas que cooperaron obtuvieron calificaciones más altas y dejaron menos preguntas en blanco en el examen final, lo que indica una mayor autoeficacia y disposición para depurar cosas.

Computación sin código

Escribir código no es la única forma de enseñar a las personas a programar: hacer que las personas novatas trabajen en ejercicios de creatividad computacional mejora sus calificaciones en varios niveles [Shel2017]. Un ejercicio típico es describir un objeto cotidiano (como un clip o un cepillo de dientes) en términos de sus entradas, salidas y funciones. Este tipo de enseñanza a veces es llamada ciencias de la computación desenchufada; La página web CS Unplugged tiene lecciones y ejercicios para este tipo de enseñanza.

¿Qué sigue?

Para aquellas personas que quieran profundizar, [Finc2019] es un completo resumen de investigación sobre educación en informática y [Ihan2016] resume los métodos que estos estudios usan más frecuentemente. Espero que algún día tengamos catálogos como [Ojos2015] y más materiales para capacitar docentes como [Hazz2014,Guzd2015a,Sent2018] para ayudarnos a enseñar mejor.

La mayor parte de la investigación mencionada en este capítulo fue financiada con fondos públicos pero tenemos que pagar para leerla: rompí la ley aproximadamente 250 veces para descargar trabajos científicos de páginas web como Sci-Hub mientras escribía este libro. Espero que llegue el día en que nadie tenga que acceder al conocimiento científico de esta manera; si investigas, por favor ayuda a que ese día se acerque publicando tu trabajo en lugares de acceso abierto.

Ejercicios

Conceptos erróneos de tus estudiantes (grupos pequeños/15’)

Trabajando en grupos pequeños, vuelvan a leer la Sección 7.3 y escriban una lista de conceptos erróneos que piensan que pueden tener sus estudiantes. ¿Qué tan específicos son? ¿Cómo verificarían que tan precisa es su lista?

Revisando errores comunes (individual/20’)

Estos errores comunes corresponden a una lista más larga en  [Sirk2012]:

Asignación invertida:

La/el estudiante asigna el valor del lado izquierdo de la variable al lado derecho de la variable en vez de hacerlo al revés.

Rama equivocada:

La/el estudiante piensa que el código del cuerpo de un if corre, aun si la condición es falsa.

Ejecutar una función en vez de definirla:

Las/los estudiantes creen que una función se ejecuta a medida que es definida.

Escribe un ejercicio para chequear que tus estudiantes no están cometiendo cada uno de estos errores.

Código desarmado (parejas/15’)

[Chen2017] describen ejercicios en los que las/los estudiantes reconstruyen el código que ha sido desarmado al eliminar comentarios, borrar o reemplazar líneas de código, al mover líneas, etc. El rendimiento en estos ejercicios se correlaciona fuertemente con el rendimiento en las evaluaciones en las que las personas deben escribir código, pero estas preguntas requieren menos trabajo para evaluar. Toma la solución de un ejercicio de programación que hayas creado en el pasado y desármalo de dos maneras distintas. Intercambia el ejercicio con tu pareja. Analicen cuánto tiempo les lleva responder correctamente los problemas elaborados por la otra persona.

El problema de la lluvia (parejas/10’)

[Solo1986] presentó el problema de la lluvia, que se ha usado en muchos estudios posteriores sobre programación [Fisl2014,Simo2013,Sepp2015]. Escribe un programa que repetidamente lea números enteros positivos hasta que llega a 99999. Después de llegar a 99999, el programa imprime el promedio de esos números leídos.

1. Resuelve el problema de la lluvia en el lenguaje de programación que prefieras.

2. Compara tu solución con la de tu pareja. ¿Qué hace tu programa que no hace el de tu colega y viceversa?

Roles de variables (parejas/15’)

[Kuit2004,Byck2005,Saja2006] presentaron un conjunto de patrones de una sola variable que encuentro muy útil en la enseñanza de personas novatas:

Valor fijo:

Un elemento que no toma un nuevo valor después de ser inicializado.

Paso a paso:

Un elemento que pasa por una sucesión sistemática y predecible de valores.

Caminante:

Un elemento que atraviesa una estructura de datos.

Elemento más reciente:

Un elemento que guarda el último valor encontrado al pasar por una sucesión de valores.

Elemento más buscado:

Un elemento que guarda el mejor o el valor más apropiado encontrado hasta el momento.

Recolector:

Un elemento que acumula el efecto de valores individuales.

Seguidor:

Un elemento que siempre obtiene su nuevo valor a partir del valor anterior de algún otro elemento.

Marca unidireccional:

Un elemento de datos de dos valores que no puede obtener su valor inicial una vez que su valor se ha cambiado.

Temporal:

Un elemento que contiene un valor solamente por poco tiempo.

Organizador:

Una estructura de datos que guarda elementos que pueden ser reordenados.

Contenedor:

Una estructura de datos que guarda elementos que pueden ser eliminados.

Elige un programa de 5 a 15 líneas y clasifica sus variables usando estas categorías. Compara tus clasificaciones con tu pareja. En los casos en los que no estuvieron de acuerdo, ¿entendieron el punto de vista de la otra persona?

¿Qué estás enseñando? (individual/10’)

Compara los temas que enseñas con la lista desarrollada en [Luxt2017] (Sección 7.1). ¿Qué temas tratas? ¿Qué temas no incluyes? ¿Qué temas adicionales incluyes pero no están en la lista?

Actividades beneficiosas (individual/10’)

Mira la lista de intervenciones desarrolladas por [Viha2014] (Sección 7.10). ¿Cuáles de estas cosas ya haces en tus clases? ¿Cuáles podrías agregar fácilmente? ¿Cuáles son irrelevantes?

Conceptos erróneos y desafíos (grupos pequeños/15’)

El sitio Desarrollo Profesional para la Enseñanza de Principios de CS incluye una lista detallada de conceptos erróneos de estudiantes y ejercicios. Trabajando en grupos pequeños, elige una sección (por ejemplo, estructura de datos o funciones) y revisa la lista. ¿Cuáles de estos conceptos erróneos recuerdas haber tenido cuando eras estudiante? ¿Cuáles tienes todavía? ¿Cuáles has visto en tus estudiantes?

¿Qué es lo que más te importa? (toda la clase/15’)

[Denn2019] les pidieron a varias personas que propongan y califiquen preguntas de investigación sobre educación en informática. Encontraron que no había superposición entre las preguntas que más les importaban a las/los investigadoras/es y las que les interesaban a quienes no investigaban. Las preguntas favoritas de las/los investigadoras/es fueron:

1. ¿Qué conceptos fundamentales de programación son los más desafiantes para las/los estudiantes?

2. ¿Qué estrategias de enseñanza son más efectivas cuando se trata de una amplia gama de experiencias previas en clases introductorias de programación?

3. ¿Qué afecta la capacidad de las/los estudiantes para generalizar a partir de ejemplos de programación simples?

4. ¿Qué prácticas de enseñanza son más efectivas para enseñar computación a niñas/os?

5. ¿Qué tipo de problemas de una clase de computación resultan más interesantes para las personas?

6. ¿Cuáles son las formas más efectivas de enseñar programación a varios grupos?

7. ¿Cuáles son las formas más efectivas de escalar la educación informática para llegar a la población general de estudiantes?

Mientras que las preguntas más importantes para las personas que no investigan fueron:

1. ¿Cómo y cuándo es mejor dar retroalimentación a las/los estudiantes sobre su código para mejorar el aprendizaje?

2. ¿Qué tipo de ejercicios de programación son más efectivos al enseñar a estudiantes de Ciencias de la Computación?

3. ¿Cuáles son los méritos relativos del aprendizaje basado en proyectos, las clases y el aprendizaje activo, para estudiantes de computación?

4. ¿Cuál es la forma más efectiva de hacer comentarios a las/los estudiantes en las clases de programación?

5. Al dividir los problemas en tareas más pequeñas mientras programan, ¿qué les resulta más difícil de aprender a las personas?

6. ¿Cuáles son los conceptos clave que las/los estudiantes deben entender en las clases introductorias de computación?

7. ¿Cuáles son las formas más efectivas de desarrollar competencia en estudiantes de disciplinas no informáticas?

8. ¿Cuál es el mejor orden para enseñar conceptos y habilidades básicas en informática?

Haz que cada persona de la clase, de forma independiente, le otorgue un punto a las ocho preguntas que más les interese, de cualquiera de las dos listas. Luego, calcula el puntaje promedio para cada pregunta. ¿Cuáles son las preguntas más populares en tu clase? ¿En qué grupo están las preguntas más populares?

Enseñar como un arte performativo

En Darwin entre las máquinas, George Dyson escribió, “En el juego de la vida y la evolución hay tres jugadores en la mesa: las personas, la naturaleza y las máquinas. Estoy firmemente del lado de la naturaleza. Pero la naturaleza, sospecho, está del lado de las máquinas…” De manera similar, ahora hay tres jugadores en el juego de la educación: los libros de texto y otros materiales de lectura, las clases en vivo, y las clases en línea automatizadas. Podrías darle a tus estudiantes clases escritas y alguna combinación de videos grabados y ejercicios para que realicen a su propio ritmo, pero si vas a enseñar en persona tienes que ofrecer algo diferente (y con suerte mejor que) cualquiera de los anteriores. Por lo tanto, este capítulo se enfoca en cómo enseñar a programar programando.

Programar en vivo

La enseñanza es teatro, no cine.
— Neal Davis

La manera más efectiva de enseñar a programar es programando en vivo [Rubi2013,Haar2017,Raj2018]. En vez de presentar material previamente escrito, quien enseña escribe el código en frente de la clase mientras que los/las estudiantes lo siguen a la par, escribiendo y ejecutando el código a medida que avanzan. Programar en vivo funciona mejor que las presentaciones por varias razones:

• Permite la enseñanza activa al facilitar a quienes están enseñando responder a los intereses y preguntas de los/las estudiantes en el momento. Una presentación de diapositivas es como una vía de ferrocarril: podrá ser un viaje suave, pero tienes que decidir hacia dónde vas con anticipación. Programar en vivo es como manejar un vehículo todo terreno: podrá ser más accidentado, pero es mucho más fácil cambiar de dirección e ir hacia donde la gente quiere.

• Mirar cómo se va escribiendo un programa es más motivador que mirar a alguien pasar diapositivas.

• Facilita la transferencia involuntaria de conocimiento: las personas aprenden más de lo que enseñamos conscientemente al observar cómo hacemos las cosas.

• Disminuye la velocidad de la persona que está enseñando: si tiene que escribir el programa a medida que avanza, entonces solo puede ir el doble de rápido que sus estudiantes, en vez de 10 veces más rápido como haría usando diapositivas.

• Ayuda a reducir la carga en la memoria de corto plazo porque hace que quien esté enseñando sea más consciente de cuánto le está mostrando a sus estudiantes.

• Los/las estudiantes pueden ver cómo diagnosticar y corregir errores. Van a dedicar mucho tiempo a esta tarea; a menos que puedan tipear de manera perfecta, programar en vivo asegura que puedan ver cómo resolver los errores de programación.

• Ver a quienes enseñan cometer errores muestra a los/las estudiantes que está bien que cometan errores. Si el/la docente no se avergüenza al cometer errores y habla sobre ellos, sus estudiantes también se sentirán más cómodos/as haciéndolo.

Otro beneficio de la programación en vivo es que demuestra el orden en que se deben escribir los programas. Cuando [Ihan2011] observaron cómo las personas resuelven problemas de Parson, encontraron que quienes tienen experiencia programando usualmente ubican la identificación del método al principio, luego agregan la mayor parte del control de flujo (es decir, bucles y condiciones), y solo después de eso, agregan detalles como la inicialización de variables y el manejo de casos especiales. Este método “fuera de orden” es ajeno para las personas novatas, que leen y escriben código en el orden en que se presenta en la página; ver el código les ayuda a descomponer los problemas en submetas que pueden abordar una a la vez. La programación en vivo además les da a quienes están enseñando la chance de enfatizar la importancia de los pequeños pasos con comentarios frecuentes [Blik2014] y la importancia de definir un plan en vez de hacer cambios más o menos aleatorios y esperar que las cosas mejoren [Spoh1985].

Sentirse cómodo/a al hablar mientras se escribe código en frente de un público requiere práctica, pero la mayoría de las personas indican que rápidamente se vuelve igual de difícil que hablar con una presentación de diapositivas. Las secciones que siguen ofrecen consejos sobre cómo mejorar la manera de programar en vivo.

Aprovecha tus errores

Los errores de tipeo son la pedagogía.
— Emily Jane McTavish

La regla más importante de la programación en vivo es aprovechar tus errores. No importa qué tan bien te prepares, cometerás algunos errores; cuando lo hagas, piensa sobre ellos con tu público. Si bien obtener datos es difícil, los/las programadores/as profesionales dedican del 25% al 60% de su tiempo identificando y resolviendo errores; las personas novatas le dedican mucho más (Sección 7.6). A pesar de ello, la mayoría de los libros de texto y tutoriales dedican poco tiempo a diagnosticar y corregir problemas. Si hablas en voz alta mientras intentas identificar qué escribiste mal o dónde tomaste el camino equivocado, y explicas cómo lo corriges, les darás a tus estudiantes un conjunto de herramientas que pueden usar cuando comentan sus propios errores.

Tropiezos deliberados

Una vez que hayas enseñado una lección varias veces, es poco probable que cometas nada más que errores básicos de tipeo (que de todas maneras pueden ser informativos). Puedes intentar recordar errores pasados y cometerlos deliberadamente, pero usualmente eso se siente forzado. Un enfoque alternativo es sacudir la programación: pide a tus estudiantes, en turnos, que te indiquen qué escribir a continuación. Esto prácticamente garantiza que te encuentres en algún tipo de problema.

Pregunta por predicciones

Una manera de mantener la motivación de tus estudiantes mientras estás programando en vivo es pedirles que hagan predicciones sobre qué hará el código que ven en la pantalla. Luego, puedes escribir las primeras sugerencias que hagan, hacer que toda la clase vote sobre cuál piensan que es la opción más probable, y finalmente ejecutar el código. Esta es una forma simple de instrucción por pares, que discutiremos en la Sección 9.2. Además de mantener su atención en la actividad, les permite practicar cómo razonar sobre el comportamiento del código.

Tómalo con calma

Cada vez que escribas un comando, agregues una línea de código a un programa o selecciones un elemento de un menú, di qué estas haciendo en voz alta. Luego señala lo que haz hecho y su resultado en la pantalla y repásalo una segunda vez. Así tus estudiantes podrán ponerse al día y revisar si lo que acaban de hacer es correcto. Esto es particularmente importante cuando algunos/as de tus estudiantes tienen dificultades para ver o escuchar, o no dominan el idioma en el que estás enseñando.

Hagas lo que hagas, no copies y pegues código: hacer eso prácticamente garantiza que irás mucho más rápido que tus estudiantes. Y si usas la tecla Tab para autocompletar lo que estás escribiendo, dilo en voz alta para que tus estudiantes entiendan qué estás haciendo, como en el siguiente ejemplo para el lenguage Python: “Usemos turtle punto ‘r’ ‘i’ y Tab para completar con ‘right’.”

Si la salida de tu comando o código hace que lo que acabas de escribir desaparezca de la vista, vuelve arriba para que tus estudiantes puedan verlo de nuevo. Si eso no es posible, ejecuta el mismo comando una segunda vez o copia y pega el último comando o comandos en las notas compartidas del taller.

Visible y con voz clara

Cuando te sientas, es más probable que mires tu pantalla en vez de mirar a tu público y puedes quedar fuera de la vista de tus estudiantes en las últimas filas del aula. Si eres físicamente capaz de pararte durante un par de horas, debes hacerlo mientras enseñas. Planifícalo y asegúrate de tener una mesa elevada, un escritorio de pie, o un atril para tu computadora portátil para que no tengas que inclinarte al escribir.

Independientemente de si estás de pie o sentado/a, asegúrate de moverte lo más que puedas: acércate a la pantalla para señalar algo, dibuja algo en la pizarra, o simplemente aléjate de la computadora por un momento y háblale directamente a tu público. Hacer esto aleja la atención de tus estudiantes de sus pantallas y les proporciona un momento natural para hacer preguntas.

Si vas a enseñar por más de un par de horas, vale la pena usar un micrófono incluso si la habitación es pequeña. Tu garganta se cansa tanto como cualquier otra parte de tu cuerpo; usar un micrófono no es diferente de usar zapatos cómodos (algo que también deberías usar). También puede marcar una gran diferencia para las personas que tienen discapacidad auditiva.

Emula la pantalla de tu estudiante

Es posible que hayas personalizado tu entorno de trabajo con una terminal de Unix elegante, un esquema de colores personalizado o una gran cantidad de atajos de teclado. Tus estudiantes no tendrán nada de eso, así que intenta crear un entorno de trabajo que refleje lo que sí tienen. Algunos/as docentes crean un usuario distinto con configuración básica en sus computadoras o una cuenta específica para enseñar si están usando algún servicio online como Scratch o GitHub. Hacer esto también puede ayudar a evitar que los paquetes que instalaste ayer para trabajar rompan la lección que se supone que enseñes hoy.

Usa la pantalla de manera sabia

Por lo general, necesitarás agrandar el tamaño de la letra considerablemente para que las personas en el fondo de la sala puedan leer. Esto significa que podrás colocar muchas menos cosas en la pantalla de las que estás acostumbrado/a. En muchos casos, se reducirá a 60–70 columnas y 20–30 filas, por lo que estarás usando una super computadora del siglo XXI como si fuera una sencilla terminal de principios de la década de 1980.

Para organizarte, maximiza la ventana que estás usando para enseñar y luego pregúntale a todos si pueden leer lo que está en la pantalla o no. Usa una fuente de color negro sobre un fondo ligeramente coloreado en vez de una fuente de color claro sobre un fondo oscuro—el tono claro deslumbrará menos que el blanco puro.

Presta atención a la iluminación de la sala: no debe estar completamente a oscuras y no debe haber luces directamente o por encima de la pantalla de protección. Dedica algunos minutos para que tus estudiantes puedan reacomodar sus mesas para ver con claridad.

Cuando la parte inferior de la proyección de la pantalla está a la misma altura que las cabezas de tus estudiantes, las personas en el fondo no podrán ver lo que ocurre en esa sección de la pantalla. Puedes elevar la parte inferior de la ventana para compensar esto, pero eso generará que tengas aún menos espacio para escribir.

Si puedes acceder a un segundo proyector y pantalla, úsalos: el espacio adicional te permitirá mostrar el código de un lado y su resultado o comportamiento del otro lado. Si la segunda pantalla requiere su propia computadora, pídele a un docente auxiliar que la controle en lugar de ir y venir entre los dos teclados.

Finalmente, si estás enseñando algo como la terminal de Unix en una consola, es importante decirle a las personas cuándo estás usando un editor de texto en la consola y cuándo regresas a la consola propiamente dicha. La mayoría de las personas novatas no han visto nunca a una ventana asumir múltiples personalidades de esta manera y pueden confundirse rápidamente cuando estás interactuando en la terminal, cuando estás escribiendo en un editor de texto, y cuando estás trabajando de manera interactiva con Python u otro lenguaje. Puedes evitar este problema usando ventanas separadas para el editor de texto; si haces esto, siempre avisa a tus estudiantes al cambiar de una ventana a la otra.

Las herramientas de accesibilidad ayudan a todas las personas

Las herramientas como Mouseposé (para Mac) y PointerFocus (para Windows) resaltan la posición del cursor del mouse en la pantalla, y las herramientas de grabación de pantalla como Camtasia y aplicaciones independientes como KeyCastr muestran teclas invisibles como Tab y Control-J a medida que las usas. Esto puede ser un poco molesto al comienzo, pero ayuda a tus estudiantes a descubrir lo que estás haciendo.

Dos dispositivos

Algunas personas usan dos dispositivos cuando enseñan: una computadora portátil conectada al proyector que sus estudiantes ven y una tableta para que puedan ver sus propias notas y las notas que los/las estudiantes están tomando (Sección 9.7). Esto es más confiable que pasar de un escritorio virtual al otro, aunque imprimir la lección sigue siendo la tecnología de respaldo más confiable.

Dibuja temprano, dibuja seguido

Los diagramas son siempre una buena idea. A veces tengo una presentación de diapositivas llena de diagramas preparada de antemano, pero construir los diagramas paso a paso ayuda a retenerlos más (Sección 4.1) y te permite improvisar.

Evita las distracciones

Desactiva las notificaciones que usas en tu computadora, especialmente las de redes sociales. Ver mensajes parpadeando en la pantalla te distrae a tí y a tus estudiantes, y puede ser incómodo si aparece un mensaje que no te gustaría que otras personas vean. De nuevo, es posible que quieras crear una segunda cuenta en tu computadora que no tenga correo electrónico u otras herramientas configuradas.

Improvisa—luego de haber aprendido el material

No te alejes de la lección que planificaste o pediste prestada la primera vez que la enseñes. Puede ser tentador desviarse del material porque te gustaría mostrar un lindo truco o demostrar otra manera de hacer algo, pero existe la posibilidad de que te encuentres con algo inesperado que te lleve más tiempo del que tienes.

Sin embargo, una vez que el material te resulte más familiar, puedes y debes comenzar a improvisar en base a los antecedentes de tus estudiantes, sus preguntas durante la clase, y lo que personalmente te parezca más interesante. Esto es como tocar una nueva canción: sigues la partitura las primeras veces, pero después de que te sientes cómodo/a con los cambios de melodía y acordes, puedes comenzar a ponerle tu propio sello.

Cuando quieras usar algo nuevo, revísalo de antemano usando la misma computadora que usarás cuando des la clase: instalar cientos de megabytes de programas a través del WiFi de la escuela secundaria en frente de jóvenes de 16 años aburridos/as no es algo por lo que alguna vez quieras pasar.

Enseñanza directa

La enseñanza directa es un método de enseñanza centrado en el diseño meticuloso del plan de estudio dictado usando un guíon predefinido. Es más como un actor recitando líneas que como el enfoque de improvisación que recomendamos. [Stoc2018] encontró que la enseñanza directa tiene un efecto estadísticamente significativo positivo a pesar de que a veces pueda ser muy repetitivo. Yo prefiero improvisar porque la enseñanza directa requiere más preparación inicial que lo que la mayoría de los grupos de estudiantes free-range pueden permitirse.

Mira a la pantalla—de vez en cuando

Está bien mirar la pantalla donde estás proyectando ocasionalmente cuando estás mostrando una sección de código o dibujando un esquema: no mirar a la sala llena de personas que te están mirando puede ayudarte a reducir tu nivel de ansiedad y darte un momento para pensar qué decir a continuación.

Sin embargo, no deberías hacerlo por más de unos segundos. Una buena regla general es tratar a la pantalla como a uno/a de tus estudiantes: si mirar a una persona durante el tiempo que miras a la pantalla te resulta incómodo, es hora de darte la vuelta y mirar a la clase nuevamente.

Inconvenientes

Programar en vivo tiene algunos inconvenientes, pero pueden evitarse o solucionarse con un poco de práctica. Si descubres que estás cometiendo demasiados errores de tipeo, reserva 5 minutos por día para practicar escribir con el teclado: también te ayudará en tu trabajo diario. Si crees que dependes demasiado de las notas de la clase, divídelas en partes más pequeñas para que solo tengas que pensar en un pequeño paso a la vez.

Y si sientes que estás pasando demasiado tiempo escribiendo código para importar librerías, encabezados de clases y código repetitivo, genera un esqueleto de código para que tú y tus estudiantes usen como punto de partida (Sección 9.9). Hacer esto también reducirá su carga cognitiva, dado que centrarán su atención donde tú quieras.

Estudiar la lección

Desde políticos/as hasta investigadores/as y docentes, quienes reforman la educación han diseñado sistemas para encontrar y apoyar a personas que pueden enseñar bien y eliminar a las personas que no lo hacen. Pero la suposición de que algunas personas nacen como docentes es errónea: en cambio, como cualquier otra representación artística, las claves para enseñar mejor son práctica y colaboración. Como explica [Gree2014], en japonés este enfoque se llama jugyokenkyu, que significa “estudiar la lección”:

Para graduarse, los/las especialistas en educación [de Japón] no solo tenían que ver como trabajaba el/la docente que le asignaban, tenían que reemplazarlo/a efectivamente, participando en su aula primero como observadores/as y luego, a la tercera semana, como una aproximación…titubeante del propio/a docente. Funcionó como una especie de relevo de docentes. Cada estudiante eligió una asignatura, preparando clases para cinco días… [y luego] cada uno/a enseñó un día. Para pasar la batuta, tenía que enseñar una clase de un día en cada asignatura: la que tenían planeada y las cuatro que no… y tenían que hacerlo delante de su docente. Después, todas las personas—el/la docente, los/las estudiantes para ser docentes, y a veces, incluso un/a observador/a externo—se sentaban alrededor de una mesa para hablar sobre lo que observaron.

Poner el trabajo bajo un microscopio para mejorarlo es común en áreas tan diversas como la fabricación y la música. Un/a músico/a profesional, por ejemplo, analizará media docena de grabaciones de “Body and Soul” o “Smells Like Teen Spirit” antes de interpretarlas. También recibirán comentarios de colegas músicos/as durante la práctica y después de las actuaciones.

Pero la retroalimentación continua no es parte de la cultura de la enseñanza en la mayoría de los países de habla inglesa. Allí, lo que sucede en el aula se queda en el aula: quienes enseñan no miran las clases de sus colegas de manera regular, por lo que no pueden tomar prestadas las buenas ideas de las demás personas. Los/as docentes podrán acceder a los planes de clases y tareas de sus colegas, la junta escolar o una editorial de libros de texto, o revisar cursos masivos abiertos en línea, pero cada persona tiene que descubrir cómo dar las clases específicas en aulas específicas para estudiantes específicos/as. Esto es particularmente cierto para personas voluntarias y docentes free-range que participan en talleres y actividades fuera de la escuela.

Desarrollar nuevas técnicas y dar lecciones de demostración (en las que una persona enseña a estudiantes reales mientras otras personas observan) no son la solución. Por ejemplo, [Finc2007,Finc2012] encontraron que de los 99 historiales analizados, quienes enseñan solo buscaron activamente nuevas prácticas o materiales en tres casos, y solo consultaron material publicado en ocho oportunidades. La mayoría de los cambios se dieron localmente, sin aportes de fuentes externas, o solo involucraron comunicación personal con otros/as docentes. [Bark2015] encontró algo similar:

La adopción no es una “acción racional”…sino una serie iterativa de decisiones tomadas en un contexto social, en base a tradiciones normativas, señales sociales, y procesos emocionales o intuitivos… No es probable que los/las docentes utilicen los resultados de investigaciones en educación como base para tomar decisiones… La retroalimentación positiva de los/las estudiantes se toma como fuerte evidencia por parte de los/las docentes de que deben continuar con una práctica.

Jugyokenkyu funciona porque maximiza la oportunidad de transferencia de conocimiento no planificada entre docentes: alguien se propone demostrar X, pero mientras lo miran, su público también (o en su lugar) aprende Y. Por ejemplo, quien enseña podría tener la intención de demostrar a sus estudiantes cómo buscar direcciones de correo electrónico en un archivo de texto, pero lo que su público podría terminar aprendiendo son algunos atajos de teclado.

Dando y recibiendo retroalimentación al enseñar

Observar a alguien te ayuda, y darle una devolución ayuda a esa persona, pero puede ser difícil recibirlas, especialmente cuando son negativas (Figura 8.1).

La retroalimentación es más fácil de dar y recibir cuando ambas partes comparten expectativas sobre lo que está y no está al alcance y sobre cómo se deben expresar los comentarios. Si solicitas una retroalimentación:

Iníciala.

Es mejor pedir la retroalimentación que recibirla de mala gana.

Elige tus preguntas,

es decir, pide comentarios específicos. Es mucho más difícil para alguien responder, “¿Qué te pareció?” que responder, “¿Hablé demasiado rápido?” o , “¿Qué cosa de esta lección debería seguir haciendo?” Direccionar la retroalimentación de esta manera además es más útil para ti. Siempre es preferible mejorar una cosa a la vez que cambiar todo y esperar que sea para mejor. Direccionar los comentarios hacia algo que elegiste trabajar ayuda a mantenerte en foco, lo que a su vez aumenta las chances de que veas un progreso.

Usa un traductor de retroalimentación.

Pídele a alguien que lea todas las devoluciones y te haga un resumen. Puede ser más fácil escuchar, “Varias personas piensan que podrías acelerar un poco,” que leer varias notas que digan, “Esto es demasiado lento” o “Esto es aburrido.”

Sé amable contigo.

La mayoría somos muy críticos/as con nosotros/as mismos/as, por lo que siempre es útil anotar lo que pensamos de nosotros/as antes de recibir retroalimentación de otras personas. Eso nos permite comparar lo que pensamos de nuestro desempeño con lo que otras personas piensan, lo que a su vez nos permite evaluar esto último con mayor precisión. Por ejemplo, es muy común que las personas piensen que están diciendo “mmm” y “ehh” con demasiada frecuencia cuando tu público en realidad no lo nota. Recibir esa retroalimentación una vez permite a los/las docentes ajustar la evaluación sobre sí mismos/as la próxima vez que se sientan así.

También puedes dar retroalimentación a otras personas de manera más efectiva:

Interactúa.

Mirar fijamente a alguien es una buena manera de hacer que se sienta incómodo/a, por lo que si deseas darle una retroalimentación sobre cómo enseña normalmente, necesitas ayudar a que se tranquilice. Interactuar con la persona como si fueras estudiante es una buena manera de hacer esto, así que haz preguntas o simula escribir su ejemplo. Si eres parte de un grupo, haz que una o dos personas desempeñen el papel de estudiantes mientras que el resto toma notas.

Balancea la retroalimentación positiva y negativa.

El “sándwich de cumplidos” compuesto por un comentario positivo, uno negativo, y un segundo positivo se vuelve agotador rápidamente, pero es importante decirle a las personas qué deben seguir haciendo y qué deben cambiar¹³.

Toma notas.

No vas a recordar todo lo que notaste si la presentación dura más de unos pocos segundos, y definitivamente no vas a recordar con qué frecuencia lo notaste. Escribe una nota la primera vez que algo suceda y luego agrega una marca o cruz cuando vuelva a ocurrir para que puedas ordenar tus comentarios por frecuencia.

Tomar notas es más eficiente cuando tienes algún tipo de rúbrica para que tengas que apurarte a escribir tus observaciones mientras la persona que estás observando todavía está hablando. La rúbrica más simple para dar comentarios de forma libre en grupo es la grilla de 2x2 cuyo eje vertical tiene las etiquetas “lo que salió bien” y “lo que se puede mejorar”, y en el eje horizontal “contenido” (lo que se dijo) y “presentación” (cómo se dijo). Quienes observan escriben sus comentarios en notas autoadhesivas mientras miran la demostración, luego las pegan en los cuadrantes de la grilla dibujada en una pizarra (Figura 8.2).

Rúbricas e inventario de preguntas

La Sección 21.1 contiene una rúbrica de ejemplo para evaluar 5–10 minutos de enseñanza de programación. Presenta elementos más o menos en el orden en que es probable que aparezcan, por ejemplo, preguntas sobre la introducción aparecen antes que las preguntas sobre la conclusión.

Rúbricas como esta tienden a crecer con el tiempo a medida que las personas piensan en cosas que les gustaría agregar. Una buena manera de mantener las rúbricas manejables es insistir en que la longitud total permanezca constante: si alguien quiere agregar una pregunta, debe identificar una que sea menos importante y que pueda sacarse.

Si te interesa dar y recibir retroalimentación, [Gorm2014] tiene buenos consejos que puedes usar para hacer que la retroalimentación entre pares sea parte del proceso de enseñanza, mientras que [Gawa2011] analiza el valor de tener un/a tutor/a.

Clases de estudio

Las escuelas de arquitectura a menudo incluyen clases de estudio en las que estudiantes resuelven pequeños problemas de diseño y reciben devoluciones de sus pares en ese mismo momento. Estas clases son más efectivas cuando el/la docente evalúa las devoluciones de pares para que quienes participen aprendan no solo cómo construir edificios sino también cómo dar y recibir retroalimentación [Scho1984]. Las clases magistrales de música tienen un propósito similar, y he descubierto que dar retroalimentación sobre la retroalimentación ayuda a las personas a mejorar su manera de enseñar también.

¿Cómo practicar cómo enseñamos?

La mejor manera de perfecccionar la forma en que damos clases en persona es observarse a sí mismo/a hacerlo:

• Trabaja en grupos de a tres personas.

• Cada persona rota entre los roles de docente, público y quien graba. La persona en el rol docente tiene dos minutos para explicar algo. La persona que pretende ser el público está allí para prestar atención, mientras que la tercera persona graba la sesión con un teléfono u otro dispositivo portátil.

• Luego de que todas las personas tuvieron la oportunidad de enseñar, el grupo mira todos los videos. Cada persona da una retroalimentación sobre los tres videos, es decir, las personas dan una devolución sobre sí mismas y sobre las demás.

• Después de que se discutieron los videos, se borran. (Muchas personas se sienten justificadamente incómodas por su presencia en internet.)

• Finalmente, toda la clase vuelve a reunirse y agrega las devoluciones a una grilla 2x2 compartida como la que se describió previamente sin decir de quién se trata cada comentario.

Para que este ejercicio funcione bien:

• Graben los tres videos y luego miren los tres. Si el ciclo es enseñar-revisar-enseñar-revisar, la última persona en enseñar siempre se queda sin tiempo (a veces a propósito). Hacer todas las revisiones luego de que todas las personas enseñaron también ayuda a poner un poco de distancia entre los dos momentos, lo que hace que el ejercicio sea un poco menos incómodo.

• Avísales a las personas al comienzo de la clase que les pedirás que enseñen algo para que tengan tiempo de elegir un tema. Avisarles con mucha anticipación puede ser contraproducente, ya que algunas personas se preocuparán por cuánto deben prepararse.

• Los grupos deben estar físicamente separados para reducir el ruido en sus grabaciones. En la práctica, esto significa 2–3 grupos en un aula de tamaño normal y el resto usando espacios de descanso cercanos, oficinas o (en una ocasión) el armario de la conserjería.

• Las personas deben dar retroalimentación sobre sí mismas y entre sí para que puedan calibrar sus impresiones de la manera en que enseñan contra las de otras personas. La mayoría de las personas son más críticas sobre ellas mismas de lo que deberían ser y es importante que se den cuenta de esto.

El anuncio de este ejercicio usualmente es recibido con quejidos y aprensión, ya que pocas personas disfrutan verse o escucharse a sí mismas. Sin embargo, esas mismas personas lo califican constantemente como una de las partes más valiosas de los talleres de enseñanza. También es una buena preparación para enseñar de a pares (Sección 9.3): a las personas que enseñan les resulta mucho más fácil intercambiar devoluciones informales si han tenido algo de práctica y tienen una rúbrica compartida para definir expectativas.

Y hablando de rúbricas: una vez que la clase haya puesto todos sus comentarios en una grilla compartida, elige algunos comentarios positivos y negativos, haz una lista y pídeles que hagan el ejercicio nuevamente. La mayoría de las personas se sienten más cómodas la segunda vez y la evaluación sobre lo que han decidido que es importante aumenta su sentido de autodeterminación (Capítulo 10).

Tics

Todas las personas tenemos hábitos nerviosos: hablamos más rápido y con voz más aguda de lo normal cuando estamos en el escenario, jugamos con nuestro pelo, o hacemos sonar los nudillos. Las personas que juegan llaman a esto “tics” y a menudo no se dan cuenta de que se mueven, se miran los zapatos, o juegan con lo que tienen en los bolsillos cuando en realidad no saben la respuesta a una pregunta.

No puedes deshacerte de los tics completamente, e intentar hacerlo puede hacer que te obsesiones con ellos. Una mejor estrategia es tratar de desplazarlos, por ejemplo, entrenarse para apretar los dedos de los pies dentro de los zapatos cuando tienes nervios en vez de limpiarte la oreja con el dedo meñique.

Ejercicios

Dar devolución sobre una mala enseñanza (toda la clase/20’)

En grupo, miren este video de mala enseñanza (en inglés, subtitulado al español —activen los subtítulos al ingresar al link) y den retroalimentación sobre dos ejes: positivo versus negativo y contenido versus presentación. Que cada persona en la clase agregue un comentario a la grilla 2x2 en una pizarra en las notas compartidas sin duplicar ningún comentario. ¿Qué vieron otras personas y tú no? ¿Con qué comentarios estás totalmente de acuerdo o en desacuerdo?

Practicar dar devoluciones (grupos pequeños/45’)

Usa el proceso descripto en la Sección 8.4 para enseñar en grupos de tres personas y recolectar las devoluciones.

Lo malo y lo bueno (toda la clase/20’)

Mira los videos de programación en vivo mal desarrollada y bien desarrollada y resume tu devolución sobre las diferencias usando la grilla 2x2 habitual. ¿De qué manera la segunda sesión de enseñanza es mejor que la primera? ¿Hay algo qué es mejor en el primer video que en el segundo?

Observa, luego haz (parejas/30’)

Enseña a tu pareja 3–4 minutos de una lección usando programación en vivo, luego intercambien lugares y observa a esa persona programar en vivo. No te preocupes por grabar estas sesiones—es difícil capturar tanto a la persona como a la pantalla con un dispositivo portátil—pero da una devolución de la misma manera que lo hiciste antes. Explícales a tus colegas qué vas a enseñar y con qué esperas que estén familiarizados/as.

• ¿Qué se siente diferente entre programar en vivo y dar una clase tradicional? ¿Cuál fue más fácil y más difícil?

• ¿Cometiste algún error? Si lo hiciste, ¿cómo lo manejaste?

• ¿Hablaste y escribiste al mismo tiempo o alternadamente?

• ¿Con qué frecuencia señalaste algo en la pantalla? ¿Con qué frecuencia usaste el cursor para resaltar algo?

• ¿Qué intentarás seguir haciendo la próxima vez? ¿Qué intentarás hacer diferente?

Tics (grupos pequeños/15’)

1. Toma notas sobre los tics que piensas que tienes, pero no las compartas con otras personas.

2. Enseña una clase corta (de 2–3 minutos).

3. Pregúntale a tu público cómo creen que te traicionan los nervios. ¿Coinciden con lo que pensaste de ti?

Consejos para enseñar (grupos pequeños/15’)

El sitio CS Teaching Tips (en inglés) tiene una gran cantidad de consejos prácticos sobre cómo enseñar computación, así como una colección de hojas de consejos descargables. Revisa las hojas de consejos en grupos pequeños y clasifica cada uno de acuerdo a si lo usas todo el tiempo, ocasionalmente, o nunca lo usaste. ¿En qué se diferencia tu práctica y la práctica de tus compañeros/as? ¿Hay algún consejo con el que no estés de acuerdo o creas que sería ineficaz?

Resumen

En el salón de clase

El capítulo anterior describió cómo practicar la enseñanza de una lección y describió un método —programación en vivo— que permite a las/los docentes adaptarse al ritmo y los intereses de sus estudiantes. Este capítulo describe otras prácticas que también son útiles en clases de programación.

Antes de describirlas, vale la pena detenerse un momento para establecer expectativas. El mejor método de enseñanza que conocemos es la tutoría individual: [Bloo1984] descubrió que el desempeño de las/los estudiantes a quienes se les enseñó uno a uno fue dos desviaciones estándar mejor que el de quienes aprendieron mediante una clase convencional. Es decir, que las/los estudiantes con tutoría individual superaron al 98% de estudiantes a quienes se les dio clases magistrales convencionales. Sin embargo, si bien la tutoría y la enseñanza a aprendices han sido históricamente las formas más comunes de transmitir conocimientos, hoy son excepciones debido a la industrialización de la educación formal. A pesar de la explosión en torno a la inteligencia artificial, la solución no estará allí a corto plazo: por eso, cada método que se describe a continuación es esencialmente un intento de abordar la efectividad de la tutoría individual a escala.

Hacer cumplir el Código de Conducta

Lo más importante que he aprendido sobre enseñar en los últimos 30 años es la importancia de tratar a las demás personas con respeto, tanto dentro como fuera de la clase. Si usas este material de alguna manera, por favor adopta un Código de Conducta como el del Anexo 17 y exige a toda persona que participe en tus clases que lo respete. No puedes evitar que las personas sean ofensivas, de la misma manera que las leyes contra el robo no evitan que las personas roben, pero puedes dejar claras las expectativas y las consecuencias, y señalar que estás tratando de que tu clase sea un lugar seguro y amigable para todas/os.

Un Código de Conducta sólo es útil si se hace cumplir. Si crees que alguien ha violado el tuyo, puedes advertirle, pedirle que se disculpe, y/o expulsarla/o, dependiendo de la gravedad de la infracción y de si crees que fue intencional o no. Hagas lo que hagas:

Hazlo frente a testigos.

La mayoría de las personas bajarán el tono de su lenguaje y hostilidad en público, tener presente a alguien más asegura que la discusión posterior no degenere en afirmaciones contradictorias sobre quién dijo qué.

Si expulsas a alguien, comunícalo al resto de la clase y explica por qué.

Esto ayuda a evitar que los rumores se difundan y muestra que tu Código de Conducta realmente significa algo.

Envía un correo electrónico a la persona infractora tan pronto como puedas

para resumir lo que sucedió y los pasos que tomaste, y copia el mensaje a las/los anfitrionas/es del taller o a alguna/o de tus colegas docentes para que haya un registro contemporáneo de la conversación. Si la persona infractora responde, no participes en un debate largo: nunca es productivo.

Lo que sucede fuera de la clase importa al menos tanto como lo que sucede dentro de ella [Part2011], por lo que debes proporcionar una forma para que tus estudiantes puedan informar sobre los problemas que tú no puedes ver. Un paso es pedirle a alguien fuera de tu grupo que sea el primer punto de contacto; de esta manera, si alguien quiere presentar una queja sobre ti o alguno de tus colegas educadores, tiene cierta garantía de confidencialidad y acción independiente. [Auro2019] tiene muchos otros consejos y es a la vez breve y práctico.

Instrucción por pares

Sin importar qué tan buena sea una persona enseñando, solo puede explicar una cosa a la vez. Entonces, ¿cómo puede aclarar muchos conceptos erróneos diferentes en un tiempo razonable? La mejor solución desarrollada hasta ahora es una técnica llamada instrucción por pares. Originalmente creada por Eric Mazur en Harvard [Mazu1996], se ha estudiado extensamente en una amplia variedad de contextos, incluida la programación [Crou2001,Port2013], y [Port2016] descubrieron que las/los estudiantes valoran la instrucción de sus pares incluso en el primer contacto.

La instrucción por pares intenta proporcionar instrucción individualizada de manera escalable intercalando la evaluación formativa con la discusión entre estudiantes:

1. Haz una breve introducción al tema.

2. Ofrece a tus estudiantes una pregunta de opción múltiple que investigue sus conceptos erróneos. (en lugar de evaluar el simple conocimiento de hechos).

3. Haz que el conjunto de tus estudiantes responda la pregunta de opción múltiple.

   • Si todas/os tus estudiantes tienen la respuesta correcta, continúa.

   • Si todas/os tienen la misma respuesta incorrecta, aborda ese error específico.

   • Si tienen una combinación de respuestas correctas e incorrectas, dales varios minutos para discutir entre ellas/os en grupos de 2 a 4, luego que vuelvan a votar.

Como muestra este video, la discusión en grupo mejora significativamente la comprensión de las/los estudiantes porque descubre lagunas en sus razonamientos y obliga a que aclaren sus pensamientos. Entonces, volver a sondear a la clase permite que la/el docente averigüe si puede continuar o si se necesitan más explicaciones. Después de presentar la respuesta correcta, una ronda de explicación adicional le da a las/los estudiantes una oportunidad más para solidificar su comprensión.

Pero, ¿podría ser esto un falso positivo? ¿Los resultados están mejorando debido a una mayor comprensión durante la discusión o simplemente por un efecto de seguimiento de quien lidera el grupo (“vota como Andrea, ella siempre tiene la razón”)? [Smit2009] evaluaron esta cuestión: luego de la primera pregunta, hicieron una segunda pregunta que las/los estudiantes respondieron individualmente. Descubrieron que la discusión entre pares mejora la comprensión, incluso cuando ninguna de las personas en un grupo de discusión sabía originalmente la respuesta correcta. Siempre que exista diversidad de opiniones dentro del grupo, sus conceptos erróneos se anulan.

Tomar posición

Es importante que tus estudiantes voten públicamente para que no puedan cambiar de opinión después y racionalizarlo con excusas como: “Acabo de interpretar mal la pregunta.” Gran parte del valor de la instrucción por pares proviene de la hipercorrección: obtener la respuesta incorrecta y tener que pensar en las razones del porqué de esta respuesta (Sección 5.1).

Enseñar en comunidad

Co-enseñar describe cualquier situación en la que dos docentes trabajan juntas/os en la misma clase. [Frie2016] describen muchas formas de hacer esto, ejemplificadas con docentes A y B:

Enseñar en equipo:

Ambas/os docentes entregan un único flujo de contenido en conjunto, turnándose como dos músicas/os haciendo solos.

Enseñar y ayudar:

La/el docente A enseña mientras B se mueve por el aula para ayudar a estudiantes con dificultades.

Enseñanza alternativa:

La/el docente A proporciona a un pequeño grupo de estudiantes una instrucción más intensiva o especializada mientras B ofrece una lección general al grupo principal.

Enseñar y observar:

La/el docente A enseña mientras B observa a los estudiantes y recopila datos sobre su comprensión para ayudar a planificar las futuras lecciones.

Enseñanza paralela:

La clase se divide en dos. Las/los docentes presentan el mismo material simultáneamente a cada grupo.

Enseñanza por estaciones:

Las/los estudiantes se dividen en pequeños grupos que rotan de una estación o actividad a la siguiente, mientras las/los docentes supervisan donde sea necesario.

Todos estos modelos crean más oportunidades para la transferencia involuntaria de conocimiento que la enseñanza por sí sola. Enseñar en equipo es particularmente beneficioso en talleres de un día: cada docente tendrá la oportunidad de descansar su voz y se reduce el riesgo de que al final del día el agotamiento sea tan grande que comience a hablar bruscamente con sus estudiantes o a manipularles el teclado.

Ayudar

Muchas personas que no se sienten cómodas enseñando están dispuestas y son capaces de brindar asistencia técnica en clase. Pueden ayudar a las/los estudiantes con la configuración e instalación de programas, responder preguntas técnicas durante los ejercicios, supervisar la sala para detectar personas que puedan necesitar ayuda o poner atención a las notas compartidas (Sección 9.7), y responder preguntas o recordar que la/el docente lo haga durante los descansos.

Las/los ayudantes a veces son personas que se están capacitando para convertirse en docentes (es decir, son la/el docente B en el modelo de enseñar y apoyar), pero también pueden ser parte del personal de apoyo técnico de la institución anfitriona, ex estudiantes de la clase o estudiantes avanzadas/os que ya conocen bien el material. Usar a estas/os últimas/os como ayudantes es doblemente efectivo: no solo es más probable que comprendan los problemas que tienen sus pares, sino que también evita que se aburran. El aburrimiento es contagioso, así que evitarlo ayuda a que toda la clase se mantenga comprometida: si un puñado de personas comienzan a dispersarse, las personas que las rodean seguirán su ejemplo.

Si estás co-enseñando con una/un colega:

• Toma de dos a tres minutos antes del comienzo de cada clase para confirmar quién está enseñando qué. Si tienen tiempo, intenten dibujar o revisar en conjunto un mapa conceptual.

• Usa ese tiempo para acordar también un par de señales de manos. “Vas demasiado rápido”, “habla”, “ese estudiante necesita ayuda” y “es hora de ir al baño” son todas útiles.

• Cada persona debe enseñar durante al menos 10 a 15 minutos seguidos, ya que los estudiantes se distraen con cambios más frecuentes.

• La persona que no está enseñando no debe interrumpir, ofrecer correcciones o elaboraciones, o hacer cualquier otra cosa que distraiga de lo que está haciendo o diciendo la persona que enseña. La única excepción es hacer preguntas guía si las/los estudiantes parecen pasivas/os o inseguras/os de sí mismas/os.

• Cada persona debería tomarse un par de minutos antes de empezar la clase para ver lo que su co-docente va a enseñar después de su turno y entonces no presentar nada de ese material.

• La persona que no está enseñando debe mantenerse comprometida con la clase, no debe hacer otra cosa, como ponerse al día con su correo electrónico. Supervisar las notas compartidas (Sección 9.7), vigilar a las/los estudiantes para ver quién tiene dificultades, anotar algunos comentarios para dárselos a su co-docente en el próximo receso—cualquier cosa que contribuya a la lección es mejor que cualquier cosa que no lo haga.

Lo más importante es que, cuando termine la clase, quienes co-enseñan tomen unos minutos para felicitarse o compadecerse: tanto en la enseñanza como en la vida, la pena compartida disminuye y la alegría compartida aumenta.

Evaluar conocimientos previos

Cuanto más sepas sobre tus estudiantes antes de comenzar a enseñar, más podrás ayudarles. Dentro de un sistema escolar formal, los pre-requisitos de tu curso te darán información sobre lo que probablemente ya sepan. Sin embargo, en un entorno free-range, tus estudiantes pueden ser mucho más diversas/os, por lo que es posible que quieras hacerles una breve encuesta o cuestionario antes de la clase para averiguar qué conocimientos y habilidades tienen.

Pedir a las personas que se califiquen a sí mismas en una escala del 1 al 5 no tiene sentido porque cuanto menos saben las personas sobre un tema, con menor precisión pueden estimar sus conocimientos (Figura 9.1, de Neurologica), un fenómeno llamado efecto Dunning-Kruger [Krug1999]. Por el contrario, las personas que integran grupos sub-representados a menudo subestiman sus habilidades.

En lugar de pedirles a las personas que se autoevalúen, puedes preguntarles con qué facilidad podrían completar algunas tareas específicas. Sin embargo, hacer esto es arriesgado: la escuela entrena a las personas para que traten cualquier cosa que parezca un examen como algo que tienen que aprobar, en lugar de tomarlo como una oportunidad para dar forma a la instrucción. Si alguien responde “No sé” incluso a un par de preguntas en su pre-evaluación, podría concluir que tu clase es demasiado avanzada para su nivel. Por lo tanto, es posible que asustes a muchas de las personas que más deseas ayudar.

La Sección 21.5 presenta un breve cuestionario de pre-evaluación que es poco probable que la mayoría de tus potenciales estudiantes encuentren intimidante. Si usas este formulario o una herramienta parecida, trata de hacer un seguimiento a las personas que no respondan para averiguar por qué no lo hicieron. Además, compara tu evaluación con la que las personas hicieron de sí mismas, de modo de mejorar tus preguntas en el futuro.

Planifica para habilidades mixtas

Si tus estudiantes tienen niveles muy diversos de conocimientos previos, puedes terminar fácilmente en una situación en la que un tercio de tu clase se pierde y un tercio se aburre. Eso es poco satisfactorio para toda la clase, pero hay algunas estrategias que puedes utilizar para manejar la situación:

• Antes de realizar un taller, comunica claramente su nivel a todas las personas mostrando algunos ejemplos de ejercicios que se les pediría que completen. Esto ayuda a tus potenciales participantes a evaluar el nivel de la clase de manera mucho más efectiva que un listado de temas.

• Proporciona ejercicios adicionales que tus estudiantes puedan hacer a su propio ritmo, para que quienes estén más avanzadas/os no terminen temprano y se aburran.

• Pon atención a las/los estudiantes que se están quedando atrás y actúa temprano para que no se frustren ni se den por vencidas/os.

• Pide a tus estudiantes más avanzadas/os que ayuden a las personas que están a su lado (mira la Sección 9.6 debajo).

Otra forma en que puedes adaptarte si hay habilidades mixtas entre tus estudiantes es hacer que todas las personas trabajen en el material por su cuenta a su propio ritmo, como lo harían en un curso en línea pero simultáneamente, y contando con ayudantes que deambulan por la sala para despejar las dudas. Algunas personas llegarán tres o cuatro veces más lejos que otras cuando los talleres se realicen de esta manera, pero todas habrán tenido un día gratificante y desafiante.

Falsas/os principiantes

Una/Un falsa/o principiante es alguien que ha estudiado un lenguaje previamente pero lo está aprendiendo de nuevo. Pueden ser indistinguibles de principiantes absolutas/os en las pruebas de pre-evaluación, pero avanzan mucho más rápido una vez que comienza la clase porque están volviendo a aprender en lugar de aprender por primera vez.

Ser una/un falsa/o principiante es a menudo una señal de privilegio de preparación [Marg2010]. Las/los falsas/os principiantes son comunes en las clases de programación free-range. Por ejemplo, imaginemos una/un niña/o que pudo ir a un campamento de verano de robótica porque su familia tiene los recursos suficientes. Es posible que tenga un desempeño pobre en una pre-evaluación de conocimientos de programación porque el material no está fresco en su mente. Sin embargo, aún tiene una ventaja sobre una/un niña/o con un trasfondo menos afortunado. Las estrategias descriptas anteriormente pueden ayudar a nivelar el campo de juego en casos como este pero, nuevamente, la solución real es usar tu propio privilegio para abordar los factores externos a la clase que sean de mayor relevancia [Part2011].

Lo más importante es aceptar que no puedes ayudar a todo el curso todo el tiempo. Si reduces el ritmo para adaptarte a dos personas a quienes les está costando, estás fallando con las otras dieciocho personas. Del mismo modo, si dedicas unos minutos a hablar sobre un tema avanzado con una/un estudiante aburrida/o, el resto de la clase se sentirá excluida.

Programación en parejas

La programación en parejas es una práctica de desarrollo de software en la que dos personas programan juntas en una computadora. Una persona (quien conduce) escribe, mientras que la otra (quien navega) ofrece comentarios y sugerencias, y ambas cambian de función varias veces por hora.

La programación en parejas es una práctica eficaz en el trabajo profesional [Hann2009] y también es una buena forma de enseñar: los beneficios incluyen una mayor tasa de éxito en los cursos introductorios, un mejor software y una mayor confianza de las/los estudiantes en sus soluciones. También hay evidencia de que estudiantes de grupos sub-representados se benefician incluso más que otros [McDo2006,Hank2011,Port2013,Cele2018]. Los pares pueden ayudarse mutuamente durante los ejercicios prácticos, aclarar los conceptos erróneos de la otra persona cuando se presenta la solución y discutir intereses comunes durante los descansos. Lo he encontrado particularmente útil en los cursos con habilidades mixtas, ya que las parejas son más homogéneas que los individuos.

Cuando utilices la programación en parejas, coloca a todas las personas en parejas, no solo a las/los estudiantes que tienen dificultades, para que nadie se sienta señalada/o. También es útil que las personas se sienten en lugares nuevos frecuentemente (y, por lo tanto, trabajen con diferentes personas) y que las personas cambien de rol dentro de cada pareja tres o cuatro veces por hora para que la personalidad más fuerte de cada pareja no domine la sesión.

Si tus estudiantes usan la programación en parejas por primera vez, toma unos minutos para demostrar de qué se trata para que comprendan que no esperas que la persona que no tiene las manos en el teclado únicamente permanezca sentada y observe. Finalmente, diles que las personas que se enfocan en tratar de completar la tarea lo más rápido posible son menos justas al compartir [Lewi2015].

Cambio de parejas

Las/los docentes tienen opiniones encontradas sobre si se debería exigir a las personas que cambien de pareja a intervalos regulares. Por un lado, cambiar de parejas les da a todos la oportunidad de obtener nuevos conocimientos y hacer nuevas amistades. Por otro lado, trasladar las computadoras y los adaptadores de corriente a escritorios nuevos varias veces al día es desgastante y el cambio de parejas puede resultar incómodo para las personas más introvertidas. Dicho esto, [Hann2010] encontró una correlación débil entre los “cinco grandes” rasgos de personalidad y el rendimiento en la programación en parejas, aunque un estudio anterior [Wall2009] encontró que las parejas cuyos integrantes tenían diferentes niveles de rasgos de personalidad se comunicaban con más frecuencia.

Tomar notas…¿juntas/os?

La toma de notas es una forma de elaboración en tiempo real (Sección 5.1): te obliga a organizar y reflexionar sobre el material a medida que se presenta, lo que a su vez aumenta la probabilidad de que lo transfieras a la memoria a largo plazo. Muchos estudios han demostrado que tomar notas mientras se aprende mejora la retención [Aike1975,Boha2011]. Si bien aún no se ha estudiado ampliamente [Ornd2015,Yang2015], he descubierto que hacer que tus estudiantes tomen notas juntos en una página en línea compartida también es eficaz:

• Permite a las personas comparar lo que creen que ellas están escuchando con lo que están escuchando las otras personas, lo que les ayuda a llenar los vacíos y a corregir conceptos erróneos de inmediato.

• Les da a las/los estudiantes más avanzadas/os de la clase algo útil que hacer. En lugar de aburrirse y revisar Instagram durante la clase, pueden tomar la iniciativa de registrar lo que se dice, lo que mantiene su compromiso a la vez que permite a las/los estudiantes menos avanzadas/os concentrarse más en el nuevo material.

• Las notas que toman las/los estudiantes suelen ser más útiles para ellas/os que las que la/el docente prepararía de antemano. Es probable que los contenidos que les resultan nuevos a las/los estudiantes se vean bien reflejados en las notas compartidas, mientras que para la/el docente es más difícil predecir qué parte del material que enseñará será realmente nuevo.

• Mirar notas recientes mientras las/los estudiantes están trabajando en un ejercicio ayuda al docente a descubrir si la clase se perdió o si algo se entendió mal.

¿Es el lápiz más poderoso que el teclado?

[Muel2014] informaron que tomar notas en una computadora es generalmente menos efectivo que tomar notas con lápiz y papel. Si bien su resultado fue ampliamente compartido, [More2019] no pudieron replicarlo.

Si tus estudiantes toman notas juntos, también puedes aprovechar para hacer evaluaciones formativas: que peguen fragmentos cortos de código o que respondan preguntas en forma de puntos o de oraciones. Siempre que quieras que cada persona responda una pregunta, haz una lista con el nombre de tus estudiantes y pégala en el documento, de modo de evitar que todas las personas intenten editar el mismo par de líneas al mismo tiempo.

Es frecuente que la primera vez que las/los estudiantes tomen notas compartidas sientan que se distraen, porque tienen que dividir su atención entre lo que dice la/el docente y lo que escriben sus pares (Sección 4.1). Si estás trabajando por única vez con un grupo en particular, debes prestar atención a los consejos en la Sección 9.12 y pedirles que tomen notas individualmente.

Puntos para mejorar

Una forma de demostrar a tus estudiantes que están aprendiendo contigo, no solo de ti, es permitirles que tomen notas editando (una copia de) tu lección. En lugar de publicar archivos PDF para que los descarguen, crea copias editables de tus diapositivas, notas y ejercicios en una wiki, un documento de Google o cualquier otra herramienta que te permita revisar y comentar los cambios. Darle crédito a las personas por corregir errores, aclarar explicaciones, agregar nuevos ejemplos y escribir nuevos ejercicios no reduce tu carga de trabajo, pero aumenta el compromiso y el tiempo de vida de la lección. (Sección 6.3).

Notas adhesivas

Las notas adhesivas son una de mis herramientas de enseñanza favoritas, y no soy el único que ama su versatilidad, portabilidad, adherencia, capacidad de plegado y aroma sutil pero atractivo [Ward2015].

Como indicadores de estado

Reparte a cada estudiante dos notas adhesivas de diferentes colores, como, por ejemplo, naranja y verde. Las notas adhesivas se pueden sostener para votar, pero su uso real es como indicadores de estado. Si alguien ha completado un ejercicio y quiere que lo revisen, coloca la nota adhesiva verde en su laptop; si tiene un problema y necesita ayuda, coloca la nota naranja. Esto funciona mucho mejor que pedirle a la gente que levante la mano: es más discreto (lo que significa que es más probable que lo hagan), pueden seguir trabajando mientras su bandera está levantada en lugar de intentar escribir con una sola mano, y puedes ver rápidamente desde el frente del salón en qué estado se encuentra tu clase. Los indicadores de estado son particularmente útiles en clases donde las personas con habilidades mixtas están trabajando en el material a su propio ritmo (Sección 9.5).

Una vez que tus estudiantes se sientan cómodos con dos notas adhesivas, puedes darles una tercera que puedan usar cuando tengan el cerebro lleno o necesiten un descanso para ir al baño ¹⁴. Nuevamente, es más probable que los adultos muestren una nota adhesiva a que levanten la mano y una vez que una nota color azul es levantada, generalmente le sigue una ráfaga de otras notas azules.

Para distribuir atención

También se pueden usar notas adhesivas para garantizar que tu atención como docente se distribuya de manera justa. Haz que cada estudiante escriba su nombre en una nota adhesiva y que lo coloque en su computadora portátil. Cada vez que alguien responda una de sus preguntas o que tú la/lo llames, quita su nota adhesiva. Una vez que hayas retirado todas las notas adhesivas, tus estudiantes vuelven a colocarlas en sus computadoras.

Esta técnica hace que sea fácil para la/el docente ver con quién no ha hablado recientemente, lo que a su vez ayuda a evitar prejuicios inconscientes e interactuar preferentemente con sus estudiantes más extrovertidos. Sin una verificación como esta, es muy fácil crear un ciclo de retroalimentación en el que quienes son más extrovertidas/os reciben más atención, por lo cual mejoran, lo que a su vez hace que reciban más atención, mientras que las/los estudiantes más introvertidas/os, menos seguras/os o marginadas/os se quedan detrás [Alvi1999,Juss2005].

También muestra a tus estudiantes que la atención se distribuye de manera justa, de modo que cuando se les llame, no se sentirán como si los estuvieran molestando. Cuando trabajo con un grupo nuevo, permito que las personas que prefieren no las llamen quiten sus propias notas adhesivas durante la primera o la segunda hora de clase. Si continúan haciendo esto a medida que pasa el tiempo, trato de tener una conversación tranquila para averiguar por qué y para ver si hay algo que pueda hacer para que se sientan más cómodas/os.

Como tarjetas de actas

También puedes usar notas adhesivas como tarjetas de actas. Antes de cada receso, tus estudiantes se toman un minuto para escribir en la nota adhesiva verde algo que creen que les será útil y en la nota naranja algo que consideran que se enseñó demasiado rápido o demasiado lento, que es confuso o irrelevante. Mientras disfrutan de su café o almuerzo, revisa sus notas y busca patrones. Se necesitan menos de cinco minutos para ver qué disfrutan las/los estudiantes de una clase de 40 personas, qué puntos hayan confusos, qué problemas tienen y qué preguntas aún no has respondido.

Las/Los estudiantes no deben firmar sus tarjetas de actas: están pensadas como comentarios anónimos. La técnica de uno arriba/uno abajo descrita en la Sección 9.11 es una oportunidad para la retroalimentación colectiva.

Nunca una página en blanco

Los talleres de programación y otros tipos de clases se pueden construir en torno a un conjunto de ejercicios independientes, pueden desarrollar un único ejemplo extendido en etapas o utilizar una estrategia mixta. Las dos ventajas principales de los ejercicios independientes son que las personas que se retrasan pueden volver a sincronizarse fácilmente y que quienes desarrollan las lecciones pueden agregar, eliminar y reorganizar el material a voluntad (Sección 6.3). Un único ejemplo extendido, por otro lado, mostrará a tus estudiantes cómo encajan las partes y piezas que están aprendiendo: en el lenguaje educativo, les brinda más oportunidades para integrar sus conocimientos.

Independientemente del enfoque que adoptes, las personas principiantes nunca deben comenzar a hacer ejercicios con una página o pantalla en blanco, ya que a menudo les resulta intimidante o desconcertante. Si te han seguido mientras realizas programación en vivo, pídeles que agreguen algunas líneas más o que modifiquen el ejemplo que creaste. Alternativamente, si están tomando notas compartidas, pega algunas líneas de código de inicio en el documento para que lo amplíen o modifiquen.

Modificar el código existente en lugar de escribir código nuevo desde cero no sólo proporciona a tus estudiantes una estructura: también está más cerca de lo que harán en la vida real. Sin embargo, ten en cuenta que las/los estudiantes pueden distraerse tratando de comprender todo el código de inicio en lugar de hacer su propio trabajo. El public static void main() de Java o un conjunto de sentencias import al inicio de un programa en Python podría tener sentido para ti, pero es una carga extrínsenca para una persona principiante (Capítulo 4).

Configuración del entorno de tus estudiantes

Las/Los estudiantes free-range a menudo quieren traer sus propias computadoras y dejar la clase con esas máquinas configuradas para hacer un trabajo real. Por lo tanto, las/los docentes free-range deberían prepararse para enseñar tanto en Windows como en MacOS ¹⁵, aunque sería más sencillo requerir que las/los estudiantes utilicen el mismo sistema operativo.

Denominadores comunes

Si tus participantes utilizan diferentes sistemas operativos, trata de evitar el uso de funciones que sean específicas de uno solo y señala las que sí utilices. Por ejemplo, los controles y el comportamiento de “minimizar ventana” en Windows son diferentes a los de MacOS.

No importa cuántas plataformas tengas que manejar, coloca instrucciones de configuración detalladas en el sitio web del curso y envía un correo electrónico a tus estudiantes un par de días antes de que comience el taller para recordarles que realicen la configuración. Algunas personas seguirán apareciendo sin el software requerido porque tuvieron problemas, no pudieron encontrar tiempo para completar todos los pasos o simplemente son el tipo de persona que nunca sigue las instrucciones por adelantado. Para detectar esto, haz que todos ejecuten un comando simple tan pronto como lleguen y muestren el resultado a las/los docentes, luego busca ayudantes y otras/os estudiantes para ayudar a las personas que se han encontrado con problemas.

Máquinas virtuales

Algunas personas usan herramientas como Docker para poner máquinas virtuales en las computadoras de sus estudiantes para que todos trabajen exactamente con las mismas herramientas, pero esto presenta un nuevo conjunto de problemas. Las máquinas más antiguas o más pequeñas simplemente no son lo suficientemente rápidas para ejecutarlas, las/los estudiantes luchan por alternar entre dos conjuntos diferentes de atajos de teclado para cosas como copiar y pegar, e incluso practicantes competentes se confundirán sobre qué está sucediendo exactamente y dónde.

La configuración es tan complicada que muchas/os docentes prefieren que se usen herramientas basadas en el navegador. Sin embargo, esto hace que la clase dependa del WiFi (que puede ser de calidad muy variable) y no satisface el deseo de las/los estudiantes de irse con sus propias máquinas listas para su uso en el mundo real. A la par que herramientas basadas en la nube como Glitch y RStudio Cloud se vuelven más robustas, esta última consideración se torna menos importante.

Una última forma de abordar los problemas de configuración es dividir la clase en varios días y hacer que las personas instalen lo que se requiere para cada día antes de dejar la clase el día anterior. Dividir el trabajo en partes hace que cada una sea menos intimidante, es más probable que las/los estudiantes realmente lo hagan y garantiza que puedas comenzar a tiempo cada lección, excepto la primera.

Otras prácticas de enseñanza

Las prácticas pequeñas que se describen a continuación no son esenciales, pero todas mejorarán la forma de dar las lecciones. Como ocurre con el ajedrez y el matrimonio, el éxito en la enseñanza suele ser una cuestión de progreso lento y constante.

Comienza con introducciones

Comienza tu clase presentándote. Si eres una persona experta, cuéntales un poco cómo llegaste a donde estás; si solo estás dos pasos por delante de ellos, enfatiza lo que tienes en común con ellas/os. Digas lo que digas, la meta es hacerte más accesible y fomentar la creencia de que pueden tener éxito.

Las/los estudiantes también deben presentarse. En una clase de una docena, pueden hacer esto verbalmente; en una clase más grande o si aún no se conocen entre sí, encuentro mejor que cada estudiante escriba una o dos líneas sobre sí mismos en las notas compartidas (Sección 9.7).

Configura tu propio entorno

Configurar tu entorno es tan importante como configurar el de tus estudiantes, pero más arduo. Además de contar con acceso a la red y de tener todo el software que vas a utilizar, también debes tener disponible un vaso de agua o una taza de té o café (o mate, o tereré). Esto ayuda a mantener tu garganta lubricada, pero el propósito real es darte una excusa para hacer una pausa y pensar durante un par de segundos cuando alguien te hace una pregunta difícil o cuando pierdes la noción de lo que ibas a decir a continuación. Probablemente también quieras algunos marcadores de pizarra y varias otras cosas que se describen en la Sección 21.3.

Una manera de evitar que tu trabajo diario se entrometa en tu manera de enseñar es creando una cuenta separada en tu computadora para tu rol docente. Usa valores predeterminados del sistema para todo lo referido a esta segunda cuenta, así como un tamaño de letra grande y un fondo de pantalla blanco, y silencia las notificaciones de manera que tus lecciones no sean interrumpidas por ventanas emergentes.

Evita dejar tarea para la casa

Las/Los estudiantes que hayan pasado todo un día programando estarán cansadas/os. Si les das tarea para hacer fuera del horario de clase, también comenzarán el día siguiente con cansancio, así que no lo hagas.

No toques el teclado de tu estudiante

A menudo es tentador arreglar las cosas para tus estudiantes, pero incluso si narras cada paso, es probable que las/los desmotives al enfatizar la brecha entre sus conocimientos y los tuyos. En su lugar, mantén tus manos fuera del teclado y habla con tus estudiantes sobre lo que tengan que hacer: llevará más tiempo, pero es más probable que el conocimiento se mantenga.

Repite la pregunta

Siempre que alguien haga una pregunta en clase, repítesela antes de responder para comprobar que la has entendido y para que las personas que quizás no la hayan escuchado tengan la oportunidad de hacerlo. Esto es particularmente importante cuando se graban o transmiten presentaciones, ya que tu micrófono generalmente no captará lo que otras personas están diciendo. Repetir las preguntas también te da la oportunidad de redirigir la pregunta a algo con lo que te sientas más cómoda/o respondiendo…

Uno arriba, uno abajo

Un complemento de las tarjetas de actas es solicitar retroalimentación resumida al final de cada día. Las/los estudiantes dan alternativamente un punto positivo o negativo sobre el día sin repetir nada de lo que ya se ha dicho. La prohibición de las repeticiones obliga a las personas a decir cosas que de otro modo no harían: una vez que se hayan dado todos los comentarios “seguros”, comenzarán a decir lo que realmente piensan.

Diferentes modos, diferentes respuestas

Las tarjetas de actas (Sección 9.8) son anónimas; la retroalimentación alterna de arriba a abajo no lo es. Debes usar los dos métodos juntos porque el anonimato permite tanto la honestidad como la ofensa.

Pide que tus estudiantes hagan predicciones

Las investigaciones han demostrado que las personas aprenden más de las demostraciones si se les pide que predigan lo que sucederá [Mill2013]. Esta actividad encaja naturalmente en la programación en vivo: después de agregar o cambiar algunas líneas de un programa, pregunta a la clase qué sucederá cuando se ejecute. Si el ejemplo es incluso moderadamente complejo, la predicción puede servir como una pregunta motivadora para una ronda de instrucción por pares.

Configuración de mesas

Es posible que no tengas ningún control sobre la distribución de los escritorios o mesas en la sala en la que enseñas, pero si lo tienes, hemos encontrado que es mejor tener asientos planos (estilo comedor) en lugar de asientos butacas (estilo teatro). De este modo puedes llegar a quienes necesitan ayuda más fácilmente y será más fácil para tus estudiantes emparejarse entre sí (Sección 9.5). Los tomacorrientes en el piso (para que no tengas que pasar cables de alimentación) hacen la vida más fácil y segura, pero siguen siendo poco comunes.

Independientemente del diseño de aula que tengas, trata de asegurarte de que cada asiento tenga una vista sin obstáculos de la pantalla. Un buen soporte para la espalda también es importante, ya que las personas estarán en ellos durante un período prolongado. Al igual que los tomacorrientes en el piso, los buenos asientos en el salón de clases aún son infrecuentes.

Pastillas para la tos

Si hablas todo el día en una habitación llena de gente, se te irritará la garganta porque estarás irritando las células epiteliales de la laringe y la faringe. Esto no solo vuelve tu voz ronca, sino que también te hace más vulnerable a las infecciones (que es parte de la razón por la que las personas a menudo se resfrían después de enseñar).

La mejor manera de protegerse contra esto es mantener la garganta lubricada: una buena recomendación es usar pastillas para la tos pronto y con frecuencia. Las buenas pastillas también disimularán la aparición del aliento a café, lo que tus estudiantes probablemente agradecerán.

Piensa, empareja, comparte

Piensa, empareja, comparte es una técnica ligera que ayuda a las personas a mejorar sus ideas mediante la discusión con sus pares. Cada persona comienza pensando individualmente sobre una pregunta o problema y anotando algunas notas. Luego, se explican las ideas por parejas, fusionándolas o seleccionando las más prometedoras. Finalmente, algunas parejas presentan sus ideas a todo el grupo. Piensa, empareja, comparte funciona porque obliga a las personas a exteriorizar su cognición (Sección 3.1). También les da la oportunidad de detectar y resolver brechas o contradicciones en sus ideas antes de exponerlas a un grupo más grande, lo que puede hacer que tus estudiantes menos extrovertidas/os tengan menos nervios de pasar el ridículo o equivocarse.

Mañana, mediodía y noche

[Smar2018] descubrieron que a las/los estudiantes les va peor si sus clases y otros trabajos se programan en horarios que no coinciden con sus relojes biológicos, es decir, que si una persona matutina toma clases nocturnas o viceversa, sus calificaciones se ven afectadas. Por lo general, no es posible acomodar esto en grupos pequeños, pero los grupos más grandes deben intentar escalonar las horas de inicio de las sesiones paralelas. Esto también puede ayudar a las personas que hacen malabarismos con las responsabilidades de cuidado de sus hijas/os, adultos mayores y otras limitaciones, además de que en los recreos las filas del café y los baños serán más cortas.

Humor

El humor debe usarse con moderación al enseñar: la mayoría de los chistes son menos divertidos cuando se escriben y se vuelven aún menos divertidos con cada relectura. Ser espontáneamente divertida/o mientras enseñas generalmente funciona mejor, pero puede salir mal fácilmente: lo que es una broma para tu círculo de amistades puede convertirse en un problema político serio para tu público. Si haces bromas cuando enseñas, no las hagas a expensas de ningún grupo o de ninguna persona excepto posiblemente de tú misma/o.

Limita la innovación

Cada una de las técnicas presentadas en este capítulo mejorará tus clases, pero no debes intentar adoptarlas todas a la vez. La razón es que cada nueva práctica aumenta tu carga cognitiva, así como la de tus estudiantes, ya que de golpe todas las personas estarán tratando de aprender una nueva forma de aprender, así como el tema de la lección. Si trabajas con un grupo repetidamente, puedes introducir una técnica nueva cada pocas lecciones; si solo enseñas un taller de un día, es mejor elegir un único método que no hayan visto antes y que se sientan cómodas/os con eso.

Ejercicios

Crea un cuestionario (individual/20’)

Utilizando el cuestionario de la Sección 21.5 como plantilla, crea un breve cuestionario que puedas entregar a tus estudiantes antes de impartir una clase propia. ¿Qué es lo que más deseas saber sobre sus antecedentes y cómo pueden ambas partes estar seguras de que están de acuerdo sobre qué nivel de comprensión se está preguntando?

Una práctica de enseñanza propia (pensar-emparejar-compartir/15’)

Piensa en una práctica de enseñanza que no se haya descripto hasta ahora. En parejas, presenta tu idea a tu compañera/o y escucha la suya. Luego, seleccionen una de las dos ideas para presentarla al grupo en general.

¿Puedo conducir? (parejas/10’)

Intercambia computadoras con una/un compañera/o (preferiblemente con alguien que use un sistema operativo diferente al tuyo) y trabaja en un simple ejercicio de programación. ¿Qué tan frustrante es? ¿Cuánta información te da sobre lo que las personas novatas tienen que pasar todo el tiempo?

Emparejar (parejas/15’)

Mira este video de programación en parejas y luego practica hacerlo con una/un compañera/o. Recuerda cambiar los roles entre conductor/a y navegante cada pocos minutos. ¿Cuánto tiempo tardas en adoptar un ritmo de trabajo?

Compara notas (grupos pequeños/15’)

Forma grupos de tres a cuatro personas y compara las notas que han tomado en este capítulo. ¿Qué te pareció digno de mención pero tus pares perdieron de vista y viceversa? ¿Qué entendiste diferente?

Credibilidad (individual/15’)

[Fink2013] describe tres cosas que hacen a las/los docentes creíbles a los ojos de sus estudiantes:

Competencia:

conocimiento del tema como lo demuestra la capacidad para explicar ideas complejas o hacer referencia al trabajo de otras personas.

Integridad:

tener en cuenta los mejores intereses de las/los estudiantes. Esto se puede demostrar dando retroalimentación individualizada, ofreciendo una explicación racional para las decisiones de calificación y tratando a todas las personas del curso por igual.

Dinamismo:

entusiasmo por el tema (Capítulo 8).

Describe una cosa que haces al enseñar que se ajuste a cada categoría y luego describe una cosa que no haces pero que deberías hacer.

Medir la eficacia (individual/15’)

[Kirk1994] define cuatro niveles en los cuales evaluar la formación:

Reacción:

¿Cómo se sintieron las/los estudiantes con respecto a la formación?

Aprendizaje:

¿Cuánto aprendieron realmente?

Comportamiento:

¿Cuánto han cambiado su comportamiento como resultado?

Resultados:

¿Cómo han afectado esos cambios de comportamiento su resultado o el resultado de su grupo?

¿Qué estás haciendo en cada nivel para evaluar qué y cómo enseñas? ¿Qué podrías hacer que no estés haciendo?

Objeciones y contraobjeciones (piensa-empareja-comparte/15’)

Has decidido no preguntar a tus estudiantes si tu clase fue útil porque sabes que no existe una correlación entre sus respuestas y cuánto aprenden realmente (Sección 7.1). En cambio, has presentado cuatro propuestas, cada una de las cuales tus colegas han rechazado:

Ver si recomiendan la clase a amigas/os.

¿Por qué esto sería más significativo que preguntarles cómo se sienten acerca de la clase?

Hacer un examen al final.

Pero cuánto saben los estudiantes al final del día es un mal predictor de cuánto recordarán dos o tres meses después, y cualquier tipo de examen final hará que la clase sea mucho más estresante.

Hacer un examen dos o tres meses después.

Eso es prácticamente imposible con estudiantes free-range. Además, es menos probable que participen del seguimiento aquellas personas que no obtuvieron nada del taller, por lo que habrá un sesgo en los comentarios recopilados.

Revisa si siguen usando lo que aprendieron.

La instalación de software espía en las computadoras de las/los estudiantes está mal vista, entonces, ¿cómo se implementará?

Trabajando por tu cuenta, encuentra respuestas a estas objeciones. Luego, comparte tus respuestas con una/un compañera/o y discutan los enfoques a los que han llegado. Cuando hayan terminado, compartan su aproximación favorita con la clase.

Motivación y desmotivación

Los/las estudiantes necesitan ánimo para enfrentar terreno desconocido, así que este capítulo analiza maneras en las que el cuerpo docente puede motivarlos/las. Y más importante, el capítulo habla de cómo los/las docentes pueden desmotivarlos/as y cómo evitarlo.

Nuestro punto de partida es la diferencia entre motivación extrínseca, lo que sentimos cuando hacemos algo para evitar un castigo o ganarnos una recompensa, y motivación intrínseca, lo que sentimos cuando conseguimos algo que nos satisface personalmente. Ambos tipos de motivación nos afectan en la mayoría de las situaciones—por ejemplo, las personas enseñan porque les gusta y porque les pagan—; pero aprendemos mejor cuando estamos motivados/as intrínsecamente[Wlod2017]. De acuerdo a la teoría de la autodeterminación, los tres impulsores de motivación intrínseca son:

Competencia:

la sensación de que sabes lo que haces.

Autonomía:

la sensación de estar en control de tu propio destino.

Relación:

la sensación de estar conectado/a con las demás personas.

Una lección bien diseñada fomenta estos tres impulsores. Por ejemplo, un ejercicio de programación puede permitir que los/las estudiantes practiquen con las herramientas que necesitan usar para resolver un problema mayor (competencia), aborden las partes del problema en el orden que quieran (autonomía), y conversen con sus pares (relación).

El problema de las notas

Yo nunca he tenido un público en mi vida. Mi público es una rúbrica.
– citado por Matt Tierney

Las calificaciones y la forma en que distorsionan el aprendizaje se utilizan con frecuencia como ejemplo de motivación extrínseca, pero como observa [Mill2016a], no van a desaparecer en el corto plazo, así que no tiene sentido intentar construir un sistema que las ignore. En lugar de eso, [Lang2013] explora cómo los cursos que enfatizan las calificaciones pueden incentivar a que los/las estudiantes hagan trampa y ofrece algunos consejos de cómo disminuir este efecto, mientras [Covi2017] observa el problema más grande de balancear la motivación intrínseca y extrínseca en la educación institucional, y el enfoque de alineación constructiva defendido en [Bigg2011] busca armonizar las actividades de aprendizaje con los resultados del aprendizaje.

[Ambr2010] contiene una lista de métodos basados en evidencia para motivar a los/las estudiantes. Ninguno es sorprendente, es difícil imaginar a alguien diciendo que no debemos identificar y recompensar lo que valoramos, pero es útil revisar lecciones para asegurarnos de que estén haciendo al menos algunas de estas cosas. Una estrategia en particular que me gusta es que los/las estudiantes que hayan luchado y tenido éxito se acerquen y cuenten sus historias al resto de la clase. Es más probable que tus estudiantes crean historias de personas parecidas a ellos/as [Mill2016a] y, además, quienes ya han pasado por tu curso siempre tendrán consejos en los que nunca hubieras pensado.

No solo para estudiantes

Las discusiones sobre motivación en educación con frecuencia pasan por alto la necesidad de motivar al docente. Los/las estudiantes responden al entusiasmo de su docente, y los/las docentes (particularmente si el trabajo es voluntario) necesitan valorar un tema para seguir enseñándolo. Esta es otra razón poderosa para co-enseñar (Sección 9.3): al igual que tener a alguien que te acompañe a correr hace que sea más probable que sigas corriendo, tener una persona con quien enseñar ayuda a ponerte en marcha esos días que tienes gripe y la lámpara del proyector se ha roto y nadie sabe donde conseguir un reemplazo y, ¿de verdad están construyendo otra vez?

Los/las docentes también pueden hacer otras cosas positivas. [Bark2014] registró tres cosas que impulsaron la retención para todos los/las estudiantes: tareas significativas, interacción del cuerpo docente con los/las estudiantes y colaboración entre estudiantes en las tareas. El ritmo y la carga de trabajo relativo a las expectativas también fueron impulsores significativos, pero principalmente para estudiantes varones. Las cuestiones que no impulsaron la retención fueron: interactuar con asistentes de la clase e interactuar con compañeros/as en actividades extracurriculares. Estos resultados parecen obvios, pero lo contrario también parecería obvio: si el estudio hubiera concluido que compartir actividades extracurriculares impulsa la retención, también pensaríamos que tiene sentido. Notablemente, replicar en línea a dos de los cuatro impulsores de retención (interacción con el cuerpo docente y colaboración entre estudiantes) toma un esfuerzo adicional (Capítulo 11).

Tareas auténticas

Como Dylan Wiliam menciona en [Hend2017], la motivación no siempre conduce al logro pero el logro casi siempre conduce a la motivación: el éxito de los/las estudiantes les motiva mucho más a que les digan lo geniales que son. Podemos usar esta idea en la docencia creando una cuadrícula cuyos ejes son “tiempo medio para dominar” y “utilidad una vez dominado” (Figura 10.1).

Las cosas que se dominan rápido y son útiles de inmediato se deben enseñar primero, incluso si no se consideran fundamentales para personas que ya son practicantes competentes, porque unas pocas victorias iniciales fortalecerán la confianza de tus estudiantes en sí mismos/as y en su docente. Por el contrario. aquellas cosas que son difíciles de aprender y no son útiles a tus estudiantes en su etapa actual de desarrollo deben omitirse por completo, mientras que los temas en la diagonal se deben sopesar entre sí.

¿Útil para quién?

Si alguien quiere construir sitios web, conceptos de ciencia de computación fundamentales como recursión y computabilidad pueden habitar la esquina inferior derecha de esta cuadrícula. Eso no quiere decir que no vale la pena aprenderlos, pero si nuestro objetivo es motivar a las personas, pueden y deben ser enseñados diferidos. Por lo contrario, un/a estudiante de último año tomando un clase de programación para estimular su mente puede preferir explorar estas grandes ideas en vez de hacer algo práctico. Cuando estás creando tu cuadrícula, deberías hacerlo con tus personas tipo en mente (Section 6.1) Si los temas se ordenan en lugares muy diferentes para diferentes personas tipo, deberías pensar en crear cursos diferentes.

Un ejemplo bien estudiado de priorizar lo que es útil sin sacrificar lo que es fundamental es el enfoque de computación de medios desarrollado en Georgia Tech [Guzd2013]. En vez de imprimir “hola mundo” o sumar los primeros diez enteros, el primer programa de un/a estudiante podría ser abrir una imagen, cambiarle el tamaño para crear una versión miniatura y guardar el resultado. Esta es una tarea auténtica; es decir, algo que los/las estudiantes creen que harían en la vida real. También tiene un artefacto tangible: si la imagen sale del tamaño incorrecto, los/las estudiantes tienen algo a mano que puede guiar su depuración. [Lee2013] describe una adaptación de este enfoque de Python a MATLAB, mientras que otras personas están construyendo cursos similares acerca de ciencia de datos, procesamiento de imágenes y biología [Dahl2018,Meys2018,Ritz2018]

Siempre habrá tensión entre darle a tus estudiantes problemas auténticos y ejercitar las habilidades individuales que requieren para resolver esos problemas: al fin y al cabo, los/las programadores no contestan preguntas de opción múltiple en el trabajo como tampoco los/las músicos/as tocan escalas una y otra vez en frente de un público. Conseguir el balance es difícil, pero un primer paso es eliminar cualquier cosa arbitraria o sin sentido. Por ejemplo, los ejemplos de programación no deben utilizar variables llamadas foo y bar, y si vas a hacer que tus estudiantes ordenen una lista, haz una lista de canciones en vez de cadenas de caracteres como “aaa” y “bbb”.

Desmotivación

Las mujeres no abandonan la computación porque no saben cómo es; se van porque sí saben.
— atribuido a varias personas

Si enseñas en un ambiente free-range probablemente tus estudiantes son voluntarios/as y probablemente quieren estar en tu clase. Por lo tanto, motivarlos/as es menos preocupante que desmotivarlos/as. Desafortunadamente, es fácil desmotivar a las personas accidentalmente. Por ejemplo, [Cher2009] reportaron cuatro estudios mostrando que hay pistas ambientales sutiles con una diferencia medible en el interés que las personas de diferentes géneros tienen en la computación: cambiar los objetos en un aula de ciencias de la computación de aquellos considerados estereotipados de ciencias de la computación (p.ej. afiches y videojuegos de Star Trek) a objetos no considerados estereotipados (p.ej. afiches de la naturaleza y guías telefónicas) impulsó el interés de estudiantes universitarias al nivel de sus pares masculinos. De manera similar, [Gauc2011] reporta tres de estudios que muestran que la redacción de género comúnmente empleada en materiales de contratación laboral puede mantener desigualdad de género en ocupaciones tradicionalmente dominadas por hombres.

Hay tres desmotivadores principales para estudiantes adultos/as:

Imprevisibilidad:

desmotiva a las personas porque si no hay una conexión confiable entre lo que hacen y el resultado que logran, no hay razón para que intenten hacer nada.

Indiferencia:

desmotiva porque los/las estudiantes que creen que el/la docente o el sistema educativo no se preocupan por ellos/as, no se van a preocupar por aprender la clase.

Injusticia:

desmotiva a las personas desfavorecidas por razones obvias. Lo sorprendente es que también desmotiva a las personas que se benefician de la injusticia: consciente o inconscientemente, les preocupa que algun dia se encuentren en el grupo desfavorecido [Wilk2011].

En situaciones extremas, los/las estudiantes pueden desarrollar indefensión aprendida: si están repetidamente sometidos/as a comentarios negativos en una situación que no pueden cambiar, pueden aprender a ni siquiera intentar cambiar aquello que sí podrían.

Una de las maneras más rápidas y seguras de desmotivar estudiantes es usar un lenguaje que sugiera que algunas personas son programadoras naturales y otras no. Guzdial lo ha llamado el mito más grande de enseñar ciencias de la computación, y [Pati2016] respaldó esto mostrando que la gente ve evidencia de un “gen geek” donde no existe uno. Analizaron distribuciones de calificaciones de 778 cursos universitarios y encontraron que solo 5,8% mostraba signos de ser multimodal, es decir, solo una clase de veinte mostró signos de tener dos poblaciones distintas de estudiantes. Luego le mostraron a 53 profesores/as de ciencias de la computación histogramas de distribuciones ambiguas de calificaciones; aquellos/as que creían que algunas personas tienen una predisposición innata a ser mejores en las ciencias de la computación eran más propensos/as de verlas como bimodal que aquellos/as que no.

Estas creencias son importantes porque los/las docentes actúan sobre ellas [Brop1983]. Si un/a docente cree que es probable que a un/a estudiante le vaya bien naturalmente (a menudo inconscientemente) se enfoca en ese/a estudiante, que luego cumple con las expectativas debido a la mayor atención, lo que a su vez parece confirmar la creencia del docente. Lamentablemente, hay pocas señales de que la mera evidencia del tipo presentado en [Pati2016] es suficiente para romper este círculo vicioso…

Aquí hay algunas otras cosas específicas que desmotivarán a tus estudiantes:

Una actitud de superioridad moral o desdeñosa

de un/una docente o un/una compañero/a estudiante.

Decirles que sus habilidades existentes son tonterías.

Las personas que son usuarias de Unix se burlan de las que usan Windows, los/las programadores/as de todo tipo hacen chistes sobre Excel y sin importar qué entorno de desarrollo de aplicación web conoces, algún/a programador/a te dirá que está desactualizado. Seguramente, tus estudiantes invirtieron mucho tiempo y esfuerzo para adquirir las habilidades que tienen; menospreciarlas es una buena manera de garantizar que no escucharán nada más de lo que tengas que decir.

Sumergirse en discusiones técnicas complejas o detalladas

con los estudiantes más avanzados de la clase.

Fingir que sabes más de lo que sabes.

Los/las estudiantes confiarán más en ti si hablas con franqueza de los límites de tu conocimiento y será más probable que hagan preguntas y pidan ayuda.

Usar la letra S (“solo”) o fingiendo sorpresa.

Como se discutió en el Capítulo 3, decir cosas como “no puedo creer que no sabes X” o “¿nunca has oído de Y?” le señala a tus estudiantes que piensas que su problema es trivial y que deben ser estúpidos/as por no poder resolverlo.

Dolores de cabeza de instalación de software.

El primer contacto de las personas con programación o con herramientas nuevas de programación suele a ser desmoralizador y creer que algo es difícil de aprender es una profecía autocumplida. No es solamente el tiempo que toma en configurar o el sentimiento de que es injusto tener que depurar algo que depende del conocimiento que aún no tienen. El problema real es que con cada falla refuerzan su creencia de que tendrán una mejor chance de cumplir con la fecha límite del próximo jueves si siguen haciendo las cosas como siempre las han hecho.

Es incluso más fácil desmotivar a las personas en línea que en persona, pero ahora hay estrategias basadas en evidencia para lidiar con esto. [Ford2016] encontraron que las siguientes cinco barreras para contribuir en Stack Overflow sos consideradas significativamente más problemáticas por las mujeres que por los hombres: falta de conocimiento de las características del sitio, sentirse incapaz de contestar preguntas, una comunidad de tamaño intimidante, malestar interactuando con personas extrañas o dependiendo de ellas, y la sensación de que buscar cosas en línea no es “trabajo real.” El miedo de comentarios negativos no llegó a esta lista, pero de seguro sería la próxima razón agregada, si los autores de la investigación no fueran tan estrictos con sus límites estadísticos. Todos estos factores pueden y deben abordarse tanto en persona como en línea usando métodos como los de la Sección 10.4, y hacerlo mejora los resultados para todas las personas [Sved2016].

Falla productiva y privilegio

Algunos trabajos recientes han explorado la falla productiva: deliberadamente se les da a estudiantes problemas que no pueden ser resueltos con el conocimiento que tienen, por lo que deben explorar y adquirir información nueva para poder avanzar [Kapu2016]. La falla productiva recuerda superficialmente al mantra del sector tecnológico “fracasa rápido, fracasa con frecuencia” pero este último es más un indicador de privilegio que de comprensión. Las personas solo pueden darse el lujo de celebrar el fracaso si es seguro que tendrán una oportunidad de volver a intentarlo; muchos de tus estudiantes, y muchas personas de grupos marginados o desfavorecidos, no pueden estar seguros/as de esto, y asumir que la falla es una opción es una buena manera de desmotivarlos/as.

Síndrome del impostor/a

El síndrome del impostor/a es la creencia de que tus logros son producto de la casualidad o la suerte y viene con el miedo de que alguien finalmente se dará cuenta. Es muy común entre personas triunfadoras que realizan un trabajo visible públicamente, pero afecta de manera desproporcionada a miembros de grupos subrepresentados: como se discutió en la Sección 7.1, [Wilc2018] encontró que las estudiantes mujeres expuestas previamente a la computación superaron a sus compañeros en todas las áreas en los cursos de introducción a la programación pero constantemente tenían menos confianza en sus habilidades, en parte porque la sociedad sigue señalando en maneras sutiles y no tan sutiles que realmente no pertenecen al mundo de la computación.

Las aulas tradicionales pueden alimentar al síndrome del impostor/a. Las tareas escolares se realizan con frecuencia de manera individual o en grupos pequeños, pero los resultados se comparten y critican públicamente. Como resultado, raramente vemos cómo el resto lucha por resolver y terminar su trabajo, lo que puede alimentar la creencia de que la tarea es fácil para todas las otras personas. Las personas que pertenencen a grupos subrepresentados que ya sienten una presión adicional para demostrar su valía pueden ser particularmente afectadas.

La iniciativa Ada (Ada Initiative) ha creado unas guías para luchar con tu propio síndrome del impostor/a, que incluyen:

Habla del problema con personas de tu confianza.

Cuando escuchas de otras personas que el síndrome del impostor/a es un problema común, se vuelve más difícil creer que tus sentimientos de fraude son reales.

Ve a una sesión en persona sobre el síndrome del impostor/a.

No hay nada como estar en un salón lleno de personas que respetas y descubrir que el 90% de ellas tienen síndrome del impostor/a.

Cuida tus palabras, porque influyen tu forma de pensar.

Decir cosas como, “No soy experto/a en esto, pero…” resta valor del conocimiento que realmente posees.

Enseña a otras personas de tu campo.

Ganarás confianza en tu propio conocimiento y habilidad y ayudarás a otros a evitar parte del síndrome del impostor/a en multitudes.

Haz preguntas.

Hacer preguntas puede ser intimidante si piensas que debes saber la respuesta, pero obtener respuestas elimina la prolongada agonía de la incertidumbre y el miedo al fracaso.

Construye alianzas.

Tranquiliza y fortalece a tus amistades, quienes te reconfortan y fortalecen. (y si no lo hacen, tal vez quieras pensar en conseguir amistades nuevas…)

Sé dueño/a de tus logros.

Sigue registrando y revisando activamente lo que has hecho, lo que has construido, y los éxitos que has tenido.

Como docente, puedes ayudar a las personas con su síndrome del impostor/a compartiendo relatos de errores que has cometido o de cosas que te costaron aprender. Esto le asegura a la clase que está bien encontrar que algunos temas son difíciles. Ser abierto/a con el grupo también genera confianza y les da confianza para hacer preguntas. (La programación en vivo es excelente para esto: como se indicó en la Sección 8.1, tus errores tipográficos le muestran a tu clase que eres un ser humano.) Las evaluaciones formativas frecuentes también ayudan, en particular si tus estudiantes te ven ajustando tanto lo que enseñas como tu velocidad en base a sus resultados.

Mentalidad y amenaza de estereotipo

Carol Dweck y otros han estudiado las diferencias de la mentalidad fija y la mentalidad de crecimiento en resultados de aprendizaje. Si la gente cree que la competencia en alguna área es intrínseca (es decir, que tienes “el gen” para ella o no), a todos/as les va peor, incluyendo a quienes supuestamente están en ventaja. La razón es que si a alguien no le va bien al principio, asume que les falta esa aptitud, lo que predispone su rendimiento en el futuro. Por otro lado, si la gente cree que una habilidad se aprende y se puede mejorar, en promedio, les irá mejor.

Se cuestiona que la mentalidad del crecimiento ha sido sobredimensionada, o que traducir las investigaciones al respecto a la práctica es mucho más difícil de lo que sus defensores más entusiastas han insinuado [Sisk2018]. Sin embargo, sí parece que los/las estudiantes de un nivel socioeconómico bajo o que están en riesgo académico podrían beneficiarse de las intervenciones de mentalidad de crecimiento.

Otro efecto discutido ampliamente es la amenaza de estereotipo [Stee2011]. Recordar a las personas de estereotipos negativos, incluso en formas sutiles, puede hacerlas sentirse ansiosas por el riesgo de confirmar esos estereotipos, lo que a su vez puede reducir su rendimiento. Otra vez, hay preocupación sobre la replicabilidad de los estudios claves, y el problema se complica aún más por el hecho de que el término se ha utilizado de muchas formas [Shap2007], pero nadie argumentaría que mencionar estereotipos en clase ayudaría a los/las estudiantes.

Accesibilidad

Colocar las lecciones y los ejercicios fuera del alcance de alguien es tan desmotivador como parece, y es muy fácil hacerlo sin darse cuenta. Por ejemplo, las primeras lecciones de programación en línea que escribí tenían una transcripción de la narración al lado de las diapositivas, pero no incluían el código fuente: eso estaba en capturas de pantalla de diapositivas de PowerPoint. Alguien utilizando un lector de pantalla podía entonces oír lo que se decía sobre el programa, pero no sabía qué era realmente el programa. No siempre es factible adaptarse a las necesidades de cada estudiante, pero agregar títulos de descripción a las imágenes y hacer que los controles de navegación sean accesible a personas que no pueden usar el mouse puede hacer una gran diferencia.

Rampas en las veredas

Hacer que el material sea accesible ayuda a todas las personas, no solamente a las personas con dificultades. Las rampas—los pequeños planos inclinados que unen una acera a la calle— fueron creados originalmente para facilitar el movimiento de personas con discapacidad física, pero resultaron ser igual de útiles para personas con cochecitos y carritos de supermercado. De forma similar, subtitular imágenes no solamente ayuda a las personas con discapacidad visual: también hace que las imágenes sean más fáciles de encontrar e indexar para los motores de búsqueda.

El primer paso y el más importante para hacer lecciones accesibles es involucrar a las personas con discapacidades en el proceso de toma de decisiones: el eslogan nihil de nobis, sine nobis (literalmente, “nada sobre nosotros sin nosotros”) precede a los derechos de accesibilidad, pero siempre es un punto adecuado de partida. Algunas recomendaciones específicas son:

Descubre lo que debes hacer.

Cada uno de estos afiches ofrece lo que debe y no debe hacerse para personas con autismo, usuarios/as de lectores de pantalla, y personas con baja visión, discapacidades físicas o motoras, ejercicios de escucha y dislexia.

No hagas todo a la vez.

Las mejoras descriptas en el punto anterior pueden parecer bastante abrumadoras, así que haz un cambio a la vez.

Primero haz las cosas fáciles.

El tamaño de fuente, usar un micrófono de clip para que las personas te puedan oír más fácilmente, y revisar tu selección de colores, son buenos puntos de partida.

Revisa qué tan bien lo estás haciendo.

Sitios como WebAIM permiten que revises qué tan accesibles son tus materiales en línea para usuarios/as con discapacidad visual.

[Coom2012,Burg2015] son buenas guías de diseño visual para la accesibilidad. Sus recomendaciones incluyen:

Asigna formato a tus documentos con encabezados reales y otros puntos de referencias

en vez de simplemente cambiar los tamaños y estilos de fuente.

Evita usar solamente el color para transmitir significado en texto o gráficos.

En su lugar, use el color en combinación con diferentes patrones de rayado cruzado (que también hace que el material sea comprensible cuando se imprime en blanco y negro).

Elimina elementos innecesarios

en lugar de hacerlos invisibles, porque los lectores de pantalla los leerán igualmente.

Permite el propio-ritmo y la repetición

para las personas con problemas de lectura o audición.

Incluye narración de la acción de pantalla en los videos

(y habla mientras escribes cuando programas en vivo).

Cucharas

En el 2003, Christine Miserandino comenzó a usar las cucharas como una forma de explicar cómo es vivir con una enfermedad crónica. Las personas sanas comienzan cada día con una cantidad ilimitada de cucharas, pero aquellas con lupus u otras condiciones debilitantes solo tienen unas pocas, y cada cosa que hacen les cuesta una. ¿Levantarse de la cama? Esa es una cuchara. ¿Preparar una comida? Esa es otra cuchara, y pronto se te acaban.

No puedes ni siquiera ponerte la ropa cuando estás enfermo/a… si ese día mis manos duelen, los botones están fuera de discusión. Si tengo moretones, necesito usar mangas largas, y si tengo fiebre necesito un abrigo para mantenerme abrigado/a, y así sucesivamente. Si se me cae el cabello necesito pasar más tiempo para lucir presentable, y luego tienes que tomar en cuenta otros 5 minutos por sentirme mal de que te tomó 2 horas hacer todo esto.

Como Elizabeth Patitsas ha argumentado, las personas que tienen muchas cucharas pueden acumular más, pero las personas cuya cantidad es limitada pueden tener dificultades para salir adelante. Al diseñar clases y ejercicios, recuerda que algunos/as de tus estudiantes pueden tener obstáculos físicos o mentales que no son obvios. En caso de duda, pregunta: es casi seguro que tengan más experiencia con lo que funciona y lo que no que cualquier otra persona.

Inclusión

La inclusión es una política para incluir a las personas que de otro modo pueden quedar excluidas o marginadas. En la computación, requiere hacer un esfuerzo positivo para tratar mejor y generar un ambiente amigable y seguro para las mujeres, grupos raciales o étnicos subrepresentados, personas con diversas orientaciones sexuales, ancianos/as, personas con dificultades físicas, personas que estuvieron encarceladas, los/las desfavorecidos/as económicamente, y todas las demás personas que no encajen en el grupo demográfico de hombres blancos/asiáticos prósperos de Silicon Valley. Figura 10.2 (de NPR) ilustra gráficamente los efectos de la cultura excluyente hacia las mujeres en la computación.

[Lee2017] es una guía breve y práctica de cómo hacer esto con referencias a la literatura de investigación. Las prácticas que describe ayudan a estudiantes que pertenecen a uno o más grupos marginados o excluidos, pero también ayudan a motivar a todas las demás personas. Están redactadas en términos de cursos a largo plazo, pero muchas pueden ser aplicadas en talleres y otros ambientes free-range:

Pide a tus estudiantes que te envíen un correo electrónico antes del taller

para explicar cómo creen que el entrenamiento puede ayudar a que logren sus metas.

Revisa tus notas

para, por ejemplo, asegurarte de que sean libres de pronombres y marcas de género e incluyan nombres diversos culturalmente.

Enfatiza que lo que importa es la velocidad a la que están aprendiendo,

no las ventajas o desventajas que tenían cuando comenzaron.

Fomenta la programación en pareja,

pero demuéstralo primero para que los/las estudiantes entiendan las funciones de quien conduce y quien navega.

Mitiga activamente el comportamiento que puede resultar intimidante para algunos/as estudiantes

por ejemplo el uso de jerga o “preguntas” que se hacen para mostrar conocimiento.

Una forma de apoyar a estudiantes de grupos marginados es que las personas se inscriban en los talleres en grupos en lugar de individualmente. De esa manera, todas las personas de la sala saben por adelantado que estarán con personas en las que confían, lo que aumenta la probabilidad de que realmente vengan. También ayuda después del taller: si las personas vienen con sus amistades o colegas, pueden trabajar en conjunto para utilizar lo que aprendieron.

Lo más fundamental es que quienes diseñen lecciones consideren la situación completa de cada persona. Por ejemplo, [DiSa2014a] encontró que el 65% de los hombres afroamericanos en un programa de prueba de juegos estudiaron computación, en parte porque el aspecto de juego del programa era algo que sus compañeros respetaban. [Lach2018] exploró dos estrategias generales para crear contenido inclusivo y los riesgos asociados con ellas:

Representación comunitaria:

resalta las identidades sociales, las historias y las redes comunitarias de los/las estudiantes utilizando mentores/as extracurriculares o modelos a seguir de sus vecindarios, o actividades que utilizan narrativas e historias comunitarias como base para un proyecto de computación. El riesgo más grande de este enfoque es la poca profundidad, p.ej. utilizar computadoras para construir presentaciones con diapositivas en lugar de hacer cualquier actividad real de computación.

Integración computacional:

incorpora ideas de la comunidad de los/las estudiantes, tales como reproducir diseños de gráficos de pueblos originarios en un ambiente de programación visual. El riesgo más grande aquí es la apropiación cultural, p.ej. utilizar prácticas sin reconocer los orígenes.

En caso de duda, pregunta a tus estudiantes e integrantes de la comunidad qué creen que deberías hacer. Volvemos a esto en el Capítulo 13.

El Código de Conducta como accesibilidad

Dijimos en la Sección 9.1 que las clases deberían hacer cumplir un Código de Conducta como el del Anexo 17. Esta es una forma de accesibilidad: mientras que los subtítulos hacen que el video sea accesible a personas con discapacidades auditivas, un Código de Conducta hace que las lecciones sean accesibles a personas que de otro modo serían marginadas.

Pasando el modelo del déficit

Dependiendo a quién le creas, solo entre el 12 y 18% de las personas que obtienen un título en ciencias de la computación son mujeres. Esta cifra es menos de la mitad del porcentaje observado a mediados de la década de 1980 (Figura 10.3, de [Robe2017]). Los países occidentales son los únicos que tienen un porcentaje tan bajo de mujeres en computación; las mujeres siguen siendo a menudo entre el 30 y el 40% de las estudiantes de ciencias de la computación en el resto del mundo [Galp2002,Varm2015].

Dado que es poco probable que las mujeres hayan cambiado drásticamente en los últimos 30 años, tenemos que buscar causas estructurales para comprender qué salió mal y cómo solucionarlo. Una explicación es la manera en que las computadoras domésticas se comercializaron como “juguetes para niños” a partir de la década de 1980 [Marg2003]; otra es la manera en la que los departamentos de ciencias de la computación respondieron al crecimiento explosivo de la matrícula en la década de 1980 y nuevamente en la de 2000 cambiando los requisitos de admisión [Robe2017]. Ninguno de estos factores puede parecer dramático para las personas que se ven afectadas por ellos, pero actúan como el goteo constante del agua sobre una piedra: a medida que pasa el tiempo, erosionan la motivación y, con ella, la participación.

El primer paso y el más importante para solucionar esto es dejar de pensar en términos de una “tubería con fugas” [Mill2015]. Más generalmente, tenemos que superar el modelo deficitario, es decir, dejar de pensar que las personas que son parte de un grupo subrepresentado carecen de algo y por lo tanto son responsables de no salir adelante. Creer esto coloca la carga en las personas que ya tienen que hacer un trabajo adicional para superar las desigualdades estructurales y (no por casualidad) da a quienes se benefician de los acuerdos actuales una excusa para no mirarse con mucho cuidado.

Reescritura de la historia

[Abba2012] describe las carreras y logros de las mujeres que le dieron forma a la historia temprana de la computación, pero que con demasiada frecuencia han sido eliminadas de ella; [Ensm2003,Ensm2012] describe cómo la programación pasó de ser una profesión femenina a una masculina en la década de 1960, mientras [Hick2018] examina cómo Gran Bretaña perdió su dominio inicial en la computación discriminando sistemáticamente en contra de sus trabajadores más cualificados: las mujeres. (Mira [Milt2018] para obtener una reseña de los tres libros.) Hablar de esta historia hace que algunos hombres en computación se sientan incómodos; en mi opinión, esa es una buena razón para hacerlo.

La misoginia en los videojuegos, el uso de “encaje cultural” en la contratación para excusar prejuicios conscientes o inconscientes, una cultura de silencio en torno al acoso y la creciente desigualdad en la sociedad que produce privilegios preparatorios (Sección 9.5) no son culpa de una persona en particular, pero solucionarlos es responsabilidad de todos/as. Como docente, tienes más poder que la mayoría; este taller tiene excelentes consejos prácticos sobre cómo ser un/a buen/a aliado/a, y su consejo probablemente es más importante que cualquier cosa que te enseñe este libro sobre la enseñanza.

Ejercicios

Tareas auténticas (parejas/15’)

1. En pares, enumeren media docena de cosas que hicieron esta semana que utilizan las habilidades que enseñan.

2. Coloquen sus artículos en una cuadrícula de 2x2 de “tiempo para dominar” y “utilidad”. ¿En qué están de acuerdo y en qué en desacuerdo?

Necesidades básicas (toda la clase/10’)

Paloma Medina identifica seis necesidades básicas para las personas en el trabajo: pertenencia, progreso, elección, igualdad, previsibilidad y significado. Luego de leer las descripciones de cada una, ordénalas de mayor a menor importancia para ti personalmente, luego compara la clasificación con tus pares. ¿Cómo crees que tu clasificación se compara con la de tus estudiantes?

Implementa una estrategia para la inclusión (individual/5’)

Escoje una actividad o cambio en práctica de [Lee2017] en la que te gustaría trabajar. Pon un recordatorio en tu calendario de aquí a tres meses para preguntarte si has hecho algo al respecto.

Después de los hechos (piensa-empareja-comparte/20’)

1. Piensa en un curso que has tomado en el pasado e identifica una cosa que el/la docente hizo que te desmotivó. Toma notas de lo que se pudo hacer después para corregir la situación.

2. Emparéjate con tu vecino y compara las historias, y luego agrega tus comentarios a un conjunto de notas compartidas por toda la clase.

3. Revisa los comentarios en el conjunto de notas como grupo. Resalta y analiza algunas de las cosas que podrían haberse hecho de manera diferente.

4. ¿Crees que hacer esto te ayudará a manejar situaciones parecidas en el futuro?

Camina la ruta (toda la clase/15’)

Encuentra el punto de partida de transporte público más cercano a tu edificio y camina desde allí a tu oficina y luego al baño más cercano, toma notas de las cosas que crees que serían difíciles para alguien con dificultades de movilidad. Ahora toma prestada una silla de ruedas. ¿Qué tan completa fue tu lista de ejercicios? ¿Y te diste cuenta que la primera oración de este ejercicio asumía que podías caminar?

¿Quién decide? (toda la clase/15’)

En [Litt2004], Kenneth Wesson escribió, “Si los/las niños/as de los barrios marginales pobres superaran sistemáticamente a los/as niños/as de hogares suburbanos ricos en las pruebas estandarizadas, ¿alguien es lo suficientemente ingenuo como para creer que todavía insistiríamos en usar estas pruebas como indicadores de éxito?” Lee este artículo de Cameron Cottrill y luego describe un ejemplo de tu propia experiencia de evaluaciones “objetivas” que reforzaron el status quo.

Estereotipos comunes (parejas/10’)

Algunas personas todavía dicen “Es tan simple que incluso tu abuela podría usarlo.” En parejas, enumeren otras dos o tres frases que refuerzan estereotipos sobre la computación.

No ser un idiota (individual/15’)

Este artículo corto de Gary Bernhardt reescribe un mensaje innecesariamente hostil para ser menos grosero. Utilizándolo como un modelo, encuentra algo desagradable en Stack Overflow o en algún otro foro público de discusión. y reescríbelo para que sea más inclusivo.

Salvar las apariencias (individual/10’)

¿Alguno de tus posibles estudiantes se avergonzaría de admitir que todavía no saben algunas de las cosas que quieres enseñar? Si es así, ¿cómo puedes ayudarles a salvar las apariencias?

Juguetes infantiles (toda la clase/15’)

[Cutt2017] encuestó a usuarios/as adultos/as de computadoras acerca de sus actividades infantiles. Encontró que la correlación más fuerte entre la confianza y el uso de la computadora se basaba en leer por uno/a mismo/a y jugar con juguetes de construcción como Lego que no tienen partes móviles. Se realiza una encuesta a la clase para observar en qué otras actividades participan las personas. Luego, se buscan estas actividades en línea. ¿Qué tan sesgadas con respecto al género son las descripciones y las propagandas para ellas?“‘ ¿Qué efecto crees que tiene esto?

Accesibilidad de la lección (parejas/30’)

En parejas, escojan una lección cuyos materiales están disponibles en línea e independientemente asignen un puntaje a esos materiales de acuerdo a lo que se debe y no se debe hacer según estos afiches. ¿En qué estuvieron de acuerdo tu pareja y tú? ¿En qué estuvieron en desacuerdo? ¿Qué tan bien fue la lección para cada una de las seis categorías de usuarios/as?

Siguiendo el ciclo (grupos pequeños/15’)

[Coco2018] sigue un patrón deprimentemente común en que las buenas intenciones se ven socavadas por el liderazgo de una organización que no está dispuesta a cambiar realmente. Trabajando en grupos de 4–6 personas, escriban textos o correos electrónicos breves que imaginas que cada una de las partes involucradas enviaría a la otra en cada etapa de este ciclo.

¿Qué es lo peor que podría pasar? (grupos pequeños/5’)

A través de los años, se me ha incendiado un proyector, una estudiante ha tenido un parto y una pelea entre estudiantes estalló en clase. Me he caído del escenario dos veces, me he quedado dormido en una de mis propias charlas, y he hecho muchos chistes que fracasaron. En grupos pequeños, hagan una lista de las peores cosas que les han pasado mientras enseñaban, y luego compártanla con la clase. Guarda la lista para recordarte más tarde que no importa qué tan mala sea la clase: al menos nada de eso sucedió.

Revisa

Enseñar en línea

Si usas robots para enseñar, les enseñas a las personas a ser robots.
— atribuido a varias personas

La tecnología ha cambiado la enseñanza y el aprendizaje muchas veces. Antes de que se introdujeran los pizarrones en las escuelas a principios del siglo XIX, no había forma de que las/los docentes compartieran un ejemplo improvisado, un diagrama o que trabajaran en un ejercicio con toda la clase a la vez. Barato, de confianza, fácil de usar y flexible, los pizarrones permitieron a las/los docentes hacer cosas rápidamente y a gran escala, que antes solo habían podido hacer lentamente y poco a poco. De forma similar, las cámaras de video portátiles revolucionaron el entrenamiento atlético; al igual que las grabadoras revolucionaron la enseñanza musical una década antes.

Muchas de las personas que introducen internet en las aulas no conocen esta historia y no se dan cuenta de que el suyo es solo el último de una larga serie de intentos de utilizar máquinas para enseñar [Watt2014]. Desde la imprenta, pasando por la radio y la televisión, a computadoras de escritorio y dispositivos móviles, cada nueva forma de compartir conocimientos ha producido una ola de optimistas agresivos que creen que la educación no funciona y que la tecnología puede arreglarlo.

Sin embargo, las/los defensoras/es más acérrimas/os de la tecnología de la educación a menudo han sabido menos sobre “educación” que sobre “tecnología”. Detrás de su retórica, muchas de estas personas han sido impulsadas más por la perspectiva de ganancias que por el deseo de empoderar a las/los estudiantes.

El debate actual a menudo se enturbia al confundir “en línea” con “automatizado”. Si se realiza bien, una docena de personas resolviendo un problema en un chat de video se siente como cualquier otra discusión en grupos pequeños. Por el contrario, un escuadrón de ayudantes de enseñanza que califican cientos de trabajos con una rúbrica inflexible bien podría ser una colección de scripts de Perl. Por lo tanto, este capítulo comienza con la instrucción en línea totalmente automatizada, usando videos grabados y ejercicios calificados automáticamente, y luego explora algunos modelos híbridos alternativos.

Cursos masivos en línea

El esfuerzo de más alto perfil para reinventar la educación usando internet son los cursos masivos en línea (en inglés Massive Open Online Course), o MOOC. El término fue inventado por David Cormier en 2008 para describir un curso organizado por George Siemens y Stephen Downes. Ese curso se basó en una visión conectivista del aprendizaje, que sostiene que el conocimiento se distribuye y el aprendizaje es el proceso de encontrar, crear y podar conexiones.

El término “MOOC” fue rápidamente cooptado por las/los creadores de cursos semejantes al modelo de disertación de un aula tradicional: una/un docente como el centro definiendo los objetivos y estudiantes que se conciben como recipientes o replicadores de conocimientos. Las clases que utilizan el modelo conectivista original se suelen denominar “cMOOCs,” mientras que las clases que centralizan el control se llaman “xMOOCs.” (A este último también se le llama a veces un “ MESS ” (la palabra mess significa lío en inglés), por las siglas Sabio Masivamente Realzado en el Escenario (Massively Enhanced Sage on the Stage, en inglés.))

Cinco años atrás, no se podía caminar por los campus de las universidades más grandes sin escuchar a alguien hablando sobre cómo los MOOCs revolucionarían la educación, la destruirían o posiblemente ambas cosas. Los MOOCs le darían a las/los estudiantes acceso a un gran abanico de cursos y les permitirían trabajar cuando les fuera conveniente en lugar de acomodar su aprendizaje a la agenda de otra persona.

Pero los MOOCs no han sido tan efectivos como predijeron sus defensoras/es más entusiastas [Ubel2017]. Una razón es que el contenido grabado es ineficaz para muchas personas principiantes porque no puede aclarar los conceptos erróneos individuales (Capítulo 2): si no entienden una explicación la primera vez, por lo general, no hay una explicación alternativa para ofrecer. Otra razón es que la evaluación automatizada necesaria para lograr lo “masivo” en este tipo de cursos solo funciona bien en los niveles más bajos de la taxonomía de Bloom (Sección 6.2). Ahora también está claro que las/los estudiantes tienen que soportar mucho más la carga de mantenerse concentrados en un MOOC, que la impersonalidad de trabajar en línea puede fomentar un comportamiento descortés y desmotivar a las personas y que “disponible para todos” significa en realidad “disponible para todo el mundo lo suficientemente pudiente como para tener internet de alta velocidad y mucho tiempo libre”.

[Marg2015] examinaron 76 MOOCs sobre varios temas y descubrieron que, si bien la organización y presentación del material fue buena, la calidad del diseño de las lecciones fue deficiente. Con temáticas más afines a las de este libro, [Kim2017] estudió treinta tutoriales en línea populares sobre programación y descubrió que en gran medida enseñaban el mismo contenido de la misma manera: de abajo hacia arriba, comenzando con conceptos de programación de bajo nivel y avanzando hacia metas de alto nivel. La mayoría de los tutoriales requería que las/los estudiantes escribieran programas y proporcionaron algún tipo de retroalimentación inmediata, pero esta retroalimentación fue típicamente muy superficial. Pocos tutoriales explicaban cuándo y por qué los conceptos son útiles (es decir, no mostraban cómo transferir conocimientos), o proporcionaban orientación para errores comunes. Más allá de una diferenciación rudimentaria basada en la edad, ninguna lección se personalizaba en base a la experiencia previa en programación o en los objetivos de las/los estudiantes.

Aprendizaje personalizado

Pocos términos han sido utilizados y abusados de tantas formas como aprendizaje personalizado. Para la mayoría de las/los defensores de la educación con tecnología, significa ajustar dinámicamente el ritmo de las lecciones en función del rendimiento de cada estudiante, de modo que si alguien responde varias preguntas seguidas correctamente, la computadora omitirá algunas de las siguientes preguntas.

Hacer esto puede producir modestas mejoras, pero hay aproximaciones más convenientes. Por ejemplo, si muchas/os estudiantes encuentran difícil un tema en particular, la/el docente puede preparar múltiples explicaciones alternativas de ese punto en lugar de acelerar un solo camino. De esa manera, si una explicación no resuena, otras están disponibles. Sin embargo, esto requiere mucho más trabajo de diseño por parte de quien enseña, lo que puede ser la razón por la que no ha demostrado su popularidad. Incluso si funciona, es probable que los efectos sean mucho menores de lo que creen algunas/os de sus defensores. En la escuela primaria, puede haber diferencias de 0.1 a 0.15 desviaciones estándar en el desempeño de fin de año debido a buenas/os docentes.  [Chet2014] (ver este artículo para un breve resumen). No es realista creer que esto puede ser superado en el corto plazo por cualquier tipo de automatización.

Entonces, ¿cómo se debe usar internet para enseñar y aprender habilidades tecnológicas? Sus pros y contras son:

Las/los estudiantes pueden acceder a más lecciones y más rápido que nunca antes

Obviamente, suponiendo que un motor de búsqueda considere que vale la pena indexar esas lecciones, que su proveedor de servicios de internet y el gobierno no lo bloqueen, y que la verdad no se ahogue en un mar de desinformación que agota la atención.

Las/los estudiantes pueden acceder a mejores lecciones que nunca antes,

a menos que estén siendo dirigidas/os hacia material de segunda categoría, para redistribuir la riqueza de las personas que no tienen, a las personas que sí tienen [McMi2017]. También vale la pena recordar que la escasez aumenta el valor percibido, por lo que a medida que la educación en línea sea más barata se convertirá cada vez más en lo que todo el mundo quiere para las/los hijas/os de otra persona.

Las/los estudiantes también pueden acceder a muchos más contactos que nunca.

Pero solo si esas/os estudiantes realmente tienen acceso a la tecnología requerida, pueden permitirse usarla y no son excluidas/os por acoso o marginadas/os por no ajustarse a las normas sociales del grupo que lleve la voz cantante. En la práctica, la mayoría de las/los usuarias/os de MOOC proviene de entornos seguros y de buen nivel adquisitivo [Hans2015].

Las/los docentes pueden obtener información mucho más detallada sobre cómo trabajan sus estudiantes.

Siempre que las/los estudiantes hagan cosas que sean susceptibles de análisis automatizado a gran escala y no se opongan a la vigilancia en el aula o no sean lo suficientemente poderosas/os como para que sus objeciones importen.

[Marg2015,Mill2016a,Nils2017] describen formas de acentuar los aspectos positivos en la lista anterior evitando los negativos:

Haz que los plazos sean frecuentes y bien publicitados,

y aplícalos para que tus estudiantes entren en ritmo de trabajo.

Manten al mínimo las actividades sincronizadas de todas las clases, como conferencias en vivo

para que las personas no se pierdan cosas debido a conflictos de agenda.

Haz que tus estudiantes contribuyan al conocimiento colectivo,

p. ej. tomar notas compartidas (Sección 9.7), servir como escribas en el aula o contribuir con problemas a conjuntos de problemas compartidos (Sección 5.3).

Anima o solicita a tus estudiantes que realicen parte de su trabajo en grupos pequeños,

los cuales sí tienen actividades sincrónicas en línea, como por ejemplo una discusión semanal. Esto ayuda a las/los estudiantes a mantener su compromiso y motivación sin crear demasiados problemas de agenda. (Ver el Anexo 20 para obtener algunos consejos sobre cómo hacer que estas discusiones sean justas y productivas.)

Crea, publicita y haz cumplir un código de conducta.

para que toda la clase pueda participar en los debates en línea (Sección 9.1).

Utiliza muchas lecciones breves en lugar de pocos fragmentos largos al estilo conferencias

para minimizar la carga cognitiva y brindar muchas oportunidades para la evaluación formativa. Esto también ayuda con el mantenimiento de las lecciones: si todos tus videos son cortos, simplemente puedes volver a grabar cualquiera que necesite actualización, lo que a menudo es más barato que intentar arreglar videos largos.

Usa videos para fomentar la participación en lugar de instruir.

Dejando de lado las discapacidades (Sección 10.3), las/los estudiantes pueden leer más rápido de lo que tú puedes hablar. La excepción a esta regla es que el video es la mejor manera de enseñar verbos (acciones): grabaciones breves de tu pantalla que muestran cómo usar un editor, cómo recorrer el código en un depurador, y así sucesivamente, son más eficaces que las capturas de pantalla con texto.

Identifica y aclara tempranamente conceptos erróneos.

Si los datos muestran que las/los estudiantes tienen dificultades con algunas partes de una lección, crea explicaciones alternativas de esas partes y ejercicios adicionales para que practiquen.

Todo esto tiene que ser implementado de alguna manera, lo que significa que necesitas alguna clase de plataforma de enseñanza. Puedes utilizar tanto un sistema de gestión del aprendizaje (learning management system, en inglés) todo en uno como Moodle o Sakai, o generar uno por tu cuenta usando Slack o Zulip para el chat, Google Hangouts o appear.in para videoconferencias, y WordPress, Google Docs, o cualquier número de sistemas wiki para la autoría colaborativa. Si recién estás comenzando, elige lo que sea más fácil de configurar y administrar y lo que sea más familiar para tus estudiantes. Si te enfrentas a una elección, la segunda consideración es más importante que la primera: esperas que las personas aprendan mucho en tu clase, por lo que es justo que tú aprendas a manejar las herramientas con las que se sientan más cómodas.

Montar una plataforma para el aprendizaje es necesario pero no suficiente: si quieres que tus estudiantes prosperen, necesitas crear una comunidad. Cientos de libros y presentaciones hablan sobre cómo hacer esto, pero la mayoría se basan en las experiencias personales de sus autores. [Krau2016] es una excepción bienvenida: si bien es anterior al descenso acelerado de Twitter y Facebook hacia el abuso y la desinformación, la mayoría de sus hallazgos siguen siendo relevantes. [Foge2005] también está lleno de consejos útiles sobre comunidades de práctica a las que las/los estudiantes pueden desear unirse; exploramos algunas de sus ideas en el Capítulo 13.

Libertad para, libertad de

El ensayo de 1958 de Isaiah Berlin “Dos conceptos de libertad” hizo una distinción entre “libertad positiva, que es la capacidad de hacer algo, y libertad negativa, que es la ausencia de reglas que digan que no puedes hacerlo. Las discusiones en línea generalmente ofrecen libertad negativa (nadie te impide decir lo que piensas), pero no libertad positiva (muchas personas no pueden ser escuchadas, en realidad). Una forma de abordar esto es introducir algún tipo de limitación, como permitir que cada estudiante contribuya con un mensaje por hilo de discusión al día. Hacer esto les da a aquellas/los que tienen algo que decir la oportunidad de decirlo, mientras deja espacio para que otras/os también digan cosas.

Otra preocupación que se tiene sobre la enseñanza en línea es la posibilidad de que las/los estudiantes hagan trampa. La deshonestidad del día a día no es más común en las clases en línea que en los entornos presenciales [Beck2014], pero la tentación de que otra persona escriba el examen final y la dificultad de comprobar si esto realmente sucedió, es una de las razones por las que las instituciones educativas se han mostrado reacias a ofrecer créditos para las clases solamente en línea. Es posible supervisar el examen a distancia, pero antes de invertir en esto, lee [Lang2013]: explora por qué y cómo las/los estudiantes hacen trampa, y cómo se pueden estructurar los cursos para evitar darles una razón para hacerlo.

Video

Una característica destacada de la mayoría de los MOOC es el uso de clases grabadas en video. Estos videos pueden ser efectivos: como se menciona en el Capítulo 8, una técnica de enseñanza llamada instrucción directa basada en la entrega precisa de un guión bien diseñado ha demostrado repetidamente su eficacia [Stoc2018]. Sin embargo, los guiones para la instrucción directa deben diseñarse, probarse y perfeccionarse con mucho cuidado, lo que es una inversión que muchos MOOC no han querido o no han podido hacer. Hacer un pequeño cambio en una página web o en una plataforma de diapositivas solo toma unos minutos; hacer incluso un pequeño cambio en un video corto lleva una hora o más, por lo que el costo de actuar en base a los comentarios puede ser insoportable para la/el docente. Incluso cuando están bien hechos, los videos deben combinarse con actividades para que sean beneficiosos: [Koed2015] estimaron que “… hacer tareas extra tiene un beneficio sobre el aprendizaje … seis veces mayor que mirar o leer extra.”

Si estás enseñando programación, puedes usar grabaciones de pantallas en lugar de diapositivas, ya que ofrecen algunas de las mismas ventajas que la programación en vivo (Sección 8.1). [Chen2009] ofrecen consejos útiles para crear y criticar grabaciones de pantallas y otros videos; la Figura 11.1 (de [Chen2009]) reproduce los patrones que presenta el papel y las relaciones entre ellos. (También es un buen ejemplo de mapa conceptual (Sección 3.1).)

Entonces, ¿qué hace que un video instructivo sea efectivo? [Guo2014] midieron el compromiso y participación, observando cuánto tiempo las/los estudiantes vieron los videos de MOOCs, y encontraron que:

• Los videos más cortos son mucho más atractivos; los videos no deben durar más de seis minutos.

• Una cabeza parlante superpuesta a las diapositivas es más atractiva que solo una voz en off.

• Los videos que se sienten personales pueden ser más atractivos que las grabaciones de estudio de alta calidad, por lo que filmar en entornos informales podría funcionar mejor que filmar en un estudio profesional por un costo menor.

• Dibujar en una tableta es más atractivo que las diapositivas de PowerPoint o las grabaciones de pantalla con código, aunque no está claro si esto se debe al movimiento y la informalidad o porque reduce la cantidad de texto en la pantalla.

• Está bien que las/los docentes hablen bastante rápido siempre que estén entusiasmados.

Una cosa que  [Guo2014] no abordaron es el problema del huevo y la gallina: ¿las/los estudiantes encuentran cierto tipo de video atractivo porque están acostumbrados? Entonces, ¿producir más videos de ese tipo aumentará la participación simplemente debido a un ciclo de retroalimentación? ¿O estas recomendaciones reflejan algunos procesos cognitivos más profundos? Otra cosa que este documento no analizó son los resultados del aprendizaje: sabemos que las evaluaciones de las/los estudiantes de los cursos no se correlacionan con el aprendizaje [Star2014,Uttl2017], y si bien es plausible que las/los estudiantes no aprendan de las cosas que no ven, queda por demostrar que aprenden de las cosas que ven.

Estoy un poco incómoda/o

La investigación de [Guo2014] fue aprobada por una junta universitaria de ética en investigación, las/los estudiantes cuyos hábitos de visualización fueron monitoreados casi con certeza hicieron clic en “aceptar” en un acuerdo de términos de servicio en algún momento, y me alegra tener estos nuevos conocimientos. Por otra parte, la palabra “privacidad” no apareció en el título o en el resumen de ninguna de las decenas de artículos o posters en la conferencia donde se presentaron estos resultados. Si pudiera elegir, preferiría no saber qué tanto compromiso tenían los estudiantes en vez de fomentar la vigilancia ubicua en el aula.

Hay muchas formas diferentes de grabar lecciones en video; para saber cuáles son más eficaces, [Mull2007a] asignó 364 estudiantes de física de primer año a los tratamientos multimedia en línea de la Primera y Segunda Ley de Newton en uno de cuatro estilos:

Exposición:

presentación concisa al estilo de una clase magistral.

Exposición extendida:

igual que la anterior, pero con información adicional interesante.

Refutación:

Exposición con conceptos erróneos comunes explícitamente declarados y refutados.

Diálogo:

Discusión estudiante-docente del mismo material que en la Refutación.

Refutación y diálogo produjeron los mayores beneficios de aprendizaje en comparación con la exposición; las/los estudiantes con pocos conocimientos previos se beneficiaron más y quienes tenían un alto conocimiento previo no estuvieron en desventaja. De nuevo, esto destaca la importancia de abordar directamente los conceptos erróneos de tus estudiantes. No solo le digas a las personas lo que es: diles también qué no es y por qué no.

Modelos híbridos

La enseñanza totalmente automatizada es solo una forma de utilizar la web en la enseñanza. En la práctica, casi todo el aprendizaje en las sociedades prósperas tiene actualmente un componente en línea, ya sea oficialmente o a través de canales de comunicación persona a persona y búsquedas encubiertas de respuestas a preguntas sobre la tarea. La combinación de instrucción en vivo y automatizada permite a las/los docentes usar las fortalezas de ambas modalidades. En un aula tradicional, la/el docente puede responder preguntas de inmediato, pero sus estudiantes necesitan días o semanas para recibir comentarios sobre sus ejercicios de programación. En línea, una/un estudiante puede tardar más en obtener una respuesta, pero puede obtener comentarios inmediatos sobre el código que programó (y al menos para ese tipo de ejercicios podemos calificar automáticamente).

Otra diferencia es que los ejercicios en línea deben ser más detallados porque tienen que anticiparse a las preguntas de las/los estudiantes. Encuentro que las lecciones en persona comienzan con la intersección de lo que todo el curso necesita saber y se expanden a pedido, mientras que las lecciones en línea deben incluir la unión de lo que todas las personas necesitan saber porque la/el docente no está ahí para hacer esta expansión.

En realidad, la distinción entre en línea y presencial ahora es menos importante para la mayoría de las personas que la distinción entre sincrónico y asincrónico: ¿docentes y estudiantes interactúan en tiempo real? ¿O su comunicación se extiende e intercala con otras actividades? En persona casi siempre la interacción será sincrónica, pero en línea es, cada vez más, una mezcla de ambas:

Creo que nuestras/os nietas/os probablemente considerarán la distinción que hacemos entre lo que llamamos el mundo real y lo que ellas/os consideran simplemente el mundo como la cosa más pintoresca e incomprensible sobre nosotras/os.
— William Gibson

La implementación más popular de este futuro combinado hoy es el aula invertida, en el que las/los estudiantes ven lecciones grabadas por su cuenta y el tiempo de la clase se utiliza para discutir y resolver conjuntos de problemas. Descripto originalmente en [King1993], la idea se popularizó como parte de la instrucción entre pares (Sección 9.2) y se ha estudiado intensamente durante la última década. Por ejemplo, [Camp2016] comparó a estudiantes que tomaron una clase de introducción a la informática en línea con quienes la tomaron en un aula invertida. La finalización de ejercicios de práctica (sin marcar) se correlacionó con los puntajes de los exámenes para ambos grupos, pero la tasa de finalización de los ejercicios de ensayo por parte de las/los estudiantes en línea fue significativamente más baja que las tasas de asistencia a clase para las/los estudiantes presenciales.

Pero si hay grabaciones disponibles, ¿seguirán asistiendo las/los estudiantes a las clases para hacer ejercicios de práctica? [Nord2017] examinó el impacto de las grabaciones en la asistencia a las clases y al desempeño de las/los estudiantes en diferentes niveles. En la mayoría de los casos, el estudio no encontró consecuencias negativas al hecho de hacer disponibles las grabaciones; en particular, las/los estudiantes no se saltaron las clases cuando las grabaciones estaban disponibles (al menos, no más de lo que suelen faltar). Los beneficios de proporcionar grabaciones fueron mayores para las/los estudiantes al principio de sus carreras, pero disminuyeron a medida que las/los estudiantes avanzaban.

Otro modelo híbrido es aquel que lleva al aula la vida en línea. Tomar notas en conjunto es un primer paso (Sección 9.7); agrupando respuestas a preguntas de opción múltiple en tiempo real con herramientas como Pear Deck y Socrative. Si la clase es pequeña — digamos, de una docena a quince personas — y si hay posibilidades de conectarse a internet en el aula, también puedes hacer que todas las personas del curso se unan a una videoconferencia para que puedan compartir la pantalla con la/el docente. Esto les permite mostrar su trabajo (o sus problemas) a toda la clase. sin tener que conectar su computadora portátil al proyector. Las/los estudiantes también pueden usar el chat en la videollamada para hacer preguntas para la/el docente; en mi experiencia, la mayoría de las preguntas serán respondidas por sus compañeras/os, y la/el docente puede encargarse del resto cuando lleguen a un momento natural de descanso. Este modelo ayuda a nivelar "la cancha´´ para las/los estudiantes remotos: si alguien no puede asistir a clase por razones de salud o por compromisos familiares o laborales, todavía puede participar casi en pie de igualdad si todo el curso está acostumbrado a colaborar en línea y en tiempo real.

También he impartido clases utilizando instrucción remota en tiempo real, modalidad en la que las/los estudiantes comparten la ubicación en 2 a 6 sitios diferentes, con ayudantes presentes, mientras yo enseñaba vía videoconferencia (Sección 18.1). Esto escala bien, ahorra en gastos de viaje, y permite el uso de técnicas como la programación en parejas (Sección 9.6). Lo que no funciona, es tener un grupo en persona y uno o más grupos de forma remota: aún con la mejor voluntad del mundo, quienes participan en persona reciben mucha más atención.

Participación en línea

[Nuth2007] descubrió que hay tres mundos superpuestos en cada aula: lo público (lo que dice y hace la/el docente), lo social (interacciones entre pares, entre estudiantes), y lo privado (dentro de la cabeza de cada estudiante). De estos, el más importante suele ser el social: las/los estudiantes captan tanto a través de las señales de sus compañeras/os como de la instrucción formal.

Por lo tanto, la clave para hacer efectiva cualquier forma de enseñanza en línea es facilitar las interacciones entre pares. Para ayudar a lograr esto, los cursos casi siempre tienen algún tipo de foro de discusión. [Mill2016a] observaron que las/los estudiantes los utilizan de formas muy diferentes:

…es muy poco probable que las personas procrastinadoras participen en foros de discusión en línea y esta participación reducida, a su vez, se correlaciona con peores calificaciones. Una posible explicación de esta correlación es que las personas procrastinadoras son especialmente reacias a unirse una vez que la discusión está en curso, quizás porque les preocupa ser percibidas como recién llegadas en una conversación establecida. Esta aversión a participar tarde provoca que se pierdan los beneficios importantes de aprendizaje y motivación de la interacción entre pares.

[Vell2017] analiza publicaciones en foros de discusión de 395 estudiantes de CS2 en dos universidades dividiéndo a las publicaciones en cuatro categorías:

Activa:

solicitud de ayuda que no muestra razonamiento y no muestra lo que la/el estudiante ya ha intentado o ya sabe.

Constructiva:

refleja el razonamiento de las/los estudiantes o intenta construir una solución al problema.

Logística:

políticas del curso, horarios, envío de tareas, etc.

Aclaración de contenido:

solicitud de información adicional que no revela el propio pensamiento de la estudiante.

Descubrieron que dominaban las preguntas constructivas y logísticas, y que las preguntas constructivas se correlacionaban con las calificaciones. También encontraron que las/los estudiantes rara vez hacen más de una pregunta activa en un curso, y que estas no se correlacionan con las calificaciones. Si bien esto es decepcionante, saberlo ayuda a establecer las expectativas de las docentes: si bien es posible que deseemos que nuestros cursos tengan comunidades en línea animadas, tenemos que aceptar que la mayoría no lo hará, o que la mayor parte de la discusión de estudiante a estudiante se llevará a cabo a través de canales que ya están usando y en los que no podemos ser parte.

Cooperación

[Gull2004] describe un concurso de programación en línea que combina colaboración y competencia. El concurso comienza cuando se publica una descripción del problema junto con una solución correcta pero ineficiente. Cuando acaba, la persona ganadora es quien ha hecho la mayor contribución global para mejorar el rendimiento de la solución global. Todas las presentaciones están abiertas, para que los participantes puedan ver el trabajo de los demás y tomar prestadas ideas entre ellos. Como muestra el trabajo, la solución final es casi siempre un híbrido que utiliza ideas de muchas personas.

[Batt2018] describió una variación a pequeña escala de esto en una clase de introducción a la informática. En la etapa uno, cada estudiante presentó un proyecto de programación de forma individual. En la etapa dos, las/los estudiantes trabajaron en parejas para crear una solución mejorada al mismo problema. La evaluación indica que los proyectos de dos etapas tienden a mejorar la comprensión de las/los estudiantes y que ellas/os disfrutaron del proceso. Proyectos como estos no solo mejoran la participación: también brindan a las/los estudiantes más experiencia sobre la base del código de otra persona.

La discusión no es la única forma de lograr que las/los estudiantes trabajen juntos en línea. [Pare2008] y [Kulk2013] reportan experimentos en el que las/los estudiantes califican el trabajo del resto del curso y las calificaciones que asignan se comparan con las calificaciones otorgadas por docentes auxiliares ya graduadas/os u otras personas expertas. Ambos trabajos encontraron que las calificaciones asignadas por las/los estudiantes coincidían con las calificaciones asignadas por las personas expertas con tanta frecuencia como las calificaciones de las personas expertas coincidían entre sí. También encontraron que unos sencillos pasos (como filtrar respuestas obviamente no consideradas o estructurar rúbricas) disminuyeron aún más el desacuerdo. Como se discute en la Sección 5.3, la colusión y el sesgo no son factores importantes en la calificación de pares.

Confía, pero educa

La forma más común de medir la validez de los comentarios es comparar las calificaciones de las/los estudiantes con las calificaciones de personas expertas, pero la revisión por pares calibrada (Sección 5.3) puede ser igualmente efectiva. Antes de pedirles a estudiantes que califiquen el trabajo del resto del curso, se les pide que califiquen muestras y se comparan sus resultados con las calificaciones asignadas por la/el docente. Una vez que ambas calificaciones se alinean, se permite que cada estudiante comience a calificar a sus pares. Dado que la lectura crítica es una forma eficaz de aprender, este resultado puede apuntar a un futuro en el que las/los estudiantes utilicen la tecnología para emitir juicios, en lugar de ser juzgadas/os por la tecnología.

Una técnica que definitivamente vamos a ver más en los próximos años es la transmisión en línea de sesiones de programación en vivo [Raj2018,Haar2017]. Esto tiene la mayoría de los beneficios discutidos en la Sección 8.1, y cuando se combina con la toma de notas colaborativa (Sección 9.7) puede ser una aproximación cercana a una experiencia en clase.

Si pensamos en unos años más, [Ijss2000] identificaron cuatro niveles de presencia en línea, desde el realismo (no podemos notar la diferencia), la inmersión (nos olvidamos de la diferencia), la participación (tenemos compromiso con la clase, pero somos conscientes de la diferencia) a la suspensión de la incredulidad (estamos haciendo la mayor parte del trabajo). La diferencia crucial que distinguen es la presencia física, como la sensación de estar en algún lugar, y la presencia social, que es la sensación de estar con las demás personas. Esta última es más importante en la mayoría de situaciones de aprendizaje y, otra vez, podemos fomentarla utilizando la tecnología diaria de las/los estudiantes en el aula. Por ejemplo, [Deb2018] descubrieron que la retroalimentación en tiempo real sobre los ejercicios en clase, usando los dispositivos móviles de las/los estudiantes, mejoró la retención de conceptos y la participación de las/los estudiantes, al tiempo que redujo las tasas de fracaso.

La enseñanza en línea y asincrónica aún está en pañales. Los MOOCs centralizados pueden llegar a ser un callejón evolutivo sin salida, pero aún quedan muchos otros modelos prometedores por explorar. En particular, [Broo2016] describe cincuenta formas en que los grupos pueden discutir cosas de manera productiva, y solo unas pocas son ampliamente conocidas o implementadas en línea. Si vamos a donde están tecnológicamente nuestras/os estudiantes, en lugar de pedirles que vengan a nosotros, podemos terminar aprendiendo tanto como ellas/los.

Ejercicios

Video bidireccional (parejas/10’)

Grábate en un video de 2 a 3 minutos haciendo algo, luego intercambia el video con tu colega para que cada una/o pueda ver el video de la otra persona a una velocidad 4x. ¿Qué tan fácil es seguir lo que está pasando? ¿Te perdiste de algo?

Puntos de vista (individual/10’)

De acuerdo a [Irib2009], diferentes disciplinas se centran en diferentes factores que afectan el éxito o no de las comunidades en línea:

Negocios:

fidelización de clientes, gestión de marca, motivación extrínseca.

Psicología:

sentido de comunidad, motivación intrínseca.

Sociología:

identidad de grupo, comunidad física, capital social, acción colectiva.

Ciencias de la computación:

implementación tecnológica.

¿Cuál de estas perspectivas se corresponde más con la tuya? ¿Con cuál estás menos alineada/o?

Ayudar o dañar (grupos pequeños/30’)

Este artículo de Susan Dynarski en New York Times explica cómo y por qué las escuelas asignan a cursos en línea a aquellas/os estudiantes que no aprueban los cursos presenciales, y cómo esto configura las condiciones para un fracaso aún mayor. Lee el artículo y luego:

1. En grupos pequeños, piensen en dos o tres cosas que las escuelas podrían hacer para compensar estos efectos negativos y crear estimaciones aproximadas de sus costos por estudiante.

2. Compara tus sugerencias y costos con los de otros grupos. ¿Cuántos puestos de enseñanza a tiempo completo crees que deberían eliminarse con el fin de liberar recursos para implementar las ideas más populares para un centenar de estudiantes?

3. Finalmente, discutan en toda la clase: ¿creen que sería un beneficio real para las/los estudiantes o no?

Los ejercicios de presupuestación como este son una buena manera de saber quién se toma en serio el cambio educativo. Todas las personas pueden pensar en cosas que les gustaría hacer; pero muchas menos están dispuestas a hablar sobre las compensaciones necesarias para que suceda el cambio.

Tipos de ejercicios

Todo/a buen/a carpintero/a tiene un juego de destornilladores y todo/a buen/a docente tiene diferentes tipos de ejercicios para comprobar qué están aprendiendo realmente los/las estudiantes, para ayudarlos a practicar sus nuevas habilidades y para mantener su compromiso.

Este capítulo comienza describiendo varios tipos de ejercicios que se pueden usar para corroborar si tu forma de enseñar ha resultado efectiva.

Luego examina el estado del arte en cuanto a calificación automatizada y culmina explorando discusiones, proyectos y otros tipos importantes de trabajo que requieren una atención más humana para evaluar.

Nuestra discusión se basa parcialmente en el Banco de Preguntas de Canterbury Canterbury Question Bank [Sand2013], que trae entradas para varios lenguajes de programación y temas introductorios a las ciencias de la computación.

Los clásicos

Como se discute en la Sección 2.1, las preguntas de opción múltiple son más efectivas cuando las respuestas incorrectas sondean conceptos erróneos específicos. Están diseñadas para evaluar los niveles más bajos en la Taxonomía de Bloom (Sección 6.2), pero también requieren que los/las estudiantes utilicen su propio juicio.

Una pregunta de opción múltiple

¿En qué orden ocurren las operaciones cuando la computadora evalúa la expresión precio = agregarImpuestos(costo - descuento)?

1. resta, llamado a función, asignación

2. llamado a función, resta, asignación

3. llamado a función, luego asignación y resta simultáneamente

4. ninguna de las anteriores

El segundo tipo de ejercicio clásico es programar y ejecutar, donde el/la estudiante escribe un código que produce una salida especificada. Los ejercicios de programar y ejecutar pueden ser tan simples o complejos como el/la docente quiera, pero cuando se usen en clase deben ser breves y tener solo una o dos respuestas correctas posibles. Generalmente es suficiente pedir a las personas principiantes que calculen e impriman un solo valor o que llamen a una función específica: docentes experimentados/as a menudo olvidan de lo difícil que puede ser averiguar qué parámetros van en qué lugar. Para los/las estudiantes más avanzados, averiguar qué función llamar es una actividad más atractiva y una mejor evaluación de su comprensión.

Programar y ejecutar

La variable foto contiene una imagen a todo color de un archivo. Usando una función, crea una versión blanco y negro de la imagen y asígnala a una variable nueva llamada monocromo.

Los ejercicios de programar y ejecutar se pueden combinar con preguntas de opción múltiple. Por ejemplo, esta pregunta de opción múltiple sólo puede ser contestada ejecutando el comando Unix ls:

Combinar preguntas de opción múltiple con programar & ejecutar

Estás en el directorio /home. ¿Cuál de los siguientes archivos no está en dicho directorio?

1. otonio.csv

2. verano.csv

3. primavera.csv

4. invierno.csv

Los ejercicios de programar y ejecutar ayudan a las personas a practicar las habilidades que más quieren aprender, pero pueden ser difíciles de evaluar: puede haber muchas maneras inesperadas de obtener la respuesta correcta, y es desmoralizante si un sistema de calificación automática rechaza el código de la solución porque no se corresponde con el del docente. Una forma de reducir qué tanto ocurre esto es evaluar solo su producción, pero eso no les da una devolución sobre cómo están programando. Otra manera es darles un pequeño conjunto de evaluación en el que pueden ejecutar su código antes de enviarlo (y entonces el código se evalúa con un conjunto más amplio de pruebas). Hacer esto les ayuda a descubrir si han malinterpretado completamente la intención del ejercicio antes de hacer cualquier cosa que pueda afectarles la nota.

En lugar de escribir código que satisface algunas especificaciones, se les puede pedir a los/las estudiantes que escriban pruebas para determinar si un fragmento de código se ajusta a una especificación. Esta habilidad es útil por sí misma y practicarla puede darles a los/las estudiantes un poco más de simpatía por el trabajo duro de sus docentes.

Invirtiendo programar y ejecutar

La función suma_monotona calcula la suma de cada sección de una lista de números, en la que los valores aumentan estrictamente.

Por ejemplo, dada la entrada [1, 3, 3, 4, 5, 1], la salida es [4, 12, 1].

Escribe y corre pruebas unitarias para determinar cuál de los siguientes errores está contenido en la función:

• Considera cada número negativo como el inicio de una nueva sub-secuencia.

• No incluye el primer valor de cada sub-secuencia en la sub-suma.

• No incluye el último valor de cada sub-secuencia en la sub-suma.

• Solo reinicia la suma cuando los valores decrecen en vez de aumentar.

Completar los espacios en blanco es un refinamiento de programar y ejecutar en el que el/la estudiante recibe el comienzo de un código y debe completarlo.

(En la práctica, la mayoría de los ejercicios programar y ejecutar son en realidad del tipo completar los espacios en blanco, porque el/la docente proporciona comentarios para recordarles a sus estudiantes los pasos que deben seguir). Las preguntas de este tipo son las bases para ejemplos desvanecidos; como se discute en el Capítulo 4, las personas principiantes a menudo encuentran a este tipo de ejercicios menos intimidante que escribir todo el código desde cero; y dado que el/la docente ha proporcionado la mayor parte de la estructura de la respuesta, las respuestas enviadas son mucho más predecibles y, por lo tanto, más fáciles de revisar.

Completar los espacios en blanco

Completa los espacios en blanco, para que el código de abajo imprima el texto ’cana’.¹⁶

text = 'Un canario que ladra si está triste' 
slice = text[____:____]
print(slice)

Los problemas de Parsons también evitan el problema de la “pantalla blanca del terror" a la vez que permite que los/las estudiantes se concentren en el flujo de control por separado del vocabulario [Pars2006,Eric2015,Morr2016,Eric2017].

Existen herramientas para construir y hacer problemas de Parsons en línea [Ihan2011], pero pueden ser emuladas (aunque un poco torpemente) pidiendo a los/las estudiantes que reorganicen las líneas de código en un editor de texto.

Problemas de Parsons

Reorganiza e indenta estas líneas para obtener la suma de los valores positivos de una lista. (También deberás agregar dos "dos puntos" en los lugares apropiados)

total = 0
if v > 0
total += v
for v in valores

Ten en cuenta que dar a los/las estudiantes más líneas de las que necesitan, o pedirles que reordenen algunas líneas y añadan algunas más, hace que los problemas de Parsons sean significativamente más difíciles [Harm2016].

Seguir

Seguir la ejecución es la inversa de un problema de Parsons: dadas unas pocas líneas de código, los/las estudiantes tienen que rastrear el orden en que se ejecutan esas líneas.

Esta es una habilidad esencial de depuración y una buena manera de consolidar la comprensión de los/las estudiantes de los bucles, los condicionales y el orden de evaluación de las llamadas a funciones y métodos.

La forma más fácil de implementarlo es hacer que los/las estudiantes escriban una secuencia de pasos etiquetados. Hacer que elijan la secuencia correcta de un conjunto (es decir, presentarla como una pregunta de opción múltiple) añade carga cognitiva sin añadir valor, ya que tienen que hacer todo el trabajo de averiguar la secuencia correcta y luego buscarla en la lista de opciones.

Seguir el orden de ejecución

¿En qué orden se ejecutan las líneas etiquetadas en este bloque de código?

A)     vals = [-1, 0, 1]
B)     suma_inversa = 0
       try:
           for v in vals:
C)             suma_inversa += 1/v
       except:
D)         pass

Seguir los valores es similar a seguir la ejecución, pero en lugar de deletrear el orden en que se ejecuta el código, el/la estudiante enumera los valores que una o más variables toman a medida que se ejecuta el programa.

Una forma de implementar esto es dar a cada estudiante una tabla cuyas columnas estén etiquetadas con nombres de variables y cuyas filas estén etiquetadas con números de línea, y pedirles que completen los valores que las variables toman en dichas líneas.

Seguir los valores

¿Qué valores toman izquierda y derecha a medida que este programa se ejecuta?

A) izquierda = 23
B) derecha = 6
C) while derecha:
D)     izquierda, derecha = derecha, izquierda % derecha

También puedes requerir que los/las estudiantes rastreen el código hacia atrás para averiguar cuál debe haber sido la entrada para que el código produzca un resultado determinado [Armo2008].

Estos problemas de ejecución inversa requieren razonamientos de búsqueda y deducción, y cuando la salida es un mensaje de error, contribuyen a que los/las estudiantes desarrollen habilidades valiosas de depuración.

Ejecución inversa

Rellena el número faltante en valores que causó que esta función se interrumpiera.

valores = [ [1.0, -0.5], [3.0, 1.5], [2.5, ___] ]
corridaTotal = 0.0
for (lectura, escalada) in valores:
    corridaTotal += lectura / escalada

Los ejercicios de ajuste mínimo también ayudan a desarrollar habilidades de depuración.

Dadas unas pocas líneas de código que contienen un error, el/la estudiante deben encontrarlo y hacer un pequeño cambio para arreglarlo.

El cambio puede hacerse usando programar y ejecutar, mientras que la identificación se puede hacer como una pregunta de opción múltiple.

Ajuste mínimo

Esta función se supone que prueba si un número se encuentra dentro de un rango. Realiza un pequeño cambio para que la función realmente lo haga.

def inside(punto, mas_bajo, mas_alto):
    if (punto <= mas_bajo):
        return false
    elif (punto <= mas_alto):
        return false
    else:
        return true

Los ejercicios de tema y variación son similares, pero se le pide al estudiante que haga una pequeña alteración que cambie la salida de alguna manera específica en lugar de realizar un cambio para corregir un error. Los cambios permitidos pueden incluir cambiar el valor inicial de una variable, reemplazar una llamada a una función por otra, intercambiar bucles internos y externos, o cambiar el orden de las pruebas en un condicional complejo.

De nuevo, este tipo de ejercicio da a los/las estudiantes la oportunidad de practicar una habilidad útil para el mundo real: la forma más rápida de producir el código que necesitan es ajustando un código que ya hace algo parecido.

Tema y variaciones

Cambia el bucle interno de la siguiente función para que llene el triángulo superior izquierdo de una imagen con un color especificado.

function llenarTriangulo(imagen, color) is
    for x := 1 to imagen.width do
        for y := 1 to imagen.height do
            imagen[x, y] = color
        end
    end
end

Los ejercicios de modificación son el complemento de los ejercicios temáticos y de variación: dado un fragmento de código que funciona, el/la estudiante tiene que modificarlo de alguna manera sin cambiar la salida.

Por ejemplo, el/la estudiante puede reemplazar los bucles con expresiones vectorizadas o simplificar la condición en un bucle while.

Esta es también una habilidad útil para la vida real, pero a menudo hay tantas formas de modificar el código que la calificación requiere inspección humana.

Refactorizar

Escribir una sola compresión de lista que tenga el mismo efecto que este bucle.

resultado = []
for v in valores:
    if len(v) > rango:
        resultado.append(v)

Diagramas

Hacer que los estudiantes dibujen mapas conceptuales y otros diagramas brinda una idea de cómo están pensando (Sección 3.1), pero los diagramas de forma libre requieren que una persona los evalúe (no pueden ser calificados automáticamente), por lo que consumen mucho tiempo.

Etiquetar los diagramas, por otra parte, es casi tan potente pedagógicamente pero mucho más fácil de escalar. En lugar de hacer que tus estudiantes creen diagramas desde cero, puedes entregarles un diagrama y un conjunto de etiquetas y hacer que coloquen las etiquetas en los lugares correctos. El diagrama puede ser una estructura de datos (“después de ejecutar este código, ¿qué variables apuntan a qué partes de esta estructura?”), un gráfico (“une con flechas cada uno de estos fragmentos de código con la parte del gráfico generado”), o el propio código (“haz coincidir cada término con un ejemplo de ese mismo elemento en el programa”).

Etiquetado de un diagrama

La Figura 12.1 muestra cómo un fragmento pequeño de HTML se representa en memoria. Coloca las etiquetas 1–9 sobre los elementos del árbol para mostrar el orden en el que se alcanzan en un recorrido en profundidad.

Otra forma de usar diagramas es dar a tus estudiantes las partes del diagrama y pedirles que las organicen correctamente.

Este es un equivalente visual a un problema de Parsons, y para ayudar con el etiquetado puedes proporcionar más o menos del esqueleto, de acuerdo a la dificultad para la que crees que están preparados/as.

Tengo buenas memorias de tratar de colocar resistencias y capacitores en un diagrama de circuito con el fin de obtener el voltaje correcto en un punto determinado, y he visto docentes que les dan a sus estudiantes un conjunto definido de bloques de Scratch y les piden que creen un diseño particular usando solo esos bloques.

Los problemas de correspondencia pueden pensarse como un caso especial de etiquetado en el que el “diagrama" es una columna de texto y las etiquetas se toman de la otra columna.

En la correspondencia uno-a-uno se le da a cada estudiante dos listas de igual longitud y se le pide que asocie los elementos correspondientes, p.ej. “ asocia cada fragmento de código con la salida que produce".

Correspondencia

Asocia cada operador de expresión regular en la Figura 12.2 con lo que hace.

Con la correspondencia de muchos a muchos las listas no tienen la misma longitud, por lo que algunos elementos pueden asociarse con varios y otros pueden no ser emparejados en absoluto.

Las correspondencias muchos-a-muchos son más difíciles porque los/las estudiantes no pueden hacer los apareamientos fáciles primero para reducir su espacio de búsqueda.

Los problemas de correspondencia pueden ser implementados en exámenes autocorregibles haciendo que los/las estudiantes/as envíen listas de ítems apareados (como “A3, B1, C2”), pero eso es burdo y propenso a errores.

Hacer que reconozcan un conjunto de pares correctos en preguntas de opción múltiple es aún peor, ya que es muy fácil de malinterpretar, lamentablemente.

Dibujar o arrastrar funciona mucho mejor, pero requiere más trabajo para implementarlo.

Ranking es un caso especial de emparejamiento que es (ligeramente) más fácil de responder a través de listas, ya que nuestras mentes son bastante buenas en la detección de errores o anomalías en las secuencias. Los criterios de ranking determinan el nivel de razonamiento requerido.

Si haces que tus estudiantes ordenen los algoritmos del más rápido al más lento, probablemente estés ejercitando la memoria (es decir, pidiéndoles que reconozcan los nombres de los algoritmos y que sepan sus propiedades), mientras que al pedirles que ordenen las soluciones de las más robustas a las más frágiles, ejercitas su razonamiento y juicio.

Resumir también requiere que los/las estudiantes utilicen un pensamiento de orden superior y les da la oportunidad de practicar una habilidad que es muy útil para informar sobre errores. Por ejemplo, les puedes preguntar a tus estudiantes: “¿Qué frase describe mejor cómo cambia la salida de f a medida que x varía de 0 a 10?" y luego darles varias opciones como una pregunta de opción múltiple.

También puedes pedir respuestas muy cortas de formato libre a preguntas en dominios restringidos, como por ejemplo, “¿Cuál es la característica clave para que un algoritmo de ordenamiento sea estable?” No podemos automatizar completamente la comprobación de las respuestas sin generar un número frustrante de falsos positivos (aceptando respuestas incorrectas) y falsos negativos (rechazando las correctas), pero las preguntas de este tipo se prestan bien a la clasificación por pares (Sección 5.3).

Calificación automática

Las herramientas automáticas de corrección de evaluaciones han existido desde antes que yo naciera: la primera mención publicada data de 1960 y las encuestas publicadas por [Douc2005,Ihan2010] mencionan muchas herramientas específicas por su nombre.

Construir este tipo de herramientas es mucho más complejo de lo que podría parecer a primera vista.

¿Cómo se representan las tareas?

¿Cómo se realiza un seguimiento y se informan los envíos?

¿Pueden los/las estudiantes trabajar cooperativamente?

¿Cómo se pueden ejecutar los envíos de forma segura?

[Edwa2014a] es un artículo dedicado por completo a un esquema adaptativo para detectar y gestionar bucles infinitos de los envíos de código, y este es solo uno de las muchos problemas que surgen.

Cuando se habla de autocalificadores, es importante diferenciar la satisfacción de los/las estudiantes de los resultados del aprendizaje. Por ejemplo, [Magu2018] sustituyó los laboratorios informales de programación para un curso de Ciencias de la Computación de segundo año por una prueba semanal evaluada utilizando un calificador automático. A los/las estudiantes no les gustó el sistema automatizado, pero la tasa general de fracasos del curso se redujo a la mitad y se triplicó el número de estudiantes que obtuvieron calificaciones con honores. Por el contrario, [Rubi2014] también comenzó a utilizar un autocalificador diseñado para competencias, pero no vio una disminución significativa en las tasas de deserción de sus estudiantes; una vez más, los/las estudiantes hicieron comentarios negativos sobre la herramienta, que los/las autores atribuyen a la calidad de los mensajes de retroalimentación más que a una aversión a la autocalificación.

[Srid2016] adoptaron un enfoque diferente. Utilizaron fuzz testing (casos de prueba generados aleatoriamente) para comprobar si el código del estudiante realiza lo mismo que una implementación de referencia proporcionada por el/la docente. En el primer proyecto de un curso introductorio de 1400 estudiantes, el fuzz testing identificó errores que no habían sido detectados en un conjunto de casos de prueba escritos a mano para más del 48% de los/las estudiantes.

[Basu2015] dio a sus estudiantes una serie de soluciones a casos de prueba, pero tenían que desbloquear cada caso respondiendo preguntas sobre su comportamiento esperado antes de que se les permitiera aplicarlo a la solución propuesta por ellos/as.

Por ejemplo, supongamos que los/las estudiantes tenían que escribir una función para encontrar el mayor par de números adyacentes en una lista. Antes de que se les permitiera usar las pruebas de la pregunta, tenían que elegir la respuesta correcta a: “¿Qué produce parMasGrande(4, 3, -1, 5, 3, 3)?". En un curso universitario de 1300 personas, la gran mayoría de los/las estudiantes optaron por validar su comprensión de los casos de prueba de esta manera antes de intentar resolver los problemas, y así hicieron menos preguntas y expresaron menos confusión acerca de las tareas.

En contra de las herramientas “listas para usar" disponibles en el mercado

Es tentador calificar el código de los/las estudiantes con herramientas de revisión de estilo disponibles y de acceso sencillo. Sin embargo, [Nutb2016] inicialmente no encontraron correlación entre las calificaciones proporcionadas por personas y las violaciones a las reglas del corrector de estilo. A veces esto se debía a que los/las estudiantes violaban una regla muchas veces (perdiendo así más puntos de los que deberían haber perdido), pero otras veces se debía a que enviaban el código de inicio de tarea con pocas alteraciones y de esa manera obtenían más puntos de los que deberían haber obtenido.

Incluso las herramientas construidas específicamente para enseñar pueden quedar por debajo de las necesidades de los/las docentes. [Keun2016a,Keun2016b] observaron los mensajes producidos por 69 herramientas de calificación automática. Encontraron que estas herramientas a menudo no dan retroalimentación sobre cómo solucionar problemas y dar el siguiente paso. También encontraron que la mayoría de los/las docentes no pueden adaptar fácilmente la mayoría de las herramientas a sus necesidades: como muchas herramientas de flujo de trabajo, tienden a hacer cumplir los supuestos no reconocidos de sus creadores sobre cómo funcionan las instituciones. Tu esquema de clasificación es una buena lista de requisitos para chequear cuando se examinan herramientas de este tipo.

[Buff2015] presenta una reflexión bien documentada sobre la idea de proporcionar una retroalimentación automatizada. Su punto de partida es que, “Los sistemas de calificación automatizados ayudan a los/las estudiantes a identificar errores en su código, [pero] pueden inadvertidamente disuadir a los/las estudiantes de pensar críticamente y probar a fondo y, en cambio, fomentan dependencia con las pruebas del docente". Una de las cuestiones clave que identificaron es que un/una estudiante puede probar a fondo su código, pero es posible que la característica aún no se implemente de acuerdo con las especificaciones del docente. En este caso, el “fallo" no es causado por la falta de pruebas sino por un malentendido de los requisitos, y es poco probable que más pruebas expongan el problema.

Si el sistema de calificación automática no proporciona una retroalimentación que brinde una mejor comprensión y aplicación de los conocimientos, esta experiencia sólo frustrará al estudiante. Con el fin de proporcionar esa retroalimentación, el sistema de [Buff2015] identifica qué métodos en el código del estudiante se ejecutan mediante pruebas fallidas para que el sistema pueda asociar pruebas fallidas con características particulares de lo que envió el/la estudiante. El sistema decide si se han “ganado" ayudas específicas viendo si el/la estudiante ha probado la característica asociada lo suficiente, para evitar que los/las estudiantes se apoyen en las ayudas en vez de realizar las pruebas. En [Srid2016] se describen otros enfoques para compartir la retroalimentación con los/las estudiantes cuando se prueba automáticamente su código. Lo primero es proporcionar la salida esperada para las pruebas—pero luego los/las estudiantes generan la salida conocida incrustando el dato directamente en el código fuente del programa ¹⁷ y dejandola fija para esas entradas (porque todo lo que pueda manipularse se hará).

Lo segundo es informar los resultados de la aprobación o rechazo del código de los/las estudiantes, pero suministrando las entradas y salidas reales de las pruebas solo después de la fecha de envío. Sin embargo, es frustante decirles a los/las estudiantes que se han equivocado pero no decirles por qué. Una tercera opción es utilizar una técnica llamada hashing para generar un valor que depende de la salida pero sin revelarla.

Si el/la usuario/a produce exactamente el resultado correcto entonces su hash desbloqueará la solución, pero es imposible hacer el camino inverso a partir del hash para averiguar cuál se supone que es la salida.

El hashing requiere más trabajo y explicación para configurarlo, pero logra un buen balance entre revelar respuestas prematuramente y no revelarlas cuando podría ser de ayuda.

Razonamientos de alto nivel

Muchos tipos de ejercicios de programación son difíciles de evaluar por los/las docentes en una clase con más de un puñado de estudiantes y son igualmente difíciles de evaluar mediante plataformas automatizadas. Las clases van desarrollándose con vistas a proyectos de programación mayores (si todo va bien), pero la única manera de dar retroalimentación es caso por caso. La revisión de código también es, en general, difícil de calificar automáticamente, pero puede ser abordada si se proporciona a los/las estudiantes una lista de fallos a buscar y se les pide que comparen comentarios con líneas de código concretas.

Por ejemplo, se le puede decir a un/a estudiante que hay dos errores de indentación y un nombre de variable incorrecto y se le puede pedir que los señale.

Si son estudiantes/as más avanzados/as, se les podría dar media docena de tipos de comentarios que podrían hacerse sobre el código sin que se les diga cuántos de cada tipo deberían encontrar.

[Steg2016b] es un buen punto de partida para una rúbrica de estilo de código, mientras que [Luxt2009] muestra la revisión por pares en las clases de programación de manera más general.

Si se pide a los/las estudiantes que hagan revisiones, hay que usar la revisión por pares calibrada (Sección 5.3) para que tengan modelos de cómo debería ser una buena retroalimentación.

Revisión de código

Marca los problemas en cada línea de código usando la rúbrica proporcionada.

01)  def addem(f):
02)      x1 = open(f).readlines()
03)      x2 = [x for x in x1 if x.strip()]
04)      changes = 0
05)      for v in x2:
06)          print('total', total)
07)          tot = tot + int(v)
08)      print('total')

1. nombre de la variable incorrecto	2. uso de variable indefinida
3. falta el valor de salida	4. variable no usada

Ejercicios

Programar y ejecutar (parejas/10’)

Crea un ejercicio corto de programa y ejecuta, luego intercambia con tu pareja y analiza cuánto tiempo les toma a cada uno de ustedes entender y hacer el ejercicio del otro/a.

¿Hubo alguna ambigüedad o malentendido en la descripción del ejercicio?

Invertir el código y la ejecución (grupos pequeños/15’)

Forma grupos de 4 a 6 personas. Haz que cada integrante del grupo cree un ejercicio de programar y ejecutar invertido: el ejercicio debe requerir que las personas averigüen qué entrada produce una salida en particular. Elige dos ejercicios al azar y mira cuántas entradas diferentes que satisfagan los requisitos puede encontrar el grupo.

Siguiendo valores (parejas/10’)

Escribe un programa corto (10-15 líneas), intercambia con tu pareja y sigue cómo las variables del programa cambian de valor con el tiempo. ¿Qué diferencias hay en la forma en que tú y tu pareja escribieron sus seguimientos?

Refactorizar (grupos pequeños/15’)

La clase trabaja en grupos de 3-4 personas.

En cada grupo, cada persona selecciona un fragmento corto de código (10–30 líneas de largo) que haya escrito y que no sea tan ordenado como podría ser. Luego, el/la docente elige un/a estudiante al azar por grupo: todas las personas de la clase ordenan su código independientemente.

¿En qué se diferencian las versiones limpias? ¿Qué tan bien o que tan mal podrían acomodarse todas estas variaciones si se calificara automáticamente, o en una clase grande?

Rotulando un diagrama (parejas/10’)

Dibuja un diagrama mostrando algo que se ha explicado recientemente: cómo los navegadores obtienen datos de los servidores, la relación entre los objetos y las clases, o cómo se indexan los dataframes en R.

Pon las etiquetas en el lateral y pídele a tu pareja que las asigne a cada elemento del diagrama.

Acertijos de lápiz y papel (toda la clase/15’)

[Butl2017] describe un conjunto de rompecabezas de lápiz y papel que pueden convertirse en asignaciones de programación introductorias, señalando que estas tareas son disfrutadas por los/las estudiantes y que fomentan la metacognición. Piensa en un simple rompecabezas de lápiz y papel al que jugabas en tu niñez y describe cómo lo convertirías en un ejercicio de programación.

Contando fallos (parejas/15’)

Cualquier estimación útil de cuánto tiempo se necesita para resolver un ejercicio debe considerar cuán frecuentes son los fallos y cuánto tiempo se pierde con ellos. Por ejemplo, editar archivos de texto parece una tarea sencilla, pero ¿qué pasa con la búsqueda de esos archivos? La mayoría de los editores que usan interfase gráfica guardan archivos en el escritorio o en el directorio personal del usuario/a; si los archivos utilizados en un curso se almacenan en otro lugar, una proporción importante de los/las estudiantes no podrá navegar al directorio correcto sin ayuda. (Si esto te parece un problema menor, por favor vuelve a visitar la discusión del punto ciego de las personas expertas en el Capítulo 3.)

Trabajando con tu pareja, haz una lista de las cosas “simples” que has notado que salen mal en los ejercicios que has usado o tomado.

¿Con qué frecuencia aparecen?

¿Cuánto tiempo tardan los estudiantes en arreglarse por su cuenta o con ayuda?

¿Cuánto tiempo de clase asignas actualmente para lidiar con estos problemas?

Hablando de tiempo (individual/10’)

¿Qué tan precisas han sido las estimaciones de tiempo de los ejercicios de este libro hasta ahora?

Construyendo una comunidad de práctica

No tienes que arreglar todos los males de la sociedad para enseñar programación, pero sí debes involucrarte en lo que sucede fuera de tu clase si quieres que las personas aprendan. Esto se aplica tanto a las personas que enseñan como a las que aprenden: gran parte de las/los docentes free-range deben balancear sus clases con muchos otros compromisos porque su trabajo es voluntario o de medio tiempo. Lo que sucede fuera del aula es tan importante para su éxito como lo es para el de sus estudiantes, así que la mejor manera de ayudar a ambas partes es fomentar una comunidad de enseñanza.

Finlandia y por qué no

Las escuelas de Finlandia se encuentran entre las más exitosas del mundo pero, tal como lo señaló Anu Partanen, su éxito no se explica de manera aislada. Los intentos de otros países por adoptar métodos de enseñanza finlandeses están condenados al fracaso a menos que esos países también garanticen que la niñez (además de sus madres y padres) tengan seguridad, alimentación saludable y reciban un trato adecuado en la administración de justicia  [Sahl2015,Wilk2011]. Esto no es ninguna sorpresa considerando lo que sabemos sobre la importancia de la motivación para el aprendizaje (Capítulo 10): las personas no van a esforzarse por mejorar si creen que el sistema es impredecible, injusto o indiferente.

Un marco para pensar en enseñar a comunidades de práctica es el aprendizaje situado, el cual se centra en cómo la participación inicial legítima motiva a las personas a convertirse en miembros de una comunidad de práctica [Weng2015]. Desglosando estos términos, una comunidad de práctica se refiere a un grupo de personas unidas por su interés en alguna actividad, como tejer o la física de partículas. Una participación inicial legítima implica realizar aquellas tareas simples y de bajo riesgo que la comunidad reconoce como contribuciones válidas: tejer tu primera bufanda, llenar sobres durante una campaña electoral, o revisar documentación de software de código abierto.

El aprendizaje situado se centra en la transición entre ser una persona recién llegada hasta la aceptación como colega por quienes ya son parte de la comunidad. Esto generalmente significa comenzar con tareas y herramientas simples, para después realizar tareas similares con herramientas más complejas y finalmente abordar el mismo trabajo que practicantes avanzadas/os. Por ejemplo, las personas que aprenden música comienzan tocando canciones infantiles con flauta o ukelele, para después tocar otras canciones simples en trompeta o saxofón junto a una banda, y recién entonces comienzan a explorar sus propios gustos musicales. Algunas formas comunes de apoyar esta evolución incluyen:

Resolución de problemas:

“No puedo avanzar — ¿podemos trabajar en el diseño de esta lección conjuntamente?”

Pedidos de información:

“¿Cuál es la contraseña para administrar la lista de correo?”

Búsqueda de experiencia:

“¿Alguien ha tenido una/un estudiante con discapacidad para leer?”

Compartir recursos:

“El año pasado armé un sitio web para una clase que puedes usar como punto de partida”.

Coordinación:

“¿Podemos combinar nuestros pedidos de camisetas para obtener un descuento?”

Construir un argumento:

“Será más fácil convencer a mi jefe de que haga cambios si sé cómo hacen esto en otros talleres”.

Documentar proyectos:

“Ya hemos tenido este problema cinco veces. Vamos a escribirlo de una vez por todas”.

Mapeo de conocimientos:

“¿Qué otros grupos están haciendo algo similar en vecindarios o ciudades cercanas?”

Visitas:

“¿Podemos visitar su programa extracurricular? Necesitamos establecer uno en nuestra ciudad”.

En términos generales, una comunidad de práctica puede ser:

Comunidad de acción:

personas enfocadas en un objetivo compartido, como conseguir que un candidato sea elegido.

Comunidad de cuidado:

en la que las personas integrantes de la comunidad se unen alrededor de un problema compartido, como tratar una enfermedad a largo plazo.

Comunidad de interés:

enfocada en el amor compartido por algo, por ejemplo el backgammon o tejer.

Comunidad de lugar:

personas que viven o trabajan juntas.

La mayoría de las comunidades son mezclas de estos diferentes tipos, como, por ejemplo, las personas en Toronto a las que les gusta enseñar tecnología. El enfoque de una comunidad también puede cambiar con el tiempo: por ejemplo, un grupo de apoyo para personas que padecen depresión (comunidad de cuidado) puede decidir recaudar fondos para mantener una línea de ayuda (comunidad de acción). A partir de entonces, mantener el funcionamiento de la línea de ayuda puede convertirse en el enfoque del grupo (comunidad de interés).

Sopa, luego himnos

Los manifiestos son divertidos de escribir, pero la mayoría de las personas se une a una comunidad para ayudar y recibir ayuda, no para discutir cómo redactar una declaración de visión¹⁸. Por lo tanto, debes centrarte en qué personas pueden crear lo que el resto de la comunidad usará de inmediato. Una vez que tu organización demuestre que puede lograr cosas pequeñas, la gente estará más segura de que vale la pena ayudarte con proyectos más grandes. Ese es el momento de preocuparse por definir los valores que guiarán a tus miembros.

Aprende, luego hazlo

El primer paso para construir una comunidad es decidir si deberías construirla o si sería más efectivo unirte a una organización existente. Miles de grupos ya están enseñando habilidades tecnológicas, desde el 4-H Club y programas de alfabetización hasta organizaciones de programación sin fines de lucro como Black Girls Code (Chicas Negras Programan, en inglés) y Bridge (Puente, en inglés). En los últimos años estas comunidades de práctica se han desarrollado también en Latinoamérica, desde aquellas que enseñan habilidades para enseñar como MetaDocencia, las que intentan achicar la brecha de genero en STEAM como GeoLatinas, Las de Sistemas y Mujeres en Tecnología hasta las que son parte de las organizaciones globales como los capítulos de R-Ladies (Mujeres de R en inglés) y PyLadies (Mujeres de Python en inglés). Unirse a un grupo existente te dará ventajas en la enseñanza, un conjunto inmediato de colegas y la oportunidad de aprender más sobre cómo manejar las cosas; Con suerte, aprender esas habilidades a la par que haces una contribución inmediata será más importante que poder decir que eres la persona que fundó algo nuevo.

Ya sea que te unas a un grupo existente o inicies uno propio, tu efectividad será mayor si investigas un poco sobre organización de comunidades. [Alin1989,Lake2018] son probablemente los trabajos más conocidos sobre organización de grupos de base, mientras que  [Brow2007,Midw2010,Lake2018] son manuales prácticos basados en décadas de experiencia. Si quieres leer más profundamente, [Adam1975] es la historia de la Highlander Folk School, cuyo enfoque ha sido emulado por muchos grupos exitosos, mientras que  [Spal2014] es una guía para enseñar a personas adultas escrita por alguien con profundas raíces personales en la organización de grupos de base y NonprofitReady.org ofrece capacitación profesional gratuita.

Cuatro pasos

Todas las personas que se involucren con tu organización (incluyéndote) pasan por cuatro fases: reclutamiento, incorporación, retención y retiro. No necesitas preocuparte por este ciclo cuando estés gestando una comunidad, pero sí cuando llegues al punto en que se involucren más de un puñado de personas no fundadoras.

El primer paso es reclutar voluntarias/os. Tu estrategia de marketing debería ayudarte con esto, al garantizar que tu organización sea localizable y al lograr que la misión y valor sean claros para las personas que quieran involucrarse (Capítulo 14). Comparte historias que ejemplifiquen el tipo de ayuda que buscas así como historias sobre las personas a las que estás ayudando, y deja en claro que hay muchas maneras de involucrarse (discutiremos esto con más detalle en la siguiente sección).

La mejor fuente de potenciales reclutas son tus propias clases: el método “verlo, practicarlo, enseñarlo” ha funcionado bien para organizaciones voluntarias desde que las organizaciones voluntarias existen. Asegúrate de que cada clase u otro tipo de encuentro termine informando a las personas cómo pueden ayudar y que su ayuda será bienvenida. De esta manera, las personas que se acerquen a ti sabrán lo que haces y habrán tenido la experiencia reciente de ser receptores de lo que ofreces, lo que contribuye a que tu organización evite el punto ciego de la persona experta a nivel de la comunidad (Capítulo 3).

Empieza pequeño

Pedirle a una persona que haga algo pequeño por ti es un buen paso para lograr que haga algo más grande. Esto se basa en el efecto Ben Franklin: quien ya le ha hecho un favor a alguien es más propensa/o a hacerle otro favor a la misma persona, (en comparación con la disposisión que tiene quien ha recibido un favor). En el marco de una comunidad de enseñanza, puedes solicitar correcciones de redacción o de errores ortográficos en los materiales de tus lecciones, o sugerencias de nuevos ejercicios o ejemplos. Escribir tus materiales de una manera mantenible (Sección 6.3), le da a tu comunidad la oportunidad de practicar algunas habilidades útiles y te permite a ti comenzar una conversación que podría conducir a sumar una nueva persona.

La mitad del ciclo de vida de una persona voluntaria es la incorporación y la retención, que cubriremos en las Secciones  13.3 y  13.4. El último paso es cuando alguien deja de ser parte de la organización: eventualmente, el resto de las personas siguen adelante, y las organizaciones saludables se preparan para ese momento. Algunas cosas simples pueden generar una sensación positiva ante el cambio, tanto para la persona que se va como para todas las que se quedan:

Pide a las personas ser explícitas sobre su partida

para que el resto sepa que realmente se han ido.

Asegúrate de que no se sientan con vergüenza por irse

o por cualquier otro motivo.

Dales la oportunidad de transmitir sus conocimientos.

Por ejemplo, puedes pedirles que asesoren a alguien durante algunas semanas como su última contribución, o que sean entrevistadas/os por alguien que se queda en la organización para recopilar cualquier historia que valga la pena volver a contar.

Asegúrate de que entreguen las llaves.

Es incómodo descubrir, seis meses después de que alguien se fue, que esa era la única persona que sabía cómo reservar un lugar para el picnic anual.

Haz un seguimiento 2 a 3 meses después de que se vayan

para ver si tienen más ideas sobre lo que funcionó y lo que no funcionó mientras estuvieron contigo, o algún consejo para ofrecer que tampoco pensaron dar o que se sentían incómodas/os de dar mientras se iban.

Agradéceles,

tanto cuando se van como la próxima vez que tu grupo se reúna.

El manual que falta

Se han escrito miles de libros sobre cómo iniciar una empresa. Solo unos pocos describen cómo cerrar una o cómo dejarla sin problemas, a pesar de que existe un final para cada comienzo. Si alguna vez escribes uno, por favor házmelo saber.

Incorporación

Después de decidir formar parte de un grupo, la gente necesita ponerse al día, y [Shol2019] resume lo que sabemos al respecto. La primera regla es tener y hacer cumplir un código de conducta (Sección 9.1) y encontrar alguien independiente a tu comunidad que acepte recibir y revisar informes de comportamiento inapropiado. Alguien fuera de la organización tendrá la objetividad de la que las/los integrantes pueden carecer. Además, una persona externa puede proteger a quienes dudan si denunciar incidentes relacionados a las personas a cargo de proyectos por temor a represalias o daños a su reputación. El equipo que lidera el proyecto debe hacer públicas las decisiones donde se aplique el código de conducta para que la comunidad reconozca que realmente se toma en serio, que se aplica y se le da relevancia.

La siguiente regla más importante es ser amigable. Como dijo Fogel  [Foge2005], “Si un proyecto no hace una buena primera impresión, quienes recién llegan van a esperar mucho tiempo antes de darle una segunda oportunidad.” Otras investigaciones han confirmado empíricamente la importancia de entornos sociales, amables y educados en proyectos abiertos [Sing2012,Stei2013,Stei2018]:

Publica un mensaje de bienvenida

en las páginas de redes sociales, canales de comunicación de tu comunidad, foros o listas de correo electrónico del proyecto. Los proyectos podrían considerar mantener un canal o lista de “Bienvenida”, donde alguna de las personas que lideran el proyecto o gestiona la comunidad escribe una breve publicación pidiendo que quienes recién llegan se presenten.

Ayuda a las personas a hacer una contribución inicial,

por ejemplo, puedes etiquetar lecciones particulares o talleres que necesitan trabajo como “adecuados para las personas recién llegadas” y pedir a miembros ya establecidos que no las arreglen. De esta forma se aseguran lugares adecuados para que las personas recién llegadas comiencen a trabajar.

Dirige a las personas recién llegadas hacia miembros similares a ellas

para demostrarles que pertenecen a tu comunidad.

Comparte los recursos esenciales del proyecto con las personas recién llegadas,

tal como las normas y pautas para contribuir.

Designa una o dos personas del proyecto como contacto

para cada persona nueva. Esto puede hacer que quienes recién llegan sean menos reticentes a formular preguntas.

Una tercera regla que ayuda a todas las personas (no solo a quienes recién llegan) es hacer que el conocimiento esté actualizado y a disposición. Las personas nuevas son como exploradoras/es que deben orientarse dentro de un paisaje desconocido [Dage2010]. La información dispersa hace que las nuevas personas se sientan perdidas y desorientadas. Considerando las diferentes opciones de lugares para mantener información, (por ejemplo, wikis, archivos en un repositorio con control de versiones, documentos compartidos, tweets antiguos, mensajes en un chat grupal o archivos de correo electrónico) es importante mantener la información sobre un tema específico consolidada en un único lugar, de modo que las personas nuevas no naveguen por múltiples fuentes de datos para encontrar lo que necesitan. Organizar la información hace que las personas recién llegadas tengan más confianza y mejor orientación [Stei2016].

Finalmente, reconoce las primeras contribuciones de quienes recién comienzan y piensa dónde y cómo podrían ayudar a largo plazo. Una vez realizada su primera contribución, es probable que tengan una mejor idea de lo que pueden ofrecer y cómo el proyecto puede ayudarles. Ayuda a las personas nuevas a encontrar el siguiente problema en el que tal vez quieran trabajar o guiales hacia el siguiente tema que podrían disfrutar leyendo. En particular, animarles a ayudar a la próxima ola de nuevas personas es una buena manera de reconocer lo que han aprendido y una forma efectiva de transmitirlo.

Retención

Si tu gente no la está pasando bien, algo está muy mal.
— Saul Alinsky

Quienes participan de la comunidad no deberían esperar disfrutar cada momento de su trabajo con tu organización, pero si no disfrutan ninguno no se quedarán. Disfrutar no significa necesariamente tener una fiesta anual: la gente puede disfrutar cocinar, entrenar a otras personas o simplemente trabajar en silencio junto al resto del grupo. Hay varias cosas que toda organización debe hacer para garantizar que las personas tengan algo que valoran de su trabajo:

Pregunta a las personas qué quieren en vez de adivinar.

Así como no eres tus estudiantes (Sección 6.1), probablemente seas diferente a otras personas de tu organización. Pregunta a las personas qué quieren hacer, qué se sienten cómodas haciendo (que puede no ser lo mismo), y qué limitaciones de tiempo tienen. Pueden decir: “Cualquier cosa”, pero incluso una breve conversación probablemente ayude a descubrir que les gusta interactuar con las personas pero preferirían no administrar las finanzas del grupo, o viceversa.

Proporciona muchas formas de contribuir.

Cuantas más formas haya para que las personas ayuden, más gente podrá hacerlo. Alguien a quien no le gusta estar frente a público puede mantener el sitio web de su organización, manejar sus cuentas o corregir las lecciones.

Reconoce las contribuciones.

A todas/os nos gusta que nos aprecien, así que las comunidades deben reconocer las contribuciones de sus miembros, tanto en público como en privado, mencionándolas/os en presentaciones, poniéndolas en el sitio web, etc. Cada hora que alguien le haya dado a tu proyecto puede ser una hora restada de su vida personal o de su empleo oficial; reconoce ese hecho y deja en claro que, si bien más horas serían bienvenidas, no esperas que hagan sacrificios insostenibles.

Haz espacio.

Crees que estás siendo útil, pero intervenir en cada decisión priva de autonomía a las demás personas, lo que reduce su motivación (Sección 10). En particular, si siempre eres quien responde primero a correos electrónicos o mensajes de chat, las personas tienen menos oportunidades de crecer como miembros y crear colaboraciones horizontales. Como resultado, la comunidad continuará centrada en una o dos personas en lugar de convertirse en una red altamente conectada en la que otras/os se sientan cómodas/os participando.

Otra forma de recompensar la participación es ofrecer capacitación. Las organizaciones necesitan presupuestos, propuestas de subsidios y resolución de disputas. A la mayoría de las personas no se les enseña cómo hacer estas tareas más de lo que se les enseña a enseñar, así que la oportunidad de adquirir habilidades transferibles es una razón poderosa para que las personas se involucren y se mantengan involucradas. Si vas a hacer esto, no intentes proporcionar la capacitación por tu cuenta a menos que sea en lo que te especializas. Muchos grupos cívicos y comunitarios tienen programas de este tipo y probablemente puedas llegar a un acuerdo con alguno de ellos.

Finalmente, si bien las personas voluntarias pueden hacer mucho, tareas como la administración del sistema y la contabilidad eventualmente necesitan personal remunerado. Cuando llegues a este punto, o no pagas nada o pagas un salario adecuado. Si no les paga nada, su verdadera recompensa es la satisfacción de hacer el bien; por otro lado, si les pagas una cantidad simbólica, le quitas esa satisfacción sin darles la posibilidad de ganarse la vida.

Gobernanza

Cada organización tiene una estructura de poder: la única pregunta es si es formal y deriva en responsabilidades, o informal y, por lo tanto, no hay responsabilidades explícitas [Free1972]. La estructura informal funciona bastante bien para grupos de hasta media docena de personas en los que todas las personas se conocen. Si el grupo es más grande, necesitas reglas para explicar quién tiene la autoridad para tomar qué decisiones y cómo lograr consensos (Sección 20.1).

El modelo de gobernanza que prefiero es del tipo cooperativo, conocido como commons en inglés. La gobernanza cooperativa es una manera de gestión conjunta realizada por una comunidad de acuerdo a las reglas que ella misma ha desarrollado y adoptado [Ostr2015]. Como subraya  [Boll2014], las tres partes de esta definición son esenciales: la gobernanza es cooperativa no solo porque hay un bien compartido, como una propiedad o un conjunto de bibliotecas de software, sino que también se incluye a la comunidad que comparte estos recursos y a las reglas que usan para hacerlo.

Los modelos más populares son los de corporaciones con fines de lucro y los de organizaciones sin fines de lucro (aunque no todos son necesariamente de gobernanza cooperativa). La mecánica varía de una jurisdicción a otra, por lo que debes buscar asesoramiento antes de elegir¹⁹. Ambos tipos de organización otorgan la máxima autoridad a su directorio. En términos generales, se trata de un directorio de servicio con miembros que también asumen otras funciones en la organización o un directorio de gobernanza o simplemente directorio cuya responsabilidad principal es contratar, supervisar y, si es necesario, despedir a quien dirige la organización. Las/los integrantes del directorio pueden ser elegidos por la comunidad o nombrados; en cualquier caso, es importante priorizar la capacidad sobre la pasión (la última es más importante para las bases) y tratar de reclutar habilidades particulares como contabilidad, marketing, etc.

Elige la democracia

Cuando llegue el momento, haz de tu organización una democracia: tarde o temprano (generalmente más temprano que tarde), cada directorio o junta designada se convierte en una sociedad de mutuo acuerdo. Darle poder a tus miembros es complicado, pero es la única forma inventada hasta ahora para garantizar que las organizaciones continúen satisfaciendo las necesidades reales de las personas.

Cuidarte y cuidar a tu comunidad

El síndrome de desgaste ocupacional (burnout en inglés) es un riesgo crónico en cualquier actividad comunitaria [Pign2016], así que aprende a decir no más seguido de lo que dices sí. Si no te cuidas, no podrás cuidar a tu comunidad.

Quedándose sin “No”

Investigaciones en la década de 1990 parecían mostrar que nuestra capacidad de ejercer fuerza de voluntad es finita: si tenemos que resistirnos a comer el último bombón de la caja cuando tenemos hambre, somos menos propensas/os a doblar la ropa, y viceversa. Este fenómeno se llama agotamiento del ego y si bien estudios recientes no han podido replicar esos primeros resultados [Hagg2016], decir “sí” cuando estamos demasiado cansados para decir “no” es una trampa en la que caen muchos organizadores.

Una forma de asegurarte de cumplir con tu “no” es escribir una lista de no-tareas, en la que anotes cosas que vale la pena hacer pero que no vas a hacer. Al momento de escribir este libro, mi lista incluye cuatro libros, dos proyectos de software, el rediseño de mi sitio web personal y aprender a tocar la flauta irlandesa.

Finalmente, recuerda de vez en cuando que eventualmente toda organización necesita ideas frescas y nuevo liderazgo. Cuando llegue ese momento, entrena a tus sucesoras/es y sigue adelante con la mayor gracia posible. Indudablemente tomarán decisiones que tú no harías, pero pocas cosas en la vida son tan satisfactorias como ver que algo que ayudaste a construir cobra vida propia. Celebra eso — no tendrás ningún problema para encontrar otra actividad que te mantenga ocupada/o.

Ejercicios

Varios de estos ejercicios se toman de [Brow2007].

¿Qué tipo de comunidad? (individual/15’)

Vuelve a leer la descripción de los cuatro tipos de comunidades y decide con cuál o cuáles se identifican o a cuales aspiran.

Personas que puedes conocer (grupos pequeños/30’)

Al organizar una comunidad, parte de tu trabajo es ayudar a las personas a encontrar una manera de contribuir a pesar de sí mismas. En grupos pequeños, elige tres de las personas descriptas a continuación y discute cómo les ayudarías a convertirse en mejores colaboradoras/es para tu organización.

Ana

sabe más sobre cada tema que todas las demás personas juntas — al menos, ella cree que lo hace. No importa lo que digas, ella te corregirá; no importa lo que sepas, ella lo sabe mejor.

Catalina

tiene tan poca confianza en su propia habilidad que no tomará ninguna decisión, sin importar qué tan pequeña sea, hasta haber consultado con alguien más.

Fernando

disfruta de saber cosas que otras personas no saben. Puede hacer milagros, pero cuando se le pregunta cómo lo hizo, sonreirá y dirá: “Oh, estoy seguro de que puedes resolverlo”.

Andrea

es tranquila. Nunca habla en las reuniones, incluso cuando sabe que otras personas están equivocadas. Podría contribuir a la lista de correo, pero es muy sensible a las críticas y siempre retrocede en lugar de defender su punto.

Cristian

aprovecha el hecho de que la mayoría de las personas preferirían hacer su parte del trabajo antes que quejarse de él. Lo frustrante es que él es muy convincente cuando alguien finalmente lo confronta. “Todas las partes han cometido errores,” dice él, o “Bueno, creo que estás siendo un poco quisquillosa/o.”.

Melisa

tiene buenas intenciones pero, por alguna razón, siempre surge algo y termina sus tareas a último momento. Por supuesto, eso significa que quienes dependen de ella no pueden hacer su trabajo hasta después de ese último momento …

Juan José

es grosero. “Esa es la forma en que hablo”, dice. “Si no puedes solucionarlo, ve a buscar otro equipo”. Su frase favorita es: “Eso es estúpido” y dice una obscenidad cada segunda oración.

Valores (grupos pequeños/45’)

Responde estas preguntas por tu cuenta y luego compara tus respuestas con las del resto del grupo.

1. ¿Cuáles son los valores que expresa tu organización?

2. ¿Son estos los valores que deseas que la organización exprese?

3. Si tu respuesta es no, ¿qué valores te gustaría expresar?

4. ¿Cuáles son los comportamientos específicos que demuestran esos valores?

5. ¿Qué comportamientos demostrarían lo contrario de esos valores?

Procedimientos para reuniones (grupos pequeños/30’)

Responde estas preguntas por tu cuenta y luego compara tus respuestas con las del resto del grupo.

1. ¿Cómo se manejan las reuniones?

2. ¿Es así como quieres que se realicen tus reuniones?

3. ¿Las reglas para conducir reuniones son explícitas o simplemente se asumen?

4. ¿Estas son las reglas que quieres tener?

5. ¿Quién tiene derecho a votar o tomar decisiones?

6. ¿Son estas las personas a quienes quisieras otorgar autoridad para tomar decisiones?

7. ¿Utilizan la regla de la mayoría, toman decisiones por consenso o usan otro mecanismo?

8. ¿Es así como quieres tomar decisiones?

9. ¿Cómo se enteran las personas en una reunión que se ha tomado una decisión?

10. ¿Cómo saben las personas que no estuvieron en una reunión qué decisiones se tomaron?

11. ¿Funciona esto para tu grupo?

Tamaño (grupos pequeños/20’)

Responde estas preguntas por tu cuenta y luego compara tus respuestas con las del resto del grupo.

1. ¿Qué tan grande es tu grupo?

2. ¿Es este el tamaño que deseas para su organización?

3. Si tu respuesta es no, ¿de qué tamaño te gustaría que fuera?

4. ¿Tienes algún límite en cuanto a la cantidad de miembros?

5. ¿Te beneficiarías de establecer ese límite?

Convertirse en miembro (grupos pequeños/45)

Responde estas preguntas por tu cuenta y luego compara tus respuestas con las del resto del grupo.

1. ¿Cómo se incorpora alguien a tu grupo?

2. ¿Qué tan bien funciona este proceso?

3. ¿Hay cuotas de membresía?

4. ¿Se requiere que las personas estén de acuerdo con alguna regla de comportamiento al unirse?

5. ¿Son estas las reglas de comportamiento que quieres?

6. ¿Cómo descubren las personas recién llegadas lo que hay que hacer?

7. ¿Qué tan bien funciona este proceso?

Contrataciones (grupos pequeños/30’)

Responde estas preguntas por tu cuenta y luego compara tus respuestas con las del resto del grupo.

1. ¿Tienes personal asalariado en tu organización o son todas/os voluntarias/os?

2. ¿Deberías tener personal asalariado?

3. ¿Quieres / necesitas más o menos personal?

4. ¿Qué hace cada integrante de tu personal? ¿A qué se dedica?

5. ¿Son estos los roles y funciones principales que necesitas que el personal desempeñe?

6. ¿Quién supervisa a tu personal?

7. ¿Es este el proceso de supervisión que quieres para tu grupo?

8. ¿Cuánto le pagan a tu personal?

9. ¿Es este el salario adecuado para realizar el trabajo necesario?

Dinero (grupos pequeños/30’)

Responde estas preguntas por tu cuenta y luego compara tus respuestas con las del resto del grupo.

1. ¿Quién paga qué?

2. ¿Esa es la persona que quisieras que pague?

3. ¿De dónde consiguen el dinero?

4. ¿Es así como quieres conseguirlo?

5. Si no, ¿tienes algún plan para conseguirlo de otra manera?

6. Si es así, ¿cuáles son esos planes?

7. ¿Quién da seguimiento a estos planes para asegurarse de que sucedan?

8. ¿Cuánto dinero tienen?

9. ¿Cuánto dinero necesitan?

10. ¿En qué gastan la mayor parte del dinero?

11. ¿Es así como quieres gastar el dinero?

Tomando ideas prestadas (toda la clase/15’)

Muchas de mis ideas sobre cómo construir una comunidad han sido moldeadas por mi experiencia en el desarrollo de software de código abierto. [Foge2005] (que está disponible en línea) es una buena guía de lo que ha funcionado y lo que no ha funcionado para esas comunidades, y el sitio de Guías de Código Abierto también tiene una gran cantidad de información útil. Elige una sección de este último recurso, puede ser “Encontrando Usuarios para Tu Proyecto”, o “Liderazgo y Gobierno” y presenta al grupo, en dos minutos, una idea que encontraste útil o una con la que estuviste muy en desacuerdo.

¿Quién eres tú? (grupos pequeños/20’)

La Administración Nacional Oceánica y Atmosférica estadounidense (NOAA por sus siglas en inglés) tiene una guía breve, útil y divertida para lidiar con comportamientos disruptivos. La guía clasifica esos comportamientos bajo etiquetas como “habladora/hablador”, “indecisa/o” y “tímida/o” y describe estrategias para manejar cada uno. En grupos de 3 a 6 personas, lean la guía (está disponible solo en inglés) y decidan cuál de las descripciones les queda mejor. ¿Crees que las estrategias descriptas para manejar personas como tú son efectivas? ¿Son otras estrategias igualmente efectivas o más?

Creando lecciones en comunidad (grupos pequeños/30’)

Una de las claves del éxito de Carpentries es su énfasis en construir y mantener lecciones en forma colaborativa [Wils2016,Deve2018]. Trabajando en grupos de 3 a 4 personas:

1. Elige una lección breve que todo el grupo haya usado.

2. Haz una revisión cuidadosa para crear una única lista con sugerencias de mejoras.

3. Ofrece esas sugerencias a las/los autoras/es de la lección.

¿Estás crujiente? (individual/10’)

Johnathan Nightingale escribió:

Cuando trabajaba en Mozilla, utilizábamos el término “crujiente” (crispy en inglés) para referirnos al estado justo antes de llegar al síndrome de desgaste ocupacional. Las personas que son crujientes no son divertidas. Son bruscas. Están ansiosas por una pelea que pueden ganar. Lloran sin mucha advertencia. … reconocíamos lo “crujiente” en nuestros colegas y nos cuidábamos mutuamente [pero] es una cosa tan fea, que vimos tanto, que teníamos un proceso cultural completo a su alrededor.

Responde “sí” o “no” a cada una de las siguientes preguntas. ¿Qué tan cerca estás de tener síndrome de desgaste ocupacional?

• ¿Te has vuelto cínica/o o crítica/o en el trabajo?

• ¿Tienes que arrastrarte al trabajo o tienes problemas para comenzar a trabajar?

• ¿Te has vuelto irritable o impaciente con tus compañeros de trabajo?

• ¿Te resulta difícil concentrarte?

• ¿No logras satisfacción con tus logros?

• ¿Estás usando comida, drogas o alcohol para sentirte mejor o simplemente no sentir?

Difusión y vinculación

Está de moda en los círculos tecnológicos menospreciar a las universidades y las instituciones gubernamentales como si fueran dinosaurios lentos, pero en mi experiencia no son peores que empresas de tamaño similar. El consejo de la escuela local, la biblioteca, la alcaldía o municipio pueden ofrecer espacio, financiación, publicidad, conexiones con otros grupos con los que aún no te has encontrado y una serie de otras cosas útiles. Conocer estas posibilidades puede ayudar a resolver o evitar problemas a corto plazo y generar beneficios en el futuro.

Marketing

Las personas con antecedentes académicos y técnicos a menudo piensan que el marketing se trata de confundir y engañar. En realidad, trata sobre ver cosas desde la perspectiva de otras personas, comprendiendo sus deseos y necesidades, y explicando cómo puedes ayudarlas—en pocas palabras, cómo enseñarles. Este capítulo analizará cómo usar ideas de los capítulos anteriores para hacer que las personas entiendan y apoyen lo que estás haciendo.

El primer paso es averiguar qué le ofreces a cada persona, es decir, lo que realmente atrae a voluntarios/as, fondos y otro tipo de apoyo que puedas necesitar para continuar. La respuesta es contra-intuitiva. Por ejemplo, la mayoría de los/las científicos/as creen que los artículos científicos (conocidos como papers) que publican en revistas académicas son sus productos, pero en realidad los productos son los proyectos que presentan a convocatorias de subsidios: son estos proyectos los que atraen el dinero [Kuch2011]. Los artículos científicos son la publicidad que convence a otras personas de financiar esas propuestas, así como los álbumes son los que convencen a la gente de comprar entradas a conciertos y camisetas de bandas musicales.

Imagina que tu grupo ofrece talleres de programación de fin de semana a personas que están reinsertándose a la actividad laboral después de haber estado inactivas por varios años. Si quienes participan del taller pueden pagar lo suficiente para cubrir tus costos, entonces son tus clientes y el taller es tu producto. Si por otro lado, los talleres son gratuitos o tus estudiantes sólo están pagando un monto simbólico para reducir la tasa de ausencias, entonces tu producto real puede ser una mezcla de:

• tus propuestas de proyectos para solicitar subsidios;

• las personas que terminan exitosamente tus talleres a las que las empresas que te patrocinaron les gustaría contratar;

• el resumen de media página de tus talleres que quien gobierna incluye en el balance o resumen anual presentado al concejo deliberante, que muestra cómo apoya al sector tecnológico local; o

• la satisfacción personal que obtienen los/las voluntarios/as cuando enseñan.

Al igual que el diseño de lecciones (Capítulo 6), los primeros pasos en marketing son crear las personas tipo de la gente que podría estar interesada en lo que estás haciendo, y averiguar cuáles de sus necesidades puedes cumplir. Una manera de resumir lo último es escribir discursos de presentación dirigidos a diferentes personas tipo. Una plantilla ampliamente utilizada para este objetivo es:

Para	objetivo de público
quien	insatisfacción con lo que está disponible actualmente
nuestros/as	categoría
proveen	beneficio clave.
A diferencia de	alternativas
nuestro programa	característica distintiva clave.

En el ejemplo del taller de fin de semana, podríamos usar este tono para los/las participantes

Para personas que regresan a la actividad laboral después de estar inactivas por varios años quienes tienen todavía responsabilidades familiares, nuestros talleres introductorios de programación proveen clases los fines de semana con guardería incluida. A diferencia de las clases en línea, nuestro programa le da a la gente la oportunidad de conocer a otras personas en la misma etapa de la vida.

y este otro discurso de presentación para quienes toman decisiones en las empresas que podrían patrocinar los talleres:

Para empresas que quieren reclutar desarrolladores/as de software de nivel básico quienes tienen dificultades para encontrar candidatos/as con suficiente madurez en diversas formaciones nuestros talleres introductorios de programación proveen potenciales candidatos/as. A diferencia de una feria de reclutamiento universitario, nuestro programa conecta empresas con una gran variedad de candidatos/as.

Si no sabes por qué diferentes patrocinadores/as potenciales podrían estar interesados/as en lo que haces, pregúntales. Si lo sabes, pregúntales igual: las respuestas pueden cambiar con el tiempo, y puedes descubrir cosas que no habías notado antes.

Estos discursos de presentación, una vez elaborados, deberían guiar lo que publicas en tu sitio web y en el material de difusión, para ayudar a la gente a descubrir lo más rápido posible si tú y ellos tienen algo de qué hablar. (No deberías copiar los discursos textualmente, porque muchas personas en el área tecnológica han visto esta plantilla tantas veces que perderán el interés si vuelven a leerla.)

Mientras escribes estos discursos, recuerda que hay varias razones para aprender cómo programar (Sección 1.4). Una sensación de logro, control sobre sus propias vidas y ser parte de una comunidad puede motivar a las personas más que el dinero (Capítulo 10).

Algunas personas podrían ofrecerse a enseñar contigo de forma voluntaria porque sus amistades lo están haciendo. Igualmente, una empresa puede decir que está patrocinando clases para estudiantes de secundaria en condiciones económicas desfavorables porque quiere tener un grupo más grande de empleados potenciales en el futuro, aunque quizás quien dirige la empresa lo podría estar haciendo simplemente porque es lo correcto.

Marcas y posicionamiento

Una marca es la primera reacción de una persona a la mención de un producto; si la reacción es “¿Qué es eso?”, todavía no tienes una marca. La marca es importante porque la gente no va a ayudar a algo que no conoce o no le importa.

La mayor parte de la discusión actual sobre las marcas se enfoca en cómo crear reconocimiento en línea. Las listas de correo, los blogs y Twitter te dan maneras de llegar a la gente, pero a medida que aumenta el volumen de desinformación, la gente presta menos atención a cada interrupción individual.

Esto hace que el posicionamiento sea cada vez más importante. A veces llamado “diferenciación”, es lo que distingue tu oferta de las otras: la sección “a diferencia de” de tu discurso de presentación. Cuando te comunicas con personas que están familiarizadas con tu campo, debes enfatizar el posicionamiento, ya que es eso lo que llamará su atención.

Hay otras cosas que puedes hacer para ayudar a construir tu marca. Una de ellas es usar ejemplos de éxito, como un robot que una de tus estudiantes hizo a partir de piezas que encontró en su casa [Schw2013] o el sitio web que otro estudiante hizo para el geriátrico sus padres.

Otra opción es hacer un video corto—no más de unos pocos minutos de duración— que resalte los antecedentes y logros de tus estudiantes. El objetivo de los ítems anteriores es contar una historia: mientras que la gente siempre pide datos, lo que creen y recuerdan son las historias.

Mitos fundacionales

Una de las historias más convincentes que una persona o grupo puede contar es por qué y cómo comenzaron. ¿Estás enseñando algo que desearías que alguien te hubiera enseñado pero no lo hizo? ¿Había una persona en particular a la que querías ayudar y eso abrió las puertas?

Si no hay una sección en tu sitio web que comience con “Había una vez”, piensa en agregar una.

Un paso crucial es lograr que tu organización sea encontrada en las búsquedas en internet. [DiSa2014b] descubrió que las clases de computación fuera de la escuela no eran encontradas con los términos de búsqueda que los padres y las madres utilizaban. Otros tipos de clases u organizaciones se enfrentan a desafíos similares. Hay mucho mito sobre técnicas para hacer que las cosas puedan ser encontradas en internet (lo que a veces se refiere como motor de optimización de posicionamiento en buscadores o SEO por su sigla en inglés (“Search Engine Optimization”)). Dado el poder casi-monopólico y la falta de transparencia de Google, la mayor parte de estas estrategias se reduce a estar un paso por delante de los algoritmos diseñados para prevenir a las personas sobre rankings manipulados, sesgados o poco realistas.

A menos que tengas muy buena financiación, lo mejor que puedes hacer es hacer búsquedas regulares de tu organización y de ti en internet para ver qué encuentras. Con esa información puedes leer estas guías (en inglés) y hacer lo que esté a tu alcance para mejorar tu sitio. Ten en mente esta viñeta de XKCD (en inglés): la gente no quiere saber sobre tu organigrama u obtener un recorrido virtual de su sitio—las personas quieren tu dirección, información sobre estacionamiento cerca y alguna idea de lo que enseñas, cuándo lo enseñas y cómo va a cambiar sus vidas.

No todo el mundo vive en línea

Estos ejemplos asumen que la gente tiene acceso a internet y que los grupos tienen dinero, materiales, tiempo libre y/o habilidades técnicas. La mayoría no tiene estos recursos—de hecho, aquellos que trabajan con grupos económicamente desfavorecidos muy probablemente no los tengan. (Como Rosario Robinson dice, “Gratis funciona para aquellas personas que pueden permitirse lo gratuito.”) Las historias son más importantes que el programa del curso en esas situaciones, porque son más fáciles de volver a contar. Igualmente, si las personas a las que esperas llegar no están en línea tan a menudo como tú, entonces publicar avisos en las carteleras de las escuelas, en bibliotecas locales, en centros de ayuda, y en los mercados y tiendas puede ser la forma más efectiva de llegar a tu público.

El arte de la llamada en frío

Crear un sitio web y esperar que las personas lo encuentren es fácil; llamar por teléfono o golpear en las puertas de sus casas sin ningún tipo de introducción previa es mucho más difícil. Al igual que ponerse de pie y enseñar, sin embargo, es un oficio que puede aprenderse. Aquí hay diez reglas simples para convencer a las personas:

1: No lo hagas

Si tienes que convencer a alguien de hacer algo, lo más probable es que realmente no quieran hacerlo. Respeta eso: casi siempre es mejor a largo plazo dejar algo en particular sin hacer que usar la culpa o cualquier truco psicológico encubierto que sólo generará resentimiento.

2: Sé amable.

No sé si existe un libro llamado Trucos secretos de los maestros ninja de ventas, pero si existe, probablemente le dice a sus lectores que hacer algo por un cliente potencial crea un sentido de obligación, lo que a su vez aumenta las probabilidades de una venta. Esto puede funcionar, pero solo funciona una vez y no es una práctica recomendable. Por otro lado, si eres genuinamente amable y ayudas a otras personas porque eso es lo que las buenas personas hacen, sólo podrías inspirarlas a ser buenas personas también.

3: Apela al bien mayor.

Si comienzas hablándole a las personas sobre lo que hay disponible para ellas, les estás señalando que deberían pensar en su interacción contigo como si se tratara de un intercambio comercial que se puede negociar. En cambio, comienza explicando cómo su aporte y ayuda puede hacer del mundo un lugar mejor y dilo en serio. Si lo que estás proponiendo no va a hacer del mundo un lugar mejor, debes mejorar tu propuesta.

4: Comienza por algo pequeño.

La mayoría de las personas son comprensiblemente reacias a sumergirse de lleno en las cosas, así que debes darles la oportunidad de conocer el terreno y conocerte a ti y a las demás personas involucradas en lo que sea que necesites ayuda. No te sorprendas o decepciones si ahí es donde terminan las cosas: todo el mundo está ocupado o cansado o tiene proyectos propios, o tal vez simplemente tiene un modelo mental diferente de cómo se supone que funcionan las colaboraciones. Recuerda la regla 90-9-1– el 90% va a mirar, el 9% va a hablar y el 1% realmente va a hacer cosas—ajusta tus expectativas de modo acorde.

5: No construyas un proyecto: construye una comunidad.

Solía pertenecer a un equipo de béisbol que nunca jugaba realmente al béisbol: nuestros “juegos“ eran sólo una excusa para que estuviéramos juntos y disfrutemos de la compañía de las demás personas. Probablemente no quieras llegar tan lejos, pero compartir una taza de té con alguien o celebrar el cumpleaños de su nieto/a pueden darte cosas que no podrías obtener con ninguna cantidad razonable de dinero.

6: Establece un punto de conexión.

“Estaba hablando con X” o “Nos conocimos en Y” les da contexto, lo que a su vez hace sentir más cómodas a las personas. Esto debe ser específico: quienes envían correo basura y quienes hacen llamadas en frío nos han entrenado para ignorar cualquier cosa que comience con la frase “Hace poco tiempo encontré tu sitio web …”

7: Sé específico/a sobre lo que estás pidiendo.

Este detalle es necesario para que las personas puedan determinar si el tiempo y las habilidades que tienen coinciden con lo que necesitas. Ser realista desde el principio también es una señal de respeto: si le dices a alguien que necesitas una mano para mover algunas cajas cuando en realidad estás mudando una casa entera, probablemente no te ayudarán por segunda vez.

8: Establece tu credibilidad.

Menciona a quienes te patrocinan, tu tamaño, cuánto tiempo hace que existe tu grupo o algo que hayas logrado en el pasado para que las personas crean que vale la pena tomarte en serio.

9: Crea una ligera sensación de urgencia.

“Esperamos lanzar esto en primavera” es mucho más probable que genere una respuesta positiva que “Con el tiempo queremos lanzar esto.” Sin embargo la palabra “ligera” es importante: si tu pedido es urgente, la mayoría de las personas pueden asumir que eres una persona desorganizada o que algo ha salido mal y por lo tanto pueden pecar de prudencia.

10: Entiende la indirecta.

Si la primera persona a la que le pides ayuda dice no, pregúntale a otra. Si la quinta o décima persona dice no, pregúntate si lo que estás tratando de hacer tiene sentido y vale la pena hacerlo.

La siguiente plantilla de correo electrónico sigue todas estas reglas. Ha funcionado bastante bien: descubrimos que alrededor de la mitad de los correos fueron respondidos, en aproximadamente la mitad de estas respuestas querían conocer más, y la mitad de estos últimos contactos condujeron a talleres, lo que significa que entre el 10 y 15% de las cuentas de correo a las que nos dirigimos resultaron en talleres. Esto puede ser bastante desmoralizador si no estás acostumbrado/a, pero es mucho mejor que la tasa de respuesta del 2 a 3% que la mayoría de las organizaciones esperan con llamadas en frío.

Hola NOMBRE

Espero que no te resulte inoportuno recibir este correo, pero quería continuar con nuestra conversación en LUGAR DE REUNIÓN para ver si tendrías interés en que realicemos un taller de entrenamiento para docentes—estamos programando la próxima tanda para las próximas dos semanas.

Este taller de un día les enseñará a tus voluntarios/as una serie de prácticas de enseñanza útiles y basadas en evidencias. El taller se ha impartido más de cien veces de diversas maneras en los seis continentes para organizaciones sin fines de lucro, bibliotecas y empresas, y todo el material está disponible gratuitamente en línea en http://teachtogether.tech.

El temario incluye:

• estudiantes tipo

• diferencias entre diferentes tipos de estudiantes

• uso de evaluaciones formativas para diagnosticar malentendidos

• la enseñanza como un arte performativo

• que motiva y desmotiva a estudiantes adultos/as

• la importancia de la inclusión y como ser un buen aliado/a

Si esto te resulta interesante, por favor avísame—Agradecería la oportunidad de hablar de los modos y por qué medios sería adecuado hacerlo.

Gracias,

NOMBRE

Referencias

Construir alianzas con otros grupos que hacen cosas relacionadas a tu trabajo vale la pena por muchas razones. Una de ellas son las referencias: si la persona que se aproxima en busca de tu ayuda podría ser mejor atendida por alguna otra organización, tómate un momento para presentarlos. Si ya has hecho esto varias veces, agrega información a tu sitio web para ayudar a la próxima persona a encontrar lo que necesita. En retribución, las organizaciones a las que estás ayudando pronto empezarán a ayudarte.

Cambio académico

Todo el mundo tiene miedo a lo desconocido y a pasar vergüenza. En consecuencia, la mayoría de la gente prefiere fracasar que cambiar. Por ejemplo, Lauren Herckis investigó por qué los/las docentes de nivel universitario no adoptan mejores metodos de enseñanza. Lauren halló que el principal motivo es el miedo a parecer estúpido/a delante de los/las estudiantes; Las otras razones fueron: preocupación de que el cambio de los métodos de enseñanza pudiera afectar las evaluaciones de los cursos de forma negativa (lo cual a su vez podría afectar promociones y cargos) y el deseo de la gente de seguir emulando a los/las docentes que son fuente de inspiración.

No tiene sentido discutir si estas cuestiones son “reales” o no: los/las docentes creen que son reales, por lo que cualquier plan para trabajar con el personal docente de las universidades necesita tenerlas en cuenta²⁰.

[Bark2015] realizaron un estudio de dos etapas sobre cómo quienes son docentes de ciencias de la computación adoptan nuevas prácticas de enseñanza, ya sea individualmente, como organización o en la sociedad en su conjunto. En este estudio se preguntaron y respondieron tres asuntos claves:

¿Cómo se enteran de nuevas prácticas de enseñanza?

Buscan intencionalmente nuevas prácticas porque su motivación es resolver un problema (en particular, la participación de sus estudiantes), son conscientes de las nuevas prácticas a través de iniciativas deliberadas por parte de sus instituciones, las replican de colegas, o las obtienen por interacciones esperadas e inesperadas en conferencias (relacionadas a la enseñanza o de otro tipo).

¿Por qué las prueban?

A veces, debido a los incentivos institucionales (por ejemplo, innovan para mejorar sus chances de promoción), pero a menudo hay tensión en las instituciones de investigación, donde la retórica sobre la importancia de la enseñanza tiene poca credibilidad. Otra razón importante es su propio análisis costo/beneficio: ¿les va a ahorrar tiempo esa innovación? Una tercera razón es que se inspiran en modelos de roles a seguir—otra vez, esto afecta en gran medida a las innovaciones destinadas a mejorar la motivación y participación más que los resultados del aprendizaje. Finalmente, el cuarto factor son fuentes de confianza, por ejemplo, personas que han conocido en congresos o conferencias que se encuentran en la misma situación que ellos/as y han tenido experiencias exitosas al adoptar las nuevas prácticas. Pero los/las docentes tienen preocupaciones que no siempre son abordadas por el grupo de personas que abogan por modificaciones. La primera era la ley de Glass: cualquier nueva herramienta o práctica inicialmente te ralentiza, entonces mientras que las nuevas prácticas pueden hacer la enseñanza más efectiva a largo plazo, no pueden permitirse en el corto plazo. Otra preocupación es que el diseño físico de las aulas dificulta muchas prácticas nuevas: por ejemplo, los grupos de discusión no funcionan bien en asientos de estilo teatro.

Pero el resultado más revelador fue el siguiente: “A pesar de ser los propios investigadores/as quienes enseñan, la mayor parte de los/las docentes de ciencias de computación con quienes hablamos no creía que los resultados de estudios sobre educación fueran razones creíbles para probar prácticas de enseñanza.” Esto es consistente con otros hallazgos: incluso personas cuyas carreras están dedicadas a la investigación a menudo ignoran investigaciones sobre educación.

¿Por qué las siguen usando?

Como dice  [Bark2015], “Las devoluciones de los estudiantes son vitales,” y son normalmente la razón más fuerte para continuar usando una práctica, a pesar de que sabemos que las auto-evaluaciones realizadas por estudiantes no se correlacionan fuertemente con los resultados del aprendizaje [Star2014,Uttl2017] (aunque la asistencia a clases sí es un buen indicador del compromiso de los/las estudiantes). Otro motivo para retener una práctica son los requisitos institucionales, pero si esta es la única motivación, las personas abandonarán la práctica cuando el incentivo explícito o el monitoreo desaparezcan.

La buena noticia es que puedes abordar estos problemas sistemáticamente. [Baue2015] observó la adopción de nuevas técnicas médicas dentro de la Administración de Veteranos de los Estados Unidos. Hallaron que las prácticas médicas basadas en evidencia toman en promedio 17 años en ser incorporadas a las prácticas generales de rutina, y que solo cerca de la mitad de estas prácticas llegan a ser ampliamente adoptadas. Este deprimente hallazgo, junto con otros, ha estimulado el crecimiento de la ciencia de la implementación, que es el estudio de cómo lograr que la gente adopte mejores prácticas.

Como decía el Capítulo 13, el punto de partida es descifrar qué es lo que creen que necesitan las personas que quieres ayudar. Por ejemplo, [Yada2016] resume las devoluciones de docentes de nivel primario y secundario sobre la preparación y el apoyo que desean. Aunque esto puede no ser aplicable a todos los entornos, tomar una taza de té con unas pocas personas y escucharlas antes de hablar hace un mundo de diferencia en su voluntad de intentar algo nuevo.

Una vez que sepas lo que la gente necesita, el siguiente paso es hacer cambios de manera incremental, dentro de los propios esquemas de las instituciones. [Nara2018] describe un programa intensivo de tres años basado en cohortes muy unidas y apoyo administrativo que triplicó las tasas de graduación, mientras que [Hu2017] describe el impacto de implementar un programa de certificaciones de seis meses para docentes de secundaria que quieren enseñar computación. El número de docentes de computación se ha mantenido estable entre 2007 y 2013, pero se cuadruplicó –sin disminuir la calidad– después de la introducción de un nuevo programa de certificación: los/las docentes que eran personas novatas en computación parecían ser tan eficaces en el curso introductorio como los/las docentes con más entrenamiento o formación informática en la enseñanza.

En un sentido más amplio, [Borr2014] presenta categorías para lograr que ocurran cambios en la educación superior. Las categorías están definidas de acuerdo a si el cambio es individual o sistémico y si se prescribe (de arriba hacia abajo) o es un cambio emergente (de abajo hacia arriba). La persona que trata de hacer los cambios (y hacer que duren) tiene un rol distinto en cada una de estas situaciones, y consecuentemente debe seguir diferentes estrategias. El artículo continúa explicando en detalle cada uno de los métodos, mientras que [Hend2015a,Hend2015b] presentan las mismas ideas en una forma más procesable.

Al llegar a una institución, probablemente en principio caigas en la categoría de cambio individual/emergente, dado que te aproximas a cada docente uno a uno y tratarás de lograr que los cambios ocurran de abajo hacia arriba. Si este es el caso, las estrategias que recomiendan Borrego y Henderson se enfocan en que los/las docentes reflexionen sobre sus prácticas de enseñanza de manera individual o en grupos. Haz programación en vivo para mostrarles lo que haces o los ejemplos que usas, luego haz que tus estudiantes programen en vivo en turnos para mostrar cómo usarían esas ideas y técnicas en su desempeño así les darás a todos/as la oportunidad de elegir cosas que les serán útiles en su contexto.

Docentes free-range

Las escuelas y las universidades no son los únicos lugares en donde la gente va a aprender programación; en los últimos años, un número creciente de personas ha acudido a talleres free-range y programas de entrenamiento intensivo. Estos últimos suelen tener entre uno y seis meses de duración, son llevados a cabo por grupos de voluntarios/as o por empresas con fines de lucro y se proponen alcanzar a personas que se están re-entrenando para entrar al mundo de la tecnología. Algunos programas son de muy alta calidad, pero otros existen primariamente para sacarle dinero del bolsillo a la gente [McMi2017].

[Thay2017] entrevistó a 26 graduados de estos entrenamientos intensivos que les dan una segunda oportunidad a aquellos que han perdido oportunidades previas de educación en computación (aunque expresarlo de este modo implica realizar grandes suposiciones en lo que respecta a las personas de grupos subrepresentados). Las personas que participan de los entrenamientos intensivos enfrentan grandes costos y riesgos personales: deben gastar una cantidad significativa de tiempo, dinero y esfuerzo antes, durante y después de los entrenamientos intensivos, y cambiar de carrera puede tomar un año o más. Varias de las personas entrevistadas sienten que sus certificados fueron subestimados por sus empleadores: como dijeron algunas de ellas, obtener un trabajo significa aprobar una entrevista, pero dado que quienes te entrevistan muchas veces no comparten sus motivos de rechazo, es difícil saber qué arreglar o qué más aprender. Muchas personas han tenido que recurrir a pasantías (pagas o de otro tipo) y pasan mucho tiempo construyendo sus portfolios y haciendo networking. Las tres barreras informales que más fácilmente identificaron las personas entrevistadas fueron la jerga, el síndrome del impostor/a y una sensación de no encajar.

[Burk2018] profundizó en este tema al comparar las habilidades y credenciales que la industria tecnológica busca con aquellas habilidades provistas por carreras de cuatro años y programas de entrenamiento intensivo. A partir de entrevistas con 15 gerentes de contratación de empresas de varios tamaños y algunos grupos focales, encontraron que los/las reclutadores/as enfatizaban uniformemente en habilidades blandas (especialmente trabajo en equipo, comunicación y la habilidad para continuar aprendiendo). Muchas compañías requerían un título de cuatro años (aunque no necesariamente en ciencias de la computación), pero muchas también elogiaron a egresados/as de programas de entrenamiento intensivo por ser mayores en edad o tener más madurez y por poseer conocimientos más actualizados.

Si te estás aproximando a un programa de entrenamiento intensivo que ya existe, tu mejor estrategia podría ser enfatizar lo que sabes sobre enseñanza, en lugar de lo que sabes sobre tecnología, ya que gran parte del personal y de los/las fundadores/as tiene experiencia en programación pero poca o ninguna capacitación en educación. Los primeros capítulos de este libro han servido con este público en el pasado, y  [Lang2016] describe prácticas de enseñanza basadas en evidencia que pueden implementarse con un esfuerzo mínimo y a bajo costo. Estas prácticas tal vez no tengan el mayor impacto, pero lograr algunas victorias tempranas ayuda a generar apoyo para esfuerzos más grandes.

Reflexiones finales

Es imposible cambiar grandes instituciones por tu cuenta: necesitas aliados/as y para conseguir aliados/as, necesitas tácticas. La guía más útil que he encontrado es [Mann2015], que cataloga más de cuatro docenas de estas tácticas y las organiza de acuerdo a si se implementan mejor temprano, más adelante, a lo largo del ciclo de cambio, o cuando encuentras resistencia. Algunos de sus patrones incluyen:

En tu espacio:

Mantén la nueva idea visible colocando recordatorios en toda la organización.

Símbolo:

Para una nueva idea se mantenga viva en la memoria de una persona, entrega un objeto simbólico que pueda identificarse con el tema que se está presentando.

El rol del escepticismo:

Identifica a los/las líderes de opinión fuertes que son escépticos de tu nueva idea para desempeñar el papel de “persona escéptica oficial”. Usa sus comentarios para mejorar tus esfuerzos, incluso si no logras hacer que cambien de opinión.

Compromiso futuro:

Si puedes anticipar algunas de sus necesidades, podrás pedir (y tener éxito) en obtener un compromiso futuro de las personas más ocupadas. Si se les da algún tiempo de anticipación, es posible que tengan mayor disposición a ayudar porque permites que se organicen.

La estrategia más importante es el deseo de cambiar tus metas basado en lo que aprendes de las personas a las que estás tratando de ayudar. Por ejemplo, enseñarles tutoriales que muestran cómo usar una hoja de cálculo podría ser una ayuda más rápida y confiable que una introducción a JavaScript. A menudo he cometido el error de confundir cosas que me apasionan con cosas que las otras personas deberían saber; si realmente quieres ser quien las acompañe, recuerda siempre que el aprendizaje y el cambio tienen que ir en ambos sentidos.

La parte más difícil de construir relaciones es comenzarlas. Reserva una o dos horas cada mes para encontrar aliados/as y mantener tus relaciones con ellos/as. Una forma de hacer esto es pedirles consejos: ¿cómo creen que deberías hacer para que lo que están haciendo sea más conocido? ¿Dónde han encontrado espacio para dar clases? ¿Qué necesidades creen que no son cubiertas y tú serías capaz de lograr? Cualquier grupo que haya existido durante algunos años tendrá consejos útiles; también se sentirán halagados/as de que se les haya consultado, y sabrán quién eres la próxima vez que llames.

Y como dice [Kuch2011], si no puedes ser el/la primero/a en una categoria, tratar de crear una nueva categoría en la que sí puedas. Si no puedes hacerlo, únete a un grupo existente o piensa en hacer algo completamente diferente. Esto no es derrotista: si alguien más ya está haciendo lo que tienes en mente, deberías incorporarte y contrinuir a ese grupo o abordar alguna de las otras cosas igualmente útiles en las que podrías estar trabajando.

Ejercicios

Discurso de presentación para un concejero/a municipal (individual/10’)

Este capítulo describe una organización que ofrece talleres de programación de fin de semana para las personas que re-ingresan a la actividad laboral. Escribe un discurso de presentación para esa organización, dirigido a un/a integrante del consejo de la ciudad o municipio cuyo apoyo necesita esa organización.

Presenta tu organización (individual/30’)

Identifica dos grupos de personas de los que tu organización necesite apoyo y escribe un discurso de presentación dirigido a cada uno de estos grupos.

Asuntos de correo electrónico (parejas/10’)

Escribe las líneas de asunto (y solo las líneas de asunto) para tres mensajes de correo electrónico: uno anunciando un nuevo curso, uno anunciando un nuevo patrocinio, y uno anunciando un cambio en el liderazgo del proyecto. Compara tus líneas de asunto con las de tu pareja. Analicen si pueden combinar las mejores características de cada asunto a la par que los acortan.

Manejando la resistencia pasiva (grupos pequeños/30’)

Las personas que no quieren cambios a veces lo dirán en voz alta, pero a menudo pueden utilizar otras formas de resistencia pasiva, como simplemente no lidiar con ello, o plantear un posible problema después de otro para hacer que el cambio parezca más arriesgado y más costoso de lo que en realidad es probable que sea [Scot1987]. En grupos pequeños, enumeren tres o cuatro razones por las que las personas podrían no querer que tu iniciativa de enseñanza siga adelante, y expliquen qué pueden hacer con el tiempo y los recursos que tienen para contrarrestar cada una de esas razones.

¿Por qué aprender a programar? (individual/15’)

Revisa el ejercicio “¿Por qué aprender a programar?” en la Sección 1.4. ¿Dónde conciden tus razones para enseñar y las razones de tus estudiantes para aprender? ¿Dónde no coinciden? ¿Cómo afecta eso a tu marketing?

Programadores/as conversacionales (pensar-parejas-compartir/15’)

Un/una programador/a conversacional es alguien que necesita saber lo suficiente sobre computación para tener una conversación valiosa con otro/a programador/a, pero no va a programar por su cuenta. [Wang2018] descubrió que la mayoría de los recursos de aprendizaje no abordan las necesidades de este grupo. En parejas, escriban un discurso para un taller de medio día destinado a ayudar a las personas que se ajustan a esta descripción. Luego, compartan el discurso que armaron con el resto de la clase.

Colaboraciones (grupos pequeños/30’)

Responde por tu cuenta las siguientes preguntas, luego compara tus respuestas con las dadas por el resto de tu grupo.

1. ¿Tienes algún acuerdo o relación con otros grupos?

2. ¿Quieres generar lazos con algún otro grupo?

3. El hecho de tener (o no tener) colaboraciones, ¿podría ayudarte a alcanzar tus metas?

4. ¿Cuáles son tus colaboraciones clave?

5. ¿Son estos los colaboradores adecuados o indicados para alcanzar tus metas u objetivos?

6. ¿Con qué grupos o entidades te gustaría que tu organización tuviera acuerdos o lazos?

Educación (toda la clase/10’)

[Laba2008] explora por qué los Estados Unidos y otros países siguen trasladando la solución a los problemas sociales hacia las instituciones educativas y por qué eso sigue sin funcionar. Tal como él remarca, “[La educación] ha hecho muy poco para promover la igualdad de raza, clase y género; para mejorar la salud pública, la productividad económica y la buena ciudadanía; o reducir el sexo sin cuidados en la adolescencia, las muertes por accidentes de tránsito, la obesidad y la destrucción ambiental. De hecho, en muchos sentidos la educación ha tenido un efecto negativo sobre estos problemas, sacando dinero y energía de las reformas sociales que podrían haber tenido un impacto más substancial.” El autor continúa escribiendo:

Entonces, ¿cómo debemos entender el éxito de esta institución, a la luz de su fracaso en lo que le pedimos? Una forma de pensar en esto es que la educación puede no estar haciendo lo que pedimos, pero está haciendo lo que queremos. Queremos una institución que persiga nuestros objetivos sociales de una manera que esté en línea con el individualismo en el corazón del ideal liberal, con el objetivo de resolver problemas sociales buscando cambiar los corazones, mentes y capacidades de cada estudiante individual. Otra forma de decir esto es que queremos una institución a través de la cual podamos expresar nuestros objetivos sociales sin violar el principio de elección individual que se encuentra en el centro de la estructura social, incluso si esto tiene el costo de no lograr estos objetivos. Entonces la educación puede servir como un punto de orgullo cívico, un lugar para exponer nuestros ideales, y un medio para participar en disputas edificantes pero que en última instancia intrascendentes sobre visiones alternativas de la buena vida. Al mismo tiempo, la educación también puede servir como un conveniente chivo expiatorio al que podemos culpar por su fracaso en lograr nuestras más altas aspiraciones como sociedad.

¿Cómo los esfuerzos para enseñar pensamiento computacional y la ciudadanía digital en las escuelas se adaptan a este marco? ¿Los programas de entrenamiento intensivo evitan estas trampas o simplemente las entregan con una nueva apariencia?

Adopción institucional (toda la clase/15’)

Relean la lista de motivaciones para adoptar nuevas prácticas presentada en la Sección 14.4.

¿Cuáles de estas motivaciones se aplican a tí y a tus colegas? ¿Cuáles son irrelevantes en tu contexto? ¿En cuáles de estas motivaciones haces hincapié en los casos en que interactúas con personas que trabajan en instituciones educativas formales?

Si al principio no tienes éxito (grupos pequeños/15’)

W.C. Fields probablemente nunca dijo “Si al principio no tienes éxito, inténtalo, inténtalo de nuevo. Luego abandona—no sirve de nada ser un maldito tonto al respecto.” Sin embargo, sigue siendo un buen consejo: si las personas con las que intentas comunicarte no están respondiendo, podría ser que nunca las convenzas. En grupos de 3 a 4 personas, hagan una breve lista de señales que indiquen que debes dejar de intentar hacer algo en lo que crees. ¿Cuántas de estas señales ya son verdaderas?

Haz que falle (individual/15’)

[Farm2006] presenta algunas reglas irónicas para lograr que nuevas herramientas no sean adoptadas, todas de las cuales aplican a nuevas prácticas de enseñanza:

1. Hazlo opcional.

2. Economiza en entrenamiento.

3. No las uses en un proyecto real.

4. Nunca la integres.

5. Úsala esporádicamente.

6. Hazla parte de una iniciativa de calidad.

7. Marginaliza al campeón/a.

8. Capitaliza los primeros errores.

9. Haz una inversión pequeña.

10. Explota el miedo, la incertidumbre, la duda, la pereza y la inercia.

¿Cuál de estas reglas has visto implementarse recientemente? ¿Cuáles has utilizado tú mismo/a? ¿De qué forma se usaron esas reglas?

Mentoreo (todo la clase/15’)

El Institute for African-American Mentoring in Computer Science (Instituto de Mentoría Afroamericana en Ciencias de la Computación) ha publicado guías para mentorear estudiantes de doctorado. Lee estas guías individualmente (en inglés), luego discutan en la clase y califiquen los esfuerzos para tu propio grupo como: +1 (definitivamente lo haría), 0 (no estoy seguro o no es aplicable), o -1 (definitivamente no lo haría).

¿Por qué enseño?

Cuando comencé a trabajar como voluntario en la Universidad de Toronto, mis estudiantes me preguntaron por qué enseñaba gratis. Esta fue mi respuesta:

Cuando tenía tu edad, pensaba que las universidades existían para enseñarle a la gente a aprender. Más tarde, en la escuela de posgrado, pensaba que las universidades se dedicaban a investigar y a crear nuevos conocimientos. Sin embargo, ahora que tengo cuarenta años pienso que lo que realmente te estamos enseñando es cómo hacerte cargo del mundo, porque vas a tener que hacerlo quieras o no.

Mis padres tienen setenta años. Ya no manejan el mundo; son las personas de mi edad quienes aprueban leyes y toman decisiones de vida o muerte en los hospitales. Y sin importar qué tan aterrador sea, nosotras/os somos las personas adultas.

En veinte años, nosotras/os estaremos camino a la jubilación y tú estarás a cargo. Esto puede parecer mucho tiempo cuando tienes diecinueve años, pero se pasa en un suspiro. Por eso te damos problemas cuyas respuestas no se pueden encontrar en las notas del año pasado. Por eso te ponemos en situaciones en las que tienes que decidir qué hacer ahora, qué se puede dejar para más tarde y qué puedes simplemente ignorar. Porque si no aprendes cómo hacer estas cosas ahora, no estarás lista/o para hacerlo cuando sea necesario.

Todo esto era verdad, pero no es toda la historia. No quiero que la gente haga del mundo un lugar mejor para que yo me pueda retirar cómodamente. Quiero que lo hagan porque es la aventura más grande de nuestro tiempo. Hace ciento cincuenta años, la mayoría de las sociedades practicaban la esclavitud. Hace cien años, en Canadá, mi abuela no era considerada una persona desde el punto de vista legal. El año en que nací, la mayoría de las personas del mundo sufrían bajo algún régimen totalitario y la justicia todavía dictaminaba terapia de electroshock para “curar” a las/los homosexuales. Todavía hay muchas cosas que están mal en el mundo, pero mira cuántas más opciones tenemos que nuestras/os abuelas/os. Mira cuántas cosas más podemos saber, ser y disfrutar porque finalmente nos estamos tomando en serio la Regla de Oro.

Hoy soy menos optimista que entonces. Cambio climático, extinción masiva, capitalismo de vigilancia, desigualdad a una escala que no habíamos visto desde hace un siglo, el resurgimiento del nacionalismo racista: mi generación vio cómo sucedió todo esto y se quedó de brazos cruzados. La factura de nuestra cobardía, letargo y avaricia no se pagará hasta que mi hija crezca, pero llegará, y para cuando lo haga, no habrá soluciones fáciles para estos problemas (y posiblemente no haya soluciones en absoluto).

Así que por eso enseño: estoy enojado. Estoy enojado porque tu género, el color de tu piel y la riqueza y conexiones de tu madre y de tu padre no deberían contar más que cuán inteligente, honesta/o o trabajadora/or seas. Estoy enojado porque convertimos a internet en una cloaca. Estoy enojado porque los nazis están en marcha una vez más y los multimillonarios juegan con cohetes espaciales mientras el planeta se derrite. Estoy enojado, entonces enseño, porque el mundo solo mejora cuando enseñamos a las personas cómo mejorarlo.

En su ensayo de 1947 “¿Por qué escribo?”, George Orwell escribió²¹:

En una época pacífica, podría haber escrito libros superficiales, decorativos o simplemente descriptivos, y podría haber permanecido casi inconsciente de mis lealtades políticas. Pero tal como están las cosas, me he visto obligado a convertirme en una especie de panfletista … Cada línea de trabajo serio que he escrito desde 1936 ha sido escrita, directa o indirectamente, en contra del totalitarismo… Me parece una tontería, en un período como el nuestro, pensar que uno puede evitar escribir sobre tales temas. Todas las personas escriben al respecto de una manera u otra. La cuestión es simplemente elegir de qué lado lo hacemos.

Reemplaza “escribir” por “enseñar” y sabrás porqué hago lo que hago.

Gracias por leer — Espero que podamos enseñar juntos algún día. Hasta entonces:

Licencia

Este es un resumen de lectura sencilla para personas (y no un sustituto) de la licencia. Por favor revisa https://creativecommons.org/licenses/by-nc/4.0/legalcode.es para el texto legal completo.

Este trabajo se licencia bajo Creative Commons Atribución – No Comercial 4.0 (CC-BY-NC-4.0).
Eres libre de:

• Compartir—copiar y redistribuir el material en cualquier medio o formato

• Adaptar—reacomodar, transformar y construir sobre el material.

El/la licenciante no puede revocar estas libertades mientras sigas los términos de la licencia.

Bajo los siguientes términos:

• Atribución—Debes dar el crédito apropiado, proporcionar un enlace a la licencia e indicar si se hicieron cambios. Puedes hacerlo de cualquier manera razonable, pero siempre que no sugiera que el/la licenciante te respalda a ti o al uso que le das al material.
  

• No Comercial—No puedes utilizar el material con fines comerciales.

Sin restricciones adicionales—No puedes aplicar términos legales o medidas tecnológicas que restrinjan legalmente a otras personas de hacer cualquier cosa que la licencia permita.

Avisos:

• No tienes que cumplir con la licencia para aquellos elementos del material que son de dominio público o cuando su uso esté permitido por una excepción o limitación aplicable.

• No se otorgan garantías. Es posible que la licencia no otorgue todos los permisos necesarios para el uso que se pretende dar al material. Por ejemplo, derechos relacionados a la publicidad, privacidad o derechos morales pueden limitar la forma en la que puedes usar el material.

Código de conducta

Con el objetivo de fomentar un ambiente abierto y amigable, las personas encargadas del proyecto, colaboradoras/es y personas de soporte, nos comprometemos a hacer de la participación en nuestro proyecto y en nuestra comunidad una experiencia libre de acoso para todas/os, independientemente de su edad, tamaño corporal, discapacidad, etnia, identidad y expresión de género, nivel de experiencia, educación, nivel socioeconómico, nacionalidad, apariencia personal, raza, religión o identidad y orientación sexual.

Nuestros estándares

Ejemplos de comportamientos que contribuyen a crear un ambiente positivo para nuestra comunidad:

• utilizar un lenguaje amigable e inclusivo,

• respetar diferentes puntos de vista y experiencias,

• aceptar adecuadamente la crítica constructiva,

• enfocarse en lo que es mejor para la comunidad y

• mostrar empatía hacia otras/os participantes de la comunidad.

Ejemplos de comportamiento inaceptable:

• el uso de lenguaje o imágenes sexualizadas así como dar atención o generar avances sexuales no deseados,

• ofender o provocar de modo malintencionado (trolling), comentarios despectivos, insultantes y ataques personales o políticos,

• acoso público o privado,

• publicar información privada de otras personas, tales como direcciones físicas o de correo electrónico, sin su permiso explícito, y

• otras conductas que puedan ser razonablemente consideradas como inapropiadas en un entorno profesional.

Nuestras responsabilidades

Las personas encargadas del proyecto somos responsables de aclarar los estándares de comportamiento aceptable y se espera que tomemos medidas de acción correctivas apropiadas y justas en respuesta a cualquier caso de comportamiento inaceptable.

Las personas encargadas del proyecto tenemos el derecho y la responsabilidad de eliminar, editar o rechazar comentarios, commits, código, ediciones en la wiki, issues y otras contribuciones que no estén alineadas con este Código de Conducta. También pueden prohibir la participación temporal o permanente de cualquier persona por comportamientos que sean considerados inapropiados, amenazantes, ofensivos o dañinos.

Alcance

Este Código de Conducta aplica tanto a espacios dentro del proyecto como en espacios públicos, mientras una persona represente al proyecto o a la comunidad. Ejemplos de representación del proyecto o la comunidad incluyen el uso de una dirección de correo electrónico oficial del proyecto, realizar publicaciones a través de una cuenta oficial en redes sociales o actuar como representante designada/o en cualquier evento presencial o en línea. La representación del proyecto puede ser aclarada y definida con más detalle por las personas encargadas.

Aplicación

Los casos de comportamiento abusivo, acosador o inaceptable pueden ser denunciados enviando un correo electrónico a la persona encargada del proyecto a la dirección gvwilson@third-bit.com. Todas las quejas serán revisadas e investigadas y darán como resultado una respuesta que se considere necesaria y apropiada a las circunstancias. El equipo encargado del proyecto está obligado a mantener la confidencialidad de quien reporte un incidente. Se pueden publicar por separado más detalles de políticas de aplicación específicas.

Aquellas personas encargadas del proyecto que no cumplan o apliquen este código de conducta de buena fe pueden enfrentar repercusiones temporales o permanentes determinadas por el resto del equipo a cargo del proyecto.

Atribución

Este código de conducta es una adaptación del Contributor Covenant version 1.4.

Unirse a nuestra comunidad

Esperamos que elijas ayudarnos a mejorar este libro. Si esta forma de trabajo colaborativa es nueva para ti, consulta en el Anexo 17 nuestro código de conducta, y luego:

Empieza pequeño.

Arregla un error tipográfico, aclara la redacción de un ejercicio, corrige o actualiza una cita, o sugiere un mejor ejemplo o analogía para ilustrar algún punto.

Únete a la conversación.

Mira los issues y los cambios propuestos por otras personas y añádeles tus comentarios. A menudo es posible mejorar las mejoras, y es una buena manera de presentarte a la comunidad y hacer nuevas amistades. Las etiquetas “Beginner-Friendly” (apto para principiantes en inglés), “Work in Progress” (trabajo en progreso en inglés) y “Help Wanted” (se busca ayuda en inglés) son buenos issues para unirte a la conversación.

Discute, luego edita.

Si quieres proponer un gran cambio, como reorganizar o dividir un capítulo completo, por favor, completa un issue que describa tu propuesta y tu razonamiento y etiquétalo como “Addition” (agregado en inglés), “Correction” (corrección en inglés) ó “Discussion” (discusión en inglés). Te alentamos a que agregues comentarios a estos issues para que toda la discusión sobre qué y por qué esté abierta y se pueda archivar. Si se acepta la propuesta, el trabajo real puede dividirse en varios problemas o cambios más pequeños que se pueden abordar de forma independiente.

Usando este material

Como se declaró en el Capítulo 1, todo este material puede distribuirse y reutilizarse libremente bajo la licencia Creative Commons Atribución – No Comercial 4.0 (Anexo 16). Puedes usar la versión en línea en http://teachtogether.tech/ en cualquier clase (gratuita o paga), y puedes citar extractos breves bajo las disposiciones de uso justo, pero no puedes volver a publicar fragmentos grandes en obras comerciales sin permiso previo.

Este material ha sido usado de muchas maneras, desde una clase en línea de varias semanas hasta un taller intensivo en persona. Por lo general, es posible cubrir gran parte de los capítulos Capítulo 2 a Capítulo 6, Capítulo 8, y Capítulo 10 en dos días de jornada completa.

En persona

Esta es la forma más efectiva de impartir esta capacitación, pero también la más exigente. Las personas que participan están físicamente en el mismo lugar. Cuando necesitan practicar cómo enseñar en pequeños grupos, parte de la clase o toda la clase va a habitaciones cercanas. Cada participante usa su propia tableta o computadora portátil para ver material en línea durante la clase y para tomar notas compartidas (Sección 9.7), y usa lápiz y papel o pizarras para otros ejercicios. Las preguntas y la discusión se hacen en voz alta.

Si estás enseñando en este formato, debes usar notas adhesivas como indicadores de estado para que puedas ver quién necesita ayuda, quién tiene preguntas y quién está listo/a para seguir adelante (Sección 9.8). También debes usarlos para distribuir la atención, para que todo el curso obtenga tu atención y tiempo de forma justa, como tarjetas de actas para alentar a tus estudiantes a reflexionar sobre lo que acaban de aprender y para darte retroalimentación procesable mientras todavía tienes tiempo para actuar en consecuencia.

En línea en grupos

En este formato, entre 10 a 40 estudiantes se juntan en 2 a 6 grupos de 4 a 12 personas, pero esos grupos están distribuidos geográficamente. Cada grupo usa una cámara y un micrófono para conectarse a la videollamada, en lugar de que cada persona esté en la llamada por separado. Un buen audio es más importante que un buen video en ambas direcciones: una voz sin imágenes (como la radio) es mucho más fácil de entender que las imágenes sin narrativa, y los/las docentes no necesitan ver a las personas para responder preguntas, siempre y cuando esas preguntas se puedan escuchar con claridad. Dicho esto, si una lección no es accesible, entonces no es útil (Sección 10.3): proporcionar texto descriptivo es una ayuda cuando la calidad del audio es deficiente, e incluso si el audio es bueno resulta importante para aquellas personas con dificultades auditivas.

Toda la clase toma notas compartidas, y también usa las notas compartidas para hacer y responder preguntas. Tener varias decenas de personas tratando de hablar en una llamada no funciona bien, así que en la mayoría de las sesiones el/la docente habla y sus estudiantes responden a través del chat de la herramienta para tomar notas.

En línea de forma individual

La extensión natural de estar en línea en grupos es estar en línea en forma individual. Al igual que con los grupos en línea, el/la docente hablará la mayoría de las veces y los/las estudiantes participarán principalmente a través del chat de texto. También en este caso, y siempre teniendo en cuenta los aspectos de accesibilidad, un buen audio es más importante que un buen video, y quienes participan deberían usar el chat de texto para indicar que quieren hablar (Anexo 20).

Tener participantes en línea individualmente hace que sea más difícil dibujar y compartir mapas conceptuales (Sección 3.4) o dar retroalimentación sobre la enseñanza (Sección 8.5). Por lo tanto, quienes enseñen deberán confiar más en el uso de ejercicios con resultados escritos que se puedan poner en las notas compartidas, como por ejemplo, dar una devolución sobre videos de personas enseñando.

Multi-semana en línea

La clase se reúne todas las semanas durante una hora a través de videoconferencia. Cada reunión puede realizarse dos veces para acomodar las zonas horarias y los horarios de los/las estudiantes. Los/las participantes toman notas compartidas como se describió anteriormente para las clases grupales en línea, para publicar tareas en línea entre clases y para comentar sobre el trabajo de los demás. En la práctica, los comentarios son relativamente raros: la gente prefiere discutir el material en las reuniones semanales.

Este fue el primer formato que utilicé y ya no lo recomiendo: mientras que extender la clase les da a las personas tiempo para reflexionar y abordar ejercicios más extensos, también aumenta en gran medida las probabilidades de que tengan que abandonar debido a otras demandas de su tiempo.

Contribuir y mantener

Las contribuciones de todo tipo son bienvenidas, desde sugerencias para mejoras hasta erratas y nuevo material. Todas las personas que contribuyan deben cumplir con nuestro Código de Conducta (Anexo 17); al enviar tu trabajo, aceptas que pueda incorporarse tanto en forma original como editada y que pueda ser publicado bajo la misma licencia que el resto de este material (Anexo 16).

Si tu material es incorporado, te agregaremos a los agradecimientos (Sección 1.3) a menos que solicites lo contrario.

La fuente de la versión original de este libro se almacena en GitHub en:

y la versión en español se encuentra dentro de la carpeta es. Para conocer más sobre el proceso de traducción y los acuerdos generados durante nuestro trabajo colaborativo, puedes consultar el Capítulo [s:traduccion] y el Readme.md en el repositorio es.

Si sabes cómo usar Git y GitHub y deseas cambiar, arreglar o agregar algo, por favor envía un pull request que modifique la fuente del LaTeX. Si deseas obtener una vista previa de tus cambios, por favor ejecuta make pdf o make html en la línea de comandos de tu computadora.

Si quieres reportar un error, hacer una pregunta o hacer una sugerencia, presenta un issue en el repositorio. Necesitas tener una cuenta de GitHub para hacer esto, pero no necesitas saber cómo usar Git.

Siempre etiqueta tus issues y pull requests como “Español”.

Si no deseas crear una cuenta de GitHub, envía tu contribución por correo electrónico a gvwilson@third-bit.com con “T3” o “Teaching Tech Together” en algún lugar del asunto. Intentaremos responder en una semana.

Finalmente, siempre nos gusta escuchar cómo se ha usado este material, y estamos siempre agradecidos/as por el aporte de más mapas conceptuales.

Glosario

Agotamiento del ego

El deterioro del autocontrol debido al uso prolongado o intensivo de las estrategias de control. Trabajos recientes no pudieron corroborar su existencia.

Amenaza del estereotipo

Una situación en la que las personas sienten que corren el riesgo de ser sometidas a los estereotipos de su grupo social.

Andamiaje

Proporcionar material adicional a las/los estudiantes en etapa inicial para ayudarlas/os a resolver problemas.

Aprendizaje activo

Un enfoque de la enseñanza en el que las/los estudiantes se involucran con el material a través de la discusión, resolución de problemas, estudios de casos y otras actividades que requieren que reflexionen y usen nueva información en tiempo real. Ver también aprendizaje pasivo.

Aprendizaje basado en la indagación

La práctica de permitir que las/los estudiantes hagan sus propias preguntas, establezcan sus propios objetivos y encuentren su propio camino a través de un tema.

Aprendizaje cognitivo

Una teoría de aprendizaje que enfatiza el proceso de enseñanza de quien transmite habilidades e ideas situacionalmente a su estudiante.

Aprendizaje pasivo

Un enfoque de la enseñanza en el que las/los estudiantes leen, escuchan o miran sin utilizar inmediatamente nuevos conocimientos. El aprendizaje pasivo es menos efectivo que el aprendizaje activo.

Aprendizaje personalizado

Adaptación automática de lecciones para satisfacer las necesidades de las/los estudiantes individuales.

Aprendizaje situado

Un modelo de aprendizaje que se centra en la transición de las personas de ser recién llegadas a ser integrantes aceptadas/os de una comunidad de práctica.

Artefacto tangible

Algo en lo que una/un estudiante puede trabajar, cuyo estado le proporciona retroalimentación sobre su progreso y la/lo ayuda a diagnosticar errores.

Aula invertida

Una clase en la que las/los estudiantes ven lecciones grabadas en su propio tiempo, mientras que el tiempo de clase se utiliza para resolver conjuntos de problemas y responder preguntas.

Automaticidad

La capacidad de hacer una tarea sin concentrarse en los detalles de bajo nivel.

Carga cognitiva

El esfuerzo mental necesario para resolver un problema. La teoría de la carga cognitiva la divide en carga intrínseca, carga pertinente y carga extrínseca. Sostiene que las personas aprenden más rápido cuando las cargas pertinente y extrínseca son reducidas.

Carga extrínseca

Cualquier carga cognitiva que distrae del aprendizaje.

Carga instrínseca

La carga cognitiva requerida para absorber nueva información.

Carga pertinente

La carga cognitiva requerida para vincular la nueva información con la antigua.

Ciencia de implementación

El estudio de cómo traducir los hallazgos de la investigación a la práctica clínica diaria.

Ciencias de la computación desenchufada

Un estilo de enseñanza que introduce conceptos informáticos utilizando ejemplos y artefactos que no son de programación.

Clase sincrónica

Un tipo de clase en la que tanto la/el docente como las/los estudiantes se conectan a un espacio común virtual al mismo tiempo e interactúan en tiempo real.

Clase asincrónica

Un tipo de clase en la que la interacción y comunicación de estudiantes y docentes se hace de forma distribuida, no necesariamente en el mismo momento, e intercalada con otras actividades.

Co-enseñanza

Enseñar con otra/o docente en el salón de clases.

Cognición externalizada

El uso de ayuda gráfica, física o verbal para aumentar el pensamiento.

Cognitivismo

Una teoría del aprendizaje que sostiene que los estados y procesos mentales pueden y deben incluirse en modelos de aprendizaje. Ver también conductismo.

Comunidad de práctica

Grupo de personas auto-organizado y auto-mantenido, que comparten y desarrollan un oficio como ser tejedoras/es, músicas/os o programadoras/es. Ver también participación inicial legítima.

Conductismo

Una teoría del aprendizaje cuyo principio central es estímulo y respuesta, y cuyo objetivo es explicar el comportamiento sin recurrir a estados mentales internos u otros inobservables. Ver además cognitivismo.

Conectivismo

Una teoría del aprendizaje que sostiene que el conocimiento se distribuye, que el aprendizaje es el proceso de navegación, crecimiento y poda de conexiones, y que enfatiza los aspectos sociales del aprendizaje que son posibles gracias a internet.

Conocimiento de la pedagogía del contenido

(PCK, por sus siglas en inglés) La comprensión de cómo enseñar un tema en particular, es decir, el mejor orden en el cual introducir temas y qué ejemplos usar. Ver también conocimiento del contenido y conocimiento pedagógico general.

Conocimiento del contenido

La comprensión de una persona de un tema. Ver también conocimiento pedagógico general y conocimiento de contenido pedagógico.

Conocimiento pedagógico general

La comprensión de una persona de los principios generales de la enseñanza. Ver también conocimiento del contenido y conocimiento de contenido pedagógico.

Constructivismo

Una teoría del aprendizaje que considera que las/los estudiantes construyen activamente el conocimiento.

Contribuyendo a la pedagogía estudiantil

Hacer que las/los estudiantes produzcan artefactos para contribuir al aprendizaje de otros.

CS0. Introducción a las ciencias de la computación

Un curso introductorio de nivel universitario sobre computación dirigido a estudiantes no avanzadas/os con poca o ninguna experiencia previa en programación.

CS1. Ciencias de la computación I

Un curso introductorio de ciencias de la computación a nivel universitario, generalmente de un semestre, que se enfoca en variables, bucles, funciones y otras mecánicas básicas.

CS2. Ciencias de la computación II

Un segundo curso de ciencias de la computación de nivel universitario que generalmente presenta estructuras de datos básicas como pilas, colas y diccionarios.

Cursos masivos en línea

(MOOC, por sus siglas en inglés) Un curso en línea diseñado para la inscripción masiva y el estudio asincrónico, que generalmente usa videos grabados y calificaciones automáticas.

Desarrollo impulsado por pruebas

Una práctica de desarrollo de software en la que las/los programadoras/es escriben primero los tests para darse objetivos concretos y aclarar su comprensión de cómo se ve “terminado”.

Directorio de servicio

Un directorio en el cual sus integrantes asumen roles de trabajo en la organización.

Directorio

Un directorio cuya responsabilidad principal es contratar, supervisar y, si es necesario, despedir a la directora o al director.

Discurso breve de presentación

Una breve descripción de una idea, proyecto, producto o persona que se puede dar y comprender en solo unos segundos.

Diseño instruccional

El arte de crear y evaluar lecciones específicas para públicos específicos. Ver también psicología educacional.

Distractor pausible

Una respuesta incorrecta, que parece que podría ser correcta, en una pregunta de opción múltiple. Ver también poder diagnóstico.

Efecto de atención dividida

La disminución que ocurre en el aprendizaje cuando las/los estudiantes deben dividir su atención entre múltiples presentaciones concurrentes de la misma información (por ejemplo, subtítulos y una voz en off).

Efecto Dunning-Kruger

La tendencia de las personas que solo saben un poco sobre un tema, a estimar incorrectamente su comprensión del mismo.

Efecto inverso de la experiencia

La forma en que la instrucción que es efectiva para las personas novatas se vuelve ineficaz para las personas competentes o expertas.

Ejemplo desvanecido

Una serie de ejemplos en los que se borra un número cada vez mayor de pasos clave. Ver también andamiaje.

Enseñar para el examen

Cualquier método de “educación” que se centre en preparar a las/los estudiantes para aprobar los exámenes estandarizados, en lugar de aprender realmente.

Enseñanza activa

Un enfoque de la instrucción en el que la/el docente actúa sobre la nueva información adquirida de las/los estudiantes mientras enseña (p. ej. cambiando dinámicamente un ejemplo o reorganizando el orden previsto del contenido). Ver también enseñanza pasiva.

Enseñanza directa

Ver instrucción directa.

Enseñanza pasiva

Un enfoque a la enseñanza en el que la/el docente no ajusta el ritmo o los ejemplos, o no actúa de acuerdo con los comentarios de las/los estudiantes, durante la lección. Ver también enseñanza activa.

Estudiante free-range

Alguien que aprende fuera de un aula institucional con un plan de estudios y tareas obligatorias.

Etiquetado de subobjetivos

Dar nombres a cada paso en una descripción paso a paso de un proceso de resolución de problemas.

Evaluación formativa

Evaluación que se lleva a cabo durante una clase para dar retroalimentación tanto a estudiantes como a docentes sobre la comprensión real. Ver también evaluación sumativa.

Evaluación sumativa

Evaluación que se realiza al final de una lección para determinar si se ha realizado el aprendizaje deseado.

Experta/o

Alguien que puede diagnosticar y manejar situaciones inusuales, sabe cuándo no se aplican las reglas habituales y tiende a reconocer soluciones en lugar de razonarlas. Ver también practicante competente y novata/o.

Falla productiva

Una situación en la que a las/los estudiantes se les dan deliberadamente, problemas que no se pueden resolver con el conocimiento que tienen y deben salir y adquirir nueva información para progresar. Ver también Zona de desarrollo próximo.

Falsa/o principiante

Las/los falsas/os principiantes comienzan en el mismo punto que los principiantes verdaderos (es decir, en una evaluación inicial mostrarán el mismo nivel de competencia) pero pueden avanzar mucho más rápido. Por ejemplo, alguien que ha estudiado un idioma antes pero lo está aprendiendo nuevamente.

Fenómeno de hipercorrección

Cuanto más cree alguien que su respuesta en un examen era correcta, más probabilidades hay de que no repita el error una vez que descubre que, de hecho, estaba equivocada/o.

Flujo

La sensación de estar completamente inmerso en una actividad, frecuentemente asociada con una alta productividad.

Fragmentación

El acto de agrupar conceptos relacionados que pueden almacenarse y procesarse como una sola unidad.

Fuzz testing

Una técnica de prueba de software basada en generar y enviar datos aleatorios.

Hashing

Generar una clave digital pseudo-aleatoria condensada a partir de datos; cualquier entrada específica produce la misma salida, pero es muy probable que diferentes entradas produzcan diferentes salidas.

Inclusión

Trabajar activamente para incluir personas con diversos antecedentes y necesidades.

Indefensión aprendida

Describe el hecho de que las personas aprenden a ni siquiera intentar escapar de comentarios negativos cuando podrían hacerlo, por haber sido sometidas repetidamente a comentarios negativos de los que no tenían forma de escapar.

Instrucción directa

Un método de enseñanza centrado en un diseño curricular meticuloso dictado a través de guiones pre-escritos.

Instrucción por pares

Un método de enseñanza en el que la/el docente hace una pregunta y luego las/los estudiantes se comprometen con una primera respuesta, discuten las respuestas con sus compañeras/os y se comprometen con una respuesta revisada.

Integración computacional

Usar la informática para volver a implementar artefactos culturales preexistentes, por ejemplo, crear variantes de diseños tradicionales usando herramientas de dibujo por computadora.

Intuición

La capacidad de comprender algo de inmediato, sin necesidad aparente de razonamiento consciente.

Inventario de conceptos

Una prueba diseñada para determinar qué tan bien una/un estudiante comprende un dominio. A diferencia de la mayoría de las pruebas realizadas por docentes, los inventarios de conceptos se basan en una extensa investigación y validación.

Jugyokenkyu

Literalmente “estudio de lección”, un conjunto de prácticas que incluye hacer que las/los docentes se observen rutinariamente entre sí y discutan las lecciones que imparten para compartir conocimientos y mejorar habilidades.

Lección de demostración

Una lección dictada por una/un docente a estudiantes reales mientras otras/os docentes observan para aprender nuevas técnicas de enseñanza.

Leer-cubrir-recordar

Una práctica de estudio en la que la/el estudiante cubre hechos o términos clave durante un primer paso por el material y luego verifica cuánto recuerda en un segundo paso.

Gobernanza cooperativa

La gestión conjunta realizada por una comunidad de acuerdo con las reglas que la misma comunidad ha desarrollado y adoptado. En inglés se conoce como commons.

Manual mínimo

Un enfoque de capacitación que divide cada tarea en instrucciones de una sola página que también explican cómo diagnosticar y corregir errores comunes.

Manual

Material de referencia, destinado a ayudar a completar (o recordar) detalles a alguien que ya comprende un tema.

Mapa conceptual

Una imagen de un modelo mental en el que los conceptos son nodos en un gráfico y las relaciones entre esos conceptos son arcos (etiquetados).

Máquina nocional

Un modelo general simplificado de cómo se ejecuta una familia particular de programas.

Marca

Las asociaciones que las personas tienen con el nombre de un producto o identidad.

Marketing

El arte de ver las cosas desde la perspectiva de otras personas, comprender sus deseos y necesidades y encontrar formas de satisfacerlas.

Memoria a corto plazo

La parte de la memoria que almacena brevemente información a la que puede acceder directamente la conciencia. Ver también memoria a largo plazo.

Memoria a largo plazo

La parte de la memoria que almacena información durante largos períodos de tiempo. La memoria a largo plazo es muy grande, pero lenta. Ver también memoria a corto plazo.

Memoria de trabajo

Ver memoria a corto plazo.

Memoria persistente

Ver memoria a largo plazo.

Mentalidad de crecimiento

La creencia de que la habilidad viene con la práctica. Ver también mentalidad fija.

Mentalidad fija

La creencia de que una habilidad es innata y que el fracaso se debe a la falta de algún atributo necesario. Ver también mentalidad de crecimiento.

Metacognición

Pensar acerca de pensar.

MOOC

Ver cursos masivos en línea.

Modelo deficitario

La idea de que algunos grupos están subrepresentados en informática (o algún otro campo) porque sus integrantes carecen de algún atributo o cualidad.

Modelo mental

Una representación simplificada de los elementos clave y las relaciones de algunos dominios de problemas que es lo suficientemente buena como para apoyar la resolución de problemas.

Motivación extrínseca

Ser impulsada/o por recompensas externas como el pago o el miedo al castigo. Ver también motivación intrínseca.

Motivación intrínseca

Ser impulsada/o por el disfrute o la satisfacción de hacer una tarea como fin en sí mismo. Ver también motivación extrínseca.

Motor de optimización de posicionamiento en buscadores

(SEO, por sus siglas en inglés) Aumentar la cantidad y la calidad del tráfico del sitio web al hacer que las páginas sean más fáciles de encontrar o parezcan más importantes para los motores de búsqueda.

Notas guiadas

Notas preparadas por la/el docente para sus estudiantes, en las que se destaca la información clase de una clase o lección.

Novata/o

Alguien que aún no ha construido un modelo mental utilizable de un dominio. Ver también Practicantes competentes y experta/o.

Objetivo de aprendizaje

Qué está intentando lograr enseñar la lección.

Paradoja de la reusabilidad

Sostiene que cuanto más reutilizable es una lección, es menos efectiva pedagógicamente.

Persona tipo

Una breve descripción de una/un estudiante objetivo tipo para una lección, que incluye: sus antecedentes generales, lo que ya sabe, lo que quiere hacer, cómo la lección le ayudará y cualquier necesidad especial que pueda tener.

Participación inicial legítima

La participación de las personas recién llegadas al grupo en tareas simples y de bajo riesgo que una comunidad de práctica reconoce como contribuciones válidas.

Pensamiento computacional

Pensar la resolución de problemas en formas inspiradas en la programación (aunque el término se usa de muchas otras maneras).

Piensa-trabaja en pareja-comparte

Un método de colaboración en el que cada persona piensa individualmente sobre una pregunta o problema, luego se junta con una/un compañera/o para compartir ideas, y luego una persona de cada pareja presenta para todo el grupo.

Poder diagnóstico

El grado en que una respuesta incorrecta a una pregunta o ejercicio le dice a la/el docente qué conceptos erróneos tiene una/un estudiante en particular.

Posicionamiento

Lo que diferencia a una marca de otras marcas similares.

Práctica deliberada

El acto de observar el desempeño de una tarea mientras se realiza para mejorar la capacidad.

Práctica reflexiva

Ver práctica deliberada.

Practicante competente

Alguien que puede realizar tareas normales con un esfuerzo normal en circunstancias normales. Ver también principiante y experta/o.

Pregunta de opción múltiple

Tipo de pregunta cerrada simple que permite a las/los estudiantes seleccionar una respuesta de una lista predefinida de opciones.

Primero objetos

Un enfoque para enseñar programación donde objetos y clases se introducen temprano.

Principiante

. Ver novata/o

Principiante absoluto

Alguien que nunca se ha encontrado con los conceptos o material antes. El término se usa en contraposición con falsa/o principiante.

Privilegio de preparación

La ventaja de provenir de un entorno que proporciona más preparación para una tarea de aprendizaje en particular que para otras.

Problemas de Parsons

Una técnica de evaluación desarrollada por Dale Parsons y otros en la que las/los estudiantes reorganizan el material dado para construir una respuesta correcta a una pregunta. [Pars2006].

Programación en parejas

Una práctica de desarrollo de software en la que dos programadoras/es comparten una computadora. Una persona (la/el piloto) escribe, mientras que la otra (la/el navegante) ofrece comentarios y sugerencias en tiempo real. La programación en parejas a menudo se usa como práctica docente en las clases de programación.

Programación en vivo

El acto de enseñar programación escribiendo software frente a las/los estudiantes a medida que avanza la lección.

Programadora/or conversacional

Alguien que necesita saber lo suficiente sobre computación para tener una conversación significativa con la/el programadora/or, pero que no va a programar por su cuenta.

Psicología educacional

El estudio de cómo la gente aprende. Ver también diseño instruccional.

Pull request

Un conjunto de cambios propuestos a un repositorio de git que pueden revisarse, actualizarse y, finalmente, agregarse al repositorio.

Punto ciego de las personas expertas

La incapacidad de las personas expertas para empatizar con las personas novatas que se encuentran por primera vez con conceptos o prácticas.

Reingeniería

Un método de diseño instruccional que trabaja hacia atrás desde una evaluación sumativa hasta evaluaciones formativas y desde allí al contenido de la lección.

Representación comunitaria

Usar el capital cultural para resaltar las identidades sociales, las historias y las redes comunitarias de las/los estudiantes en las actividades de aprendizaje.

Representación fluida

La capacidad de moverse rápidamente entre diferentes modelos de un problema.

Resultado del aprendizaje

Aquello que la lección realmente logra enseñar.

Revisión por pares calibrada

Hacer que estudiantes comparen sus revisiones del trabajo de ejemplo con las de una/un docente antes de que se les permita revisar el trabajo de sus pares.

Síndrome de la/el impostora/or

Un sentimiento de inseguridad sobre los logros propios, que se manifiesta como un miedo a ser expuesta/o como un fraude.

Sistema de gestión de aprendizaje

(LMS, por sus siglas en inglés): Una aplicación para registrar la inscripción a cursos, presentaciones de ejercicios, calificaciones y otros aspectos burocráticos del aprendizaje formal en el aula.

Tarea auténtica

Una tarea que contiene elementos importantes de cosas que las/los estudiantes harían en situaciones reales (fuera del aula). Para ser auténtica, una tarea debe requerir que las/los estudiantes construyan sus propias respuestas en lugar de elegir entre las respuestas proporcionadas, a la par de trabajar con las mismas herramientas y datos que usarían en la vida real.

Tarjetas de actas

Una técnica de retroalimentación en la que las/los estudiantes pasan un minuto escribiendo una cosa positiva sobre una lección (por ejemplo, una cosa que han aprendido) y una cosa negativa (por ejemplo, una pregunta que aún no ha sido respondida).

Taxonomía de Bloom

Una clasificación jerárquica, ampliamente adoptada, de seis etapas de comprensión y cuyos niveles son conocimiento, comprensión, aplicación, análisis, síntesis y evaluación. Ver también Taxonomía de Fink.

Taxonomía de Fink

Una clasificación de comprensión no jerárquica de seis partes, cuyas categorías son conocimiento fundamental, aplicación, integración, dimensión humana, cuidado y aprender a aprender. Ver también Taxonomía de Bloom.

Transferencia apropiada de procesamiento

La mejora en recordar qué ocurre cuando la práctica utiliza actividades similares a las utilizadas en las pruebas.

Transferencia cercana

Transferencia de aprendizaje entre dominios estrechamente relacionados, por ejemplo, mejora en la comprensión de decimales como resultado de hacer ejercicios con fracciones.

Transferencia de aprendizaje

Aplicar el conocimiento aprendido en un contexto a problemas en otro contexto. Ver también transferencia cercana y transferencia lejana.

Transferencia lejana

La transferencia de aprendizaje entre dominios ampliamente separados, por ejemplo, mejora en las habilidades matemáticas como resultado de jugar al ajedrez.

Tutorial

Una lección destinada a ayudar a alguien a mejorar su comprensión general de un tema.

Sacudir la programación

Hacer que un grupo de personas decida momento a momento o línea por línea qué agregarle a un programa.

Usuaria/o final docente

Por analogía con usuaria/o final programadora/or, alguien que enseña con frecuencia, pero cuya ocupación principal no es la enseñanza, que tiene poca o ninguna experiencia en pedagogía y que puede trabajar fuera de las aulas institucionales.

Usuaria/o final programadora/or

Alguien que no se considera una/un programadora/or, pero que, sin embargo, escribe y depura software, como por ejemplo, un artista que crea macros complejas para una herramienta de dibujo.

Zona de desarrollo próximo

(ZPD, por sus siglas en inglés) Incluye el conjunto de problemas que las personas aún no pueden resolver por sí mismas pero que pueden resolver con la ayuda de un mentor más experimentado. Ver también falla productiva.

Reuniones, reuniones, reuniones

La mayoría de la gente no es muy buena al organizar reuniones: no llevan una agenda, no realizan una minuta o acta de la reunión, hablan vagamente o se desvían en cuestiones irrelevantes, dicen algo trivial o repiten lo que otras personas han dicho sólo para decir algo, y mantienen conversaciones paralelas (lo cual garantiza que la reunión será una pérdida de tiempo). Saber cómo organizar una reunión de manera eficiente es una habilidad central para cualquiera que desee terminar bien un trabajo; saber cómo participar en la reunión de otra persona es igual de importante (y aunque recibe mucha menos atención, como dijo una colega una vez: siempre se ofrece entrenamiento para ser líderes, pero nunca para ser seguidores/as).

Las reglas más importantes para hacer que las reuniones sean eficientes no son secretas, pero rara vez se siguen:

Decide si realmente se necesita una reunión.

Si el único propósito es compartir información, envía un breve correo electrónico en su lugar. Recuerda, puedes leer más rápido que lo que cualquiera puede hablar: si alguien tiene datos para que el resto del equipo los asimile, la forma más educada de comunicarlos es escribirlos.

Escribe un temario.

Si a nadie le importa lo suficiente la reunión como para escribir una lista de puntos de lo que se discutirá, la reunión probablemente no se necesita.

Incluye horarios en el temario.

Incluir el tiempo que le dedicarás a cada punto en el temario, puede ayudarte a evitar que los primeros puntos le roben tiempo a los últimos. Tus primeras estimaciones con cualquier grupo nuevo serán tremendamente optimistas, así que revísalas nuevamente para las siguientes reuniones. Sin embargo, no deberías planear una segunda o tercera reunión porque no alcanzó el tiempo, en cambio, trata de averiguar por qué ocupaste tiempo extra y arregla el problema que lo originó.

Prioriza.

Cada reunión es un microproyecto, por lo tanto el trabajo debería priorizarse de la misma manera que se hace para otros proyectos: aquello que tendrá alto impacto pero lleva poco tiempo debería realizarse primero, y aquello que tomará mucho tiempo pero tiene bajo impacto debería omitirse.

Haz a una persona responsable de mantener las cosas en movimiento.

Una persona debe tener la tarea de mantener el tratamiento de cada punto en la agenda a tiempo, por ejemplo, llamando la atención a la gente que esté revisando el correo electrónico o de aquellas que están teniendo conversaciones paralelas; pidiendo a quienes están hablando mucho que lleguen al punto e invitando a las personas que no intervienen a expresar su opinión. Esta persona no debería ser quien más hable; en realidad, en una reunión bien armada la persona a cargo hablará menos que el resto.

Pide amabilidad.

Que nadie llegue a ser grosero/a, que nadie empiece a divagar. Si alguien se sale del tema, es tanto el derecho como la responsabilidad del moderador/a decir “Discutamos eso en otro momento”.

Sin interrupciones.

Los/las participantes deben levantar la mano o poner una nota adhesiva si quieren hablar después. Si la persona que está hablando no los/las percibe, quien modera la reunión debería hacerlo.

Sin tecnología.

En reuniones presenciales, a menos que sea necesario por razones de accesibilidad, insistir amablemente en que todas las personas guarden sus teléfonos, tabletas y computadoras. (p.ej. Por favor, cierren sus aparatos electrónicos).

Registro de minutas.

Alguna otra persona que no sea quien modere debería tomar notas de forma puntual sobre los fragmentos más importantes de información compartida, todas las decisiones tomadas y todas las tareas que se asignaron a alguna persona.

Toma notas.

Mientras otras personas están hablando, los/las participantes deberían anotar las preguntas que quieran hacer u observaciones que quieran realizar (te sorprenderás lo inteligente que parecerás cuando llegue tu turno para hablar).

Termina temprano.

Si tu reunión está programada de 10:00 a 11:00, debes intentar terminar a las 10:50 para darle tiempo a las personas a pasar por el baño en su camino a donde vayan luego.

Tan pronto termina la reunión, envía a todos un correo electrónico con la minuta o publícala en la web:

La gente que no estuvo en la reunión puede mantenerse al tanto de lo que ocurrió.

Una página web o un mensaje de correo electrónico es una forma mucho más eficiente de ponerse al día que preguntarle a un/a compañero/a de equipo qué te perdiste.

Cualquiera puede comprobar lo que realmente se dijo o prometió.

Más de una vez he revisado la minuta de una reunión en la que estuve y pensé: “¿Yo dije eso?” o “Espera un minuto, ¡yo no prometí tenerlo listo para esa fecha!” Accidentalmente o no, muchas veces la gente recordará las cosas de manera diferente; escribirlo da la oportunidad al equipo de corregir errores, lo que puede ahorrar futuros malos entendidos.

Las personas pueden ser responsables en reuniones posteriores.

No tiene sentido hacer listas de preguntas y puntos de acción si después no los sigues. Si estás utilizando algún tipo de sistema de seguimiento de temas, crea un tema por cada pregunta o tarea justo después de la reunión y actualiza los que se cumplieron, luego comienza cada reunión repasando la lista de esos temas.

[Brow2007,Broo2016,Roge2018] tienen muchos consejos para organizar reuniones. Según mi experiencia, una hora de entrenamiento en cómo ser moderador/a es una de las mejores inversiones que harás.

Notas adhesivas y bingo para interrupción

Algunas personas están tan acostumbradas al sonido de su propia voz que insistirán en hablar la mitad del tiempo sin importar cuántas personas haya en la habitación. Para evitar esto entrega a cada participante tres notas adhesivas al comienzo de la reunión. Cada vez que hablen tienen que sacar una nota adhesiva. Cuando se queden sin notas no se les permitirá hablar hasta que todos hayan usado al menos una. En ese momento todos recuperan sus tres notas adhesivas. Esto asegura que nadie hable más de tres veces que la persona más callada de la reunión, y cambia completamente la dinámica de la mayoría de los grupos: personas que dejan de intentar ser escuchadas porque siempre son tapadas de repente tienen espacio para contribuir, y aquellas que hablaban con demasiada frecuencia se dan cuenta lo injustos/as que han sido²².

Otra técnica es un bingo de interrupción. Dibuja una tabla y etiqueta las filas y columnas con los nombres de los/las participantes. Agrega en la celda apropiada una marca para contar cada vez que alguien interrumpa a otra persona, y toma un momento para compartir los resultados a la mitad de la reunión. En la mayoría de los casos verás que una o dos personas son las que interrumpen siempre, a menudo sin ser conscientes de ello. Eso solo muchas veces es suficiente para detenerlas. Nota que esta técnica está destinada a manejar las interrupciones, no el tiempo de conversación: puede ser apropiado que las personas con más conocimiento de un tema sean las que más hablan de dicho tema en una reunión, pero nunca es apropiado interrumpir repetidamente a las personas.

Las reglas de Martha

Las organizaciones de todo el mundo realizan sus reuniones de acuerdo a Reglas de Orden de Roberto (Robert’s Rules of Order en inglés), pero son mucho más formales que lo requerido para proyectos pequeños. Una ligera alternativa conocida como “Las reglas de Martha” puede que sea mucho mejor para la toma de decisiones por consenso [Mina1986]:

1. Antes de cada reunión cualquiera que lo desee puede patrocinar una propuesta compartiéndola con el grupo. Las propuestas deben ser compartidas al menos 24 horas antes de una reunión para ser consideradas en esa reunión, y deben incluir:

   • un resumen de una línea;

   • el texto completo de la propuesta;

   • cualquier información de antecedentes requerida;

   • pros y contras; y

   • posibles alternativas

   Las propuestas deberían ser a lo sumo de dos páginas.

2. Se establece un quórum en una reunión si la mitad o más de las personas que pueden votar están presentes.

3. Una vez que una persona patrocina una propuesta es responsable de ella. El grupo no puede discutir o votar sobre el tema a menos que quien patrocina o a quien se lo haya delegado esté presente. La persona patrocinadora también es responsable de presentar el tema al grupo.

4. Después que la persona patrocinadora presente la propuesta se emite un voto preliminar para la propuesta antes de cualquier discusión:

   • ¿A quién le gusta la propuesta?

   • ¿A quién le parece razonable la propuesta?

   • ¿Quién se siente incómodo con la propuesta?

   Los votos preliminares se pueden hacer con el pulgar hacia arriba, el pulgar hacia los lados o el pulgar hacia abajo (en persona) o escribiendo +1, 0 o -1 en el chat en línea (en reuniones virtuales).

5. Si a todos/as o a la mayoría del grupo le gusta o resulta razonable la propuesta, se pasa inmediatamente a una votación formal sin más discusión.

6. Si la mayoría del grupo está disconforme con la propuesta se pospone para que la persona patrocinadora pueda volver a trabajar sobre ella.

7. Si parte de los/las participantes se sienten disconformes, se invita a que expresen brevemente sus objeciones. Luego se establece un temporizador para una breve discusión moderada por una persona facilitadora. Después de diez minutos o cuando nadie más tenga algo que agregar (lo que ocurra primero), quien facilita llama a una votación sí-o-no sobre la pregunta: “¿Deberíamos implementar esta decisión aun con las objeciones establecidas?” Si la mayoría vota “sí” la propuesta se implementa. De lo contrario, la propuesta se devuelve a la persona patrocinadora para trabajarla más.

Reuniones en línea

La discusión de Chelsea Troy sobre por qué las reuniones en línea son a menudo frustrantes e improductivas rescata un punto importante: en la mayoría de las reuniones en línea la primera persona en hablar durante una pausa toma la palabra. ¿El resultado? “Si tienes algo que quieres decir, tienes que dejar de escuchar a la persona que está hablando actualmente y en lugar de eso, enfocarte en cuándo van a detenerse o terminar, para que puedas saltar sobre ese nanosegundo de silencio y ser quien primero pueda decir algo. El formato… alienta a los/las participantes que deseen contribuir a decir más y escuchar menos.”

La solución es chatear (charla en texto) a la par de la videoconferencia donde las personas pueden indicar que quieren hablar. Quien modere entonces selecciona personas de la lista de espera. Si la reunión es grande o argumentativa, mantener a todos silenciados y solo permitir a quien modere liberar el micrófono de quienes participan.

La autopsia

Cada proyecto debe terminar con una autopsia en la que los/las participantes reflexionan sobre lo que acaban de lograr y qué podrían mejorar la próxima vez. Su objetivo es no señalar con el dedo a las personas, aunque si eso tiene que suceder, la autopsia es el mejor lugar para ello.

Una autopsia se realiza como cualquier otra reunión con algunas pautas adicionales [Derb2006]:

Conseguir una persona que modere y que no sea parte del proyecto

ni tenga interés en serlo.

Reservar una hora y solo una hora.

Según mi experiencia, nada útil se dice en los primeros diez minutos de la primera autopsia de alguien, dado que las personas son naturalmente un poco tímidas para alabar o condenar su propio trabajo. Igualmente, no se dice nada útil después de la primera hora: si aún sigues hablando, probablemente sea porque una o dos personas tienen cosas que quieren sacarse del pecho en lugar de dar sugerencias para poder mejorar.

Requerir asistencia.

Todas las personas que formaron parte del proyecto deben estar en la sala para la autopsia. Esto es más importante de lo que piensas: las personas que tienen más que aprender de la autopsia en general son menos propensas a presentarse si la reunión es opcional.

Confeccionar dos listas.

Cuando estoy moderando pongo los encabezados “Hazlo otra vez” y “Hazlo diferente” en la pizarra, luego pido a cada persona que me dé una respuesta para cada lista, en orden y sin repetir nada que ya se haya dicho.

Comentar sobre acciones en lugar de individuos.

Para cuando el proyecto esté terminado es posible que algunas personas ya no sean amigas. No dejes que esto desvíe la reunión: si alguien tiene una queja específica sobre otro/a integrante del equipo, pídele que critique un evento o decisión en particular. “Tiene una mala actitud” no ayuda a nadie a mejorar.

Priorizar las recomendaciones.

Una vez que los pensamientos de todos/as estén al descubierto, ordénalos según importancia para mantenerlos y para cambiarlos. Probablemente solo podrás abordar uno o dos de cada lista en tu próximo proyecto, pero si haces eso cada vez tu vida mejorará rápidamente.

Listas de verificación y plantillas

[Gawa2007] hizo popular la idea de que usar listas de verificación puede salvar vidas y estudios más recientes apoyan su efectividad [Avel2013,Urba2014,Rams2019]. En particular, encontramos útiles las listas de verificación cuando hay docentes que recién se incorporan al equipo. Los ejemplos que siguen pueden servirte como material inicial a partir del cual desarrollar tus propias listas de verificación.

Enseñando a evaluar

Esta rúbrica fue diseñada para evaluar lo que se enseñó durante 5 a 10 minutos con diapositivas, programación en vivo o una combinación de ambas estrategias. Valora cada ítem como “Sí,” “Más o menos,” “No,” o “No corresponde (NC).”

Inicio	Presente (usa NC para otras las respuestas si no hay un inicio)
	Adecuada duración (10 a 30 segundos)
	Se presenta
	Presenta el tema que se trabajará
	Describe los requisitos
Contenido	Objetivos claros/narrativa fluida
	Lenguaje inclusivo
	Ejemplos y tareas reales
	Enseña buenas prácticas/utiliza código idiomático
	Señala un camino intermedio entre la Escila de la jerga y la Caribdis de la sobresimplificación
Dando la lección	Voz clara y entendible (usa “Más o menos” o “No” para acentos muy marcados)
	Ritmo: ni muy rápido ni muy lento, no realiza pausas largas o se interrumpe, no aparenta estar leyendo sus notas
	Seguridad: no se pierde en el pozo de alquitrán de la incertidumbre ni tampoco en las colinas de estiércol de la condescendencia
Diapositivas	Usa diapositivas (completa con NC el resto de las respuestas si no usa diapositivas)
	Diapositivas y discurso se complementan uno al otro (programación dual)
	Fuentes y colores legibles; sin bloques de texto abrumadores por su tamaño
	Pantalla: cambia frecuentemente (algo cambia cada 30 segundos)
	Adecuado uso de figuras
Programación en vivo	Usa programación en vivo (completa con NC el resto de las respuestas si no usa programación en vivo)
	Código y discurso se complementan uno al otro
	Fuentes y colores legibles; adecuada cantidad de código en pantalla
	Uso de herramientas de forma adecuada
	Resalta elementos clave del código
	Analiza los errores
Cierre	Presente (valora NC para otras respuestas si el cierre no está presente)
	Adecuada duración (10 a 30 segundos)
	Resume puntos clave
	Presenta un esquema general de los próximos pasos
En general	Puntos claramente conectados y flujo lógico
	Hace que el tema sea interesante (es decir, no aburrido)
	Comprende el tema

Evaluación del grupo docente

Esta rúbrica fue diseñada para evaluar el desempeño de individuos dentro de un grupo. Los ejemplos a continuación pueden servirte como material inicial a partir del cual desarrollar tus propias rúbricas. Valora cada ítem como “Sí,” “Más o menos,” “No,” o “No corresponde (NC).”

Comunicación	Escucha atentamente y sin interrumpir
	Aclara lo que se ha dicho para garantizar la comprensión
	Articula ideas en forma clara y concisa
	Argumenta adecuadamente sus ideas
	Obtiene el apoyo de otras/os integrantes del equipo
Toma de decisiones	Analiza los problemas desde diferentes puntos de vista
	Aplica lógica para resolver problemas
	Propone soluciones basadas en hechos y no en “corazonadas” o intuición
	Invita al resto del equipo a proponer nuevas ideas
	Genera nuevas ideas
	Acepta cambios
Colaboración	Reconoce los problemas que el equipo necesita enfrentar y resolver
	Trabaja para hallar soluciones que sean aceptables para todas las partes involucradas
	Comparte el crédito del éxito con otras/os integrantes del equipo
	Promueve la participación entre todos las/los integrantes del equipo
	Acepta la crítica abiertamente y sin “ponerse a la defensiva”
	Coopera con el equipo
Autogestión	Monitorea sus avances para garantizar que se alcancen los objetivos
	Le da máxima prioridad a obtener resultados
	Define tareas prioritarias para los encuentros de trabajo
	Promueve que otras/os integrantes del equipo manifiesten sus opiniones, incluso si no coinciden con las propias
	Mantiene la atención durante la reunión
	Usa eficientemente el tiempo de reunión
	Sugiere formas de trabajar en las reuniones

Organización de eventos

Las listas de verificación que se presentan a continuación pueden usarse antes, durante y después de un evento.

Programar el evento

• Decidir si será presencial, virtual para un lugar, o virtual para más de un lugar.

• Conversar con la/el disertante sobre sus expectativas y asegurarse de que están de acuerdo en cuanto a quién cubrirá los costos de traslado.

• Definir quiénes podrán participar: ¿será el evento abierto a todas las personas? ¿restringido a integrantes de una organización? ¿una situación intermedia?

• Organizar quiénes serán docentes.

• Organizar el espacio, incluyendo salas para grupos pequeños si fuera necesario.

• Definir la fecha. Si fuera presencial, reservar lo relativo al viaje.

• Conseguir nombres y direcciones de e-mail de participantes a través de la disertante.

• Asegurarse de que la totalidad de las/los participantes esté registrada.

Construir el evento

• Crea una página web con los detalles del taller, que incluya fecha, lugar, y lo que las/los participantes deben traer consigo.

• Confirma las necesidades especiales de las/los participantes.

• Si el evento es virtual prueba el modo de videoconferencia, dos veces.

• Asegúrate que las/los participantes tengan acceso a internet.

• Crea un espacio para compartir apuntes y soluciones a los ejercicios (p.ej. un documento Google Doc (Sección 9.7)).

• Establece contacto con las/los asistentes por correo electrónico con un mensaje de bienvenida que contenga el link a la página del taller, lecturas sobre la temática, la descripción de la configuración que deban hacer en su computadora, una lista de los elementos requeridos para el taller, y un mecanismo para establecer contacto con la/el disertante o docente durante el día.

Al comienzo del evento

• Recuerda a las/los asistentes el código de conducta.

• Toma lista y crea una lista de nombres para pegar en el documento compartido para tomar notas.

• Reparte pequeñas notas adhesivas.

• Asegúrate de que tengan acceso a internet.

• Asegúrate de que pueden acceder al documento compartido.

• Registra información relevante sobre la identificación de las/los asistentes en sus perfiles online.

Al finalizar el evento

• Actualiza la lista de participantes.

• Lleva un registro de la retroalimentación brindada por las/los participantes.

• Haz una copia del documento compartido.

Equipo de viaje

Aquí algunas cosas que las/los docentes llevan consigo a los talleres:

notas adhesivas y caramelos para suavizar la garganta
zapatos cómodos y una pequeña libreta de notas
adaptador de corriente eléctrica de repuesto y camisa de repuesto
desodorante y adaptadores para video
pegatinas (stickers) para computadoras y tus notas (impresas o en una tableta)
barrita de cereal o similar y antiácido (problema de comer al paso)
tarjeta de presentación y anteojos o lentes de contacto de repuesto
libreta y bolígrafo, puntero láser
vaso térmico para té o café (o equipo de mate o tereré) y marcadores de pizarra adicionales
cepillo de dientes o enjuague bucal y toallitas húmedas descartables (puede volcarse algo encima de tu ropa)

Al viajar muchas/os docentes llevan además zapatos deportivos, traje de baño, mat de yoga o el material que necesiten para hacer actividad física. También una conexión WiFi portátil por si la de la habitación no funciona, y alguna memoria USB con los instaladores del software que las/los estudiantes necesitarán para el curso.

Diseño de lecciones

Esta sección resume el diseño de lecciones por el método de reingeniería, que fue desarrollado independientemente por  [Wigg2005,Bigg2011,Fink2013]. Propone una progresión paso a paso para ayudarte a pensar qué hacer en cada uno de los pasos y en el orden adecuado. También proporciona ejercicios breves espaciados para que puedas reorientar o redirigir tu esfuerzo sin demasiadas sorpresas desagradables.

Todo lo que hagas del paso 2 en adelante será parte de tu lección final por lo que no estarás perdiendo en tiempo: como se describió en el Capítulo 6, construir ejercicios de práctica desde el comienzo te ayuda a asegurarte de que todo lo que preguntes a las/los estudiantes contribuirá a los objetivos de la lección y que todo lo que necesitan saber está cubierto.

Los pasos se describen en orden creciente de detalle pero el proceso en sí es siempre iterativo. Con frecuencia y a medida que resuelvas preguntas más avanzadas, volverás a revisar tus respuestas en trabajos anteriores, y te darás cuenta que tu plan inicial no iba a funcionar como pensaste originalmente.

¿Para quién es esta lección?

Crea algunas personas tipo (Sección 6.1) o (mejor aún) elige entre los que tú y tus colegas han creado para uso general. Cada estudiante tipo debe tener:

1. un contexto general,

2. lo que ya sabe,

3. lo que cree que quiere saber y

4. qué necesidades especiales tiene.

 
Ejercicio breve: resumen breve de a quién estás intentando ayudar.

¿Cuál es la idea principal?

Responde tres o cuatro de las siguientes preguntas sólo enumerando elementos para ayudarte a descifrar el enfoque de la lección. No necesitas responder todas las preguntas, y puedes plantear y responder otras preguntas si crees que ayudarán, pero debes incluir sí o sí un par de respuestas a la primera pregunta. Además, en esta etapa puedes crear un mapa conceptual (Sección 3.1).

• ¿Qué problemas aprenderán a resolver?

• ¿Cuáles conceptos y técnicas aprenderán?

• ¿Cuáles herramientas tecnológicas, paquetes y funciones usarán?

• ¿Qué términos de jerga definirás?

• ¿Qué analogías usarás para explicar conceptos?

• ¿Qué errores o conceptos erróneos esperas encontrar?

• ¿Qué conjuntos de datos utilizarás?

 
Ejercicio breve enfoque general y sin detalles de la lección. Compártelo con una/un colega — una breve devolución en esta instancia puede ahorrar horas de esfuerzo más tarde.

¿Qué harán tus estudiantes durante la lección?

Establece los objetivos del paso 2 escribiendo descripciones detalladas de algunos ejercicios que tus estudiantes serán capaces de resolver al final de la lección. Hacer esto es análogo al desarrollo impulsado por pruebas: en vez de trabajar en función de un conjunto de objetivos de aprendizaje (probablemente ambiguos), hazlo “hacia atrás”: elabora ejemplos concretos que quieres que puedan resolver tus estudiantes. Esto además permite dejar en evidencia requisitos técnicos necesarios que de otro modo podrían no descubrirse hasta que fuera demasiado tarde.

Para complementar la descripción detallada de los ejercicios, escribe la descripción de uno o dos ejercicios para cada hora de lección como una lista de conceptos breve. De este modo, puedes visualizar qué tan rápido esperas que tus estudiantes avancen. De nuevo, esto permitirá tener una visión realista sobre lo que asumiste de tus estudiantes y ayudará a hacer evidentes los requisitos técnicos necesarios para resolver el ejercicio. Una manera de elaborar estos ejercicios adicionales es hacer una lista con las habilidades que necesitan para resolver los ejercicios principales y crear un ejercicio que aborde cada una.

 
Ejercicio breve: 1 a 2 ejercicios explicados de principio a fin que usen las habilidades que tus estudiantes van a aprender, y una media docena de ejercicios con su solución esquematizada. Incluye soluciones completas para que puedas asegurarte de que el programa que usen funciona.

¿Cómo están conectados los conceptos

Coloca los ejercicios que creaste en un orden lógico y a partir de ellos deriva el esquema general de una lección. El esquema debe tener entre 3 a 4 ítems por hora de clase con una evaluación formativa para cada uno. En esta etapa es común que modifiques las evaluaciones de forma que puedan basarse sobre las anteriores.

 
Ejercicio breve: el esquema de una lección. Es muy probable que te encuentres con que te habías olvidado de algunos elementos y que no están incluidos en tu trabajo hasta aquí, así que no te sorprendas si debes ir y venir varias veces.

Descripción general de la lección

Ahora puedes escribir la descripción general de la lección que incluya:

• un párrafo de descripción (es decir, un discurso de venta para tus estudiantes),

• media docena de objetivos de aprendizaje y

• un resumen de los requisitos.

Hacer esto antes suele ser un esfuerzo inútil ya que el material que compone la lección aumenta, se recorta o cambia de lugar en las etapas anteriores.

 
Ejercicio breve: descripción del curso, objetivos de aprendizaje y requisitos.

Cuestionario de pre-evaluación

Este cuestionario ayuda a las/los docentes a estimar el conocimiento previo sobre programación de las/los participantes en un taller introductorio a JavaScript. Las preguntas y respuestas son concretas y el cuestionario es corto, para que no resulte intimidante.

1. ¿Cuál de estas opciones describe mejor tu experiencia con la programación en general?

   • No tengo ninguna experiencia.

   • He escrito unas pocas líneas de código alguna vez.

   • He escrito programas para uso personal de un par de páginas de extensión.

   • He escrito y mantenido porciones grandes de programas.
     

2. ¿Cuál de estas opciones describe mejor tu experiencia con la programación en JavaScript?

   • No tengo ninguna experiencia.

   • He escrito unas pocas líneas de código alguna vez.

   • He escrito programas para uso personal de un par de páginas de extensión.

   • He escrito y mantenido porciones grandes de programas.
     

3. ¿Cuál de estas opciones describe mejor cuán fácil te resultaría escribir un programa en el lenguaje de programación que prefieras para hallar el número más alto en una lista?

   • No sabría por dónde comenzar.

   • Podría resolverlo con prueba y error y realizando bastantes búsquedas en internet.

   • Lo resolvería rápido con poco o nada de ayuda externa.
     

4. ¿Cuál de estas opciones describe mejor cuán fácil te resultaría escribir un programa en JavaScript para hallar y cambiar a mayúscula todos los títulos de una página web?

   • No sabría por dónde comenzar.

   • Podría resolverlo con prueba y error y realizando bastantes búsquedas en internet.

   • Lo resolvería rápido con poco o nada de ayuda externa.
     

5. ¿Qué te gustaría saber o poder hacer al finalizar esta clase que no sabes o puedes hacer ahora?

Ejemplos de mapas conceptuales

Estos mapas conceptuales fueron creados por Amy Hodge de la Universidad de Stanford y se reutilizan con su permiso.

Solución del ejercicio de particionar

Mira el último ejercicio en el Capítulo 3 para la representación completa de estos símbolos.

Referencias

Abba2012

Janet Abbate: Recoding Gender: Women's Changing Participation in Computing. MIT Press, 2012, 9780262534536. Describe las carreras y logros de las mujeres que dieron forma a la historia temprana de la informática, pero que con demasiada frecuencia se han eliminado de esa historia.

Abel2009

Andrew Abela: "Chart Suggestions - A Thought Starter". http://extremepresentation.typepad.com/files/choosing-a-good-chart-09.pdf, 2009. Un árbol de decisión visual para elegir el tipo correcto de gráfico.

Adam1975

Frank Adams and Myles Horton: Unearthing Seeds of Fire: The Idea of Highlander. Blair, 1975, 0895870193. Una historia del Centro de Investigación y Educación Highlander, anteriormente conocido como \emphHighlander Folk School y su fundador, Myles Horton.

Aike1975

Edwin G. Aiken, Gary S. Thomas, and William A. Shennum: "Memory for a Lecture: Effects of Notes, Lecture Rate, and Informational Density". Journal of Educational Psychology, 67(3), 1975, doi:10.1037/h0076613. Un primer estudio de referencia que muestra que tomar notas mejora la retención del conocimiento.

Aiva2016

Efthimia Aivaloglou and Felienne Hermans: "How Kids Code and How We Know". In 2016 International Computing Education Research Conference (ICER'16), 2016, doi:10.1145/2960310.2960325. Presenta un análisis de 250.000 proyectos de Scratch.

Alin1989

Saul D. Alinsky: Rules for Radicals: A Practical Primer for Realistic Radicals. Vintage, 1989, 0679721134. Una guía ampliamente leída sobre la organización comunitaria escrita por uno de los grandes organizadores del siglo XX.

Alqa2017

Basma S. Alqadi and Jonathan I. Maletic: "An Empirical Study of Debugging Patterns Among Novice Programmers". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017761. Informa patrones en las actividades de depuración y tasas de éxito de personas novatas en programación.

Alvi1999

Jennifer Alvidrez and Rhona S. Weinstein: "Early Teacher Perceptions and Later Student Academic Achievement". Journal of Educational Psychology, 91(4), 1999, doi:10.1037/0022-0663.91.4.731. Un estudio influyente sobre los efectos de las percepciones de los/las docentes sobre los/las estudiantes en sus logros posteriores.

Ambr2010

Susan A. Ambrose, Michael W. Bridges, Michele DiPietro, Marsha C. Lovett, and Marie K. Norman: How Learning Works: Seven Research-Based Principles for Smart Teaching. Jossey-Bass, 2010, 0470484101. Resume lo que sabemos sobre educación y por qué creemos que es verdad, desde la psicología cognitiva hasta los factores sociales.

Ande2001

Lorin W. Anderson and David R. Krathwohl (eds.): A Taxonomy for Learning, Teaching, And Assessing: A Revision of Bloom's Taxonomy of Educational Objectives. Longman, 2001, 080131903X. Una revisión ampliamente utilizada de la taxonomía de Bloom.

Armo2008

Michal Armoni and David Ginat: "Reversing: A Fundamental Idea in Computer Science". Computer Science Education, 18(3), 9 2008, doi:10.1080/08993400802332670. Sostiene que la noción de revertir las cosas es un concepto fundamental no reconocido en la educación informática.

Atki2000

Robert K. Atkinson, Sharon J. Derry, Alexander Renkl, and Donald Wortham: "Learning from Examples: Instructional Principles from the Worked Examples Research". Review of Educational Research, 70(2), 6 2000, doi:10.3102/00346543070002181. Un relevamiento completo de la investigación de ejemplos resueltos hasta ese momento.

Auro2019

Valerie Aurora and Mary Gardiner: How to Respond to Code of Conduct Reports. Frame Shift Consulting LLC, 2019, 978-1386922575. Una breve guía práctica para hacer cumplir un Código de Conducta.

Avel2013

Emma-Louise Aveling, Peter McCulloch, and Mary Dixon-Woods: "A Qualitative Study Comparing Experiences of the Surgical Safety Checklist in Hospitals in High-Income and Low-Income Countries". BMJ Open, 3(8), 8 2013, doi:10.1136/bmjopen-2013-003039. Informa sobre la eficacia de las implementaciones de listas de verificación quirúrgicas en el Reino Unido y África.

Bacc2013

Alberto Bacchelli and Christian Bird: "Expectations, Outcomes, and Challenges of Modern Code Review". In 2013 International Conference on Software Engineering (ICSE'13), 5 2013. Un resumen del trabajo sobre revisión de código.

Bari2017

Titus Barik, Justin Smith, Kevin Lubick, Elisabeth Holmes, Jing Feng, Emerson Murphy-Hill, and Chris Parnin: "Do Developers Read Compiler Error Messages?". In 2017 International Conference on Software Engineering (ICSE'17), 5 2017, doi:10.1109/icse.2017.59. Informa que los/las desarrolladores/as leen mensajes de error y que hacerlo es tan difícil como leer el código fuente: toma entre un 13 y un 25\% del tiempo total de la tarea.

Bark2014

Lecia Barker, Christopher Lynnly Hovey, and Leisa D. Thompson: "Results of a Large-Scale, Multi-Institutional Study of Undergraduate Retention in Computing". In 2014 Frontiers in Education Conference (FIE'14), 10 2014, doi:10.1109/fie.2014.7044267. Reporta que las tareas significativas, la interacción del cuerpo docente con los/las estudiantes, la colaboración de los/las estudiantes en las tareas y (para los estudiantes varones) el ritmo y la carga de trabajo en relación con las expectativas impulsan la retención en las clases de computación, mientras que las interacciones con ayudantes o con sus pares en las actividades extracurriculares tienen poco impacto.

Bark2015

Lecia Barker, Christopher Lynnly Hovey, and Jane Gruning: "What Influences CS Faculty to Adopt Teaching Practices?". In 2015 Technical Symposium on Computer Science Education (SIGCSE'15), 2015, doi:10.1145/2676723.2677282. Describe cómo los/las docentes de informática adoptan nuevas prácticas de enseñanza.

Basi1987

Victor R. Basili and Richard W. Selby: "Comparing the Effectiveness of Software Testing Strategies". IEEE Transactions on Software Engineering, SE-13(12), 12 1987, doi:10.1109/tse.1987.232881. Un primer e influyente resumen sobre la efectividad de la revisión del código.

Basu2015

Soumya Basu, Albert Wu, Brian Hou, and John DeNero: "Problems Before Solutions: Automated Problem Clarification at Scale". In 2015 Conference on Learning @ Scale (L@S'15), 2015, doi:10.1145/2724660.2724679. Describe un sistema en el que los/las estudiantes tienen que desbloquear casos de prueba para su código respondiendo preguntas frecuentes y presenta datos que demuestran que esta práctica es efectiva.

Batt2018

Lina Battestilli, Apeksha Awasthi, and Yingjun Cao: "Two-Stage Programming Projects: Individual Work Followed by Peer Collaboration". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159486. Informa que los resultados del aprendizaje mejoraron mediante proyectos de dos etapas en los que los/las estudiantes trabajan individualmente y luego vuelven a resolver el mismo problema en parejas.

Baue2015

Mark S. Bauer, Laura Damschroder, Hildi Hagedorn, Jeffrey Smith, and Amy M. Kilbourne: "An Introduction to Implementation Science for the Non-Specialist". BMC Psychology, 3(1), 9 2015, doi:10.1186/s40359-015-0089-9. Explica qué es la ciencia de la implementación, utilizando ejemplos de la Administración de Veteranos de EE.UU. para ilustrarla.

Beck2013

Leland Beck and Alexander Chizhik: "Cooperative Learning Instructional methods for CS1: Design, Implementation, and Evaluation". ACM Transactions on Computing Education, 13(3), 8 2013, doi:10.1145/2492686. Informa que el aprendizaje cooperativo mejora los resultados del aprendizaje y la autoeficacia en CS1.

Beck2014

Victoria Beck: "Testing a Model to Predict Online Cheating---Much Ado About Nothing". Active Learning in Higher Education, 15(1), 1 2014, doi:10.1177/1469787413514646. Reporta que hacer trampa no es más probable en los cursos en línea que en los cursos presenciales.

Beck2016

Brett A. Becker, Graham Glanville, Ricardo Iwashima, Claire McDonnell, Kyle Goslin, and Catherine Mooney: "Effective Compiler Error Message Enhancement for Novice Programming Students". Computer Science Education, 26(2-3), 7 2016, doi:10.1080/08993408.2016.1225464. Reporta que los mensajes de error mejorados ayudaron a las personas principiantes a aprender más rápido.

Beni2017

Gal Beniamini, Sarah Gingichashvili, Alon Klein Orbach, and Dror G. Feitelson: "Meaningful Identifier Names: The Case of Single-Letter Variables". In 2017 International Conference on Program Comprehension (ICPC'17), 5 2017, doi:10.1109/icpc.2017.18. Informa que el uso de nombres de variables de una sola letra no afecta la capacidad de modificar el código y que algunos nombres de variables de una sola letra tienen tipos y significados implícitos.

Benn2007a

Jens Bennedsen and Michael E. Caspersen: "Failure Rates in Introductory Programming". ACM SIGCSE Bulletin, 39(2), 6 2007, doi:10.1145/1272848.1272879. Informa que el 67\% de los/las estudiantes aprueba CS1, con una variación del 5\% al 100\%.

Benn2007b

Jens Bennedsen and Carsten Schulte: "What Does ``Objects-first'' Mean?: An International Study of Teachers' Perceptions of Objects-first". In 2007 Koli Calling Conference on Computing Education Research (Koli'07), 2007. Descubre tres significados de ``objetos primero'' en la educación informática.

Benn2000

Patricia Benner: From Novice to Expert: Excellence and Power in Clinical Nursing Practice. Pearson, 2000, 0130325228. Un estudio clásico del juicio clínico y el desarrollo de la experiencia.

Berg2012

Joseph Bergin, Jane Chandler, Jutta Eckstein, Helen Sharp, Mary Lynn Manns, Klaus Marquardt, Marianna Sipos, Markus Völter, and Eugene Wallingford: Pedagogical Patterns: Advice for Educators. CreateSpace, 2012, 9781479171828. Un catálogo de patrones de diseño para la docencia.

Biel1995

Katerine Bielaczyc, Peter L. Pirolli, and Ann L. Brown: "Training in Self-Explanation and Self-Regulation Strategies: Investigating the Effects of Knowledge Acquisition Activities on Problem Solving". Cognition and Instruction, 13(2), 6 1995, doi:10.1207/s1532690xci1302_3. Informa que la formación de los/las estudiantes en la autoexplicación acelera su aprendizaje.

Bigg2011

John Biggs and Catherine Tang: Teaching for Quality Learning at University. Open University Press, 2011, 0335242758. Una guía paso a paso para el desarrollo, la enseñanza y la evaluación de lecciones para personas que trabajan en la educación superior.

Bink2012

Dave Binkley, Marcia Davis, Dawn Lawrie, Jonathan I. Maletic, Christopher Morrell, and Bonita Sharif: "The Impact of Identifier Style on Effort and Comprehension". Empirical Software Engineering, 18(2), 5 2012, doi:10.1007/s10664-012-9201-4. Reporta que leer y comprender código es fundamentalmente diferente de leer prosa y que los/las desarrolladores/as con experiencia no se ven relativamente afectados/as por el estilo del identificador, pero las personas principiantes se benefician del uso del Camel case (frente al pothole case).

Blik2014

Paulo Blikstein, Marcelo Worsley, Chris Piech, Mehran Sahami, Steven Cooper, and Daphne Koller: "Programming Pluralism: Using Learning Analytics to Detect Patterns in the Learning of Computer Programming". Journal of the Learning Sciences, 23(4), 10 2014, doi:10.1080/10508406.2014.954750. Reporte de un intento de categorizar el comportamiento de una persona novata en programación mediante el uso de aprendizaje automático, que encontró patrones interesantes en las tareas individuales.

Bloo1984

Benjamin S. Bloom: "The 2 Sigma Problem: The Search for Methods of Group Instruction as Effective as One-to-One Tutoring". Educational Researcher, 13(6), 6 1984, doi:10.3102/0013189x013006004. Informa que los/las estudiantes que recibieron tutoría individual usando técnicas de dominio de aprendizaje aprenden mejor por dos desviaciones estándar que quienes aprendieron a través de una clase convencional.

Boll2014

David Bollier: Think Like a Commoner: A Short Introduction to the Life of the Commons. New Society Publishers, 2014, 0865717680. Una breve introducción a un modelo de gobernanza ampliamente utilizado.

Boha2011

Mark Bohay, Daniel P. Blakely, Andrea K. Tamplin, and Gabriel A. Radvansky: "Note Taking, Review, Memory, and Comprehension". American Journal of Psychology, 124(1), 2011, doi:10.5406/amerjpsyc.124.1.0063. Informa que tomar notas mejora la retención en niveles más profundos de comprensión.

Borr2014

Maura Borrego and Charles Henderson: "Increasing the Use of Evidence-Based Teaching in STEM Higher Education: A Comparison of Eight Change Strategies". Journal of Engineering Education, 103(2), 4 2014, doi:10.1002/jee.20040. Categoriza diferentes enfoques para lograr cambios en la educación superior.

Bria2015

Samuel A. Brian, Richard N. Thomas, James M. Hogan, and Colin Fidge: "Planting Bugs: A System for Testing Students' Unit Tests". In 2015 Conference on Innovation and Technology in Computer Science Education (ITiCSE'15), 2015, doi:10.1145/2729094.2742631. Describe una herramienta para evaluar los programas de los/las estudiantes y las pruebas unitarias, y descubre que los/las estudiantes a menudo escriben pruebas débiles y no entienden el papel de las pruebas unitarias.

Broo2016

Stephen D. Brookfield and Stephen Preskill: The Discussion Book: 50 Great Ways to Get People Talking. Jossey-Bass, 2016, 9781119049715. Describe cincuenta formas diferentes de lograr que los grupos hablen de manera productiva.

Brop1983

Jere E. Brophy: "Research on the Self-Fulfilling Prophecy and Teacher Expectations". Journal of Educational Psychology, 75(5), 1983, doi:10.1037/0022-0663.75.5.631. Un estudio inicial e influyente de los efectos de las percepciones de los/las docentes sobre los logros de los/las estudiantes.

Brow2007

Michael Jacoby Brown: Building Powerful Community Organizations: A Personal Guide to Creating Groups that Can Solve Problems and Change the World. Long Haul Press, 2007, 0977151808. Una guía práctica para crear organizaciones eficaces en y para las comunidades.

Brow2017

Neil C. C. Brown and Amjad Altadmri: "Novice Java Programming Mistakes". ACM Transactions on Computing Education, 17(2), 5 2017, doi:10.1145/2994154. Resume el análisis de los autores de errores de programación para principiantes.

Brow2018

Neil C. C. Brown and Greg Wilson: "Ten Quick Tips for Teaching Programming". PLoS Computational Biology, 14(4), 4 2018, doi:10.1371/journal.pcbi.1006023. Un breve resumen de lo que realmente sabemos sobre la enseñanza de la programación y por qué creemos que es cierto.

Buff2015

Kevin Buffardi and Stephen H. Edwards: "Reconsidering Automated Feedback: A Test-Driven Approach". In 2015 Technical Symposium on Computer Science Education (SIGCSE'15), 2015, doi:10.1145/2676723.2677313. Describe un sistema que asocia las pruebas fallidas con características particulares en el código de un/a estudiante para que los/las estudiantes no puedan jugar con el sistema.

Burg2015

Sheryl E. Burgstahler: Universal Design in Higher Education: From Principles to Practice. Harvard Education Press, 2015, 9781612508160. Describe cómo hacer que los materiales didácticos en línea sean accesibles para todas las personas.

Burk2018

Quinn Burke, Cinamon Bailey, Louise Ann Lyon, and Emily Greeen: "Understanding the Software Development Industry's Perspective on Coding Boot Camps Versus Traditional 4-Year Colleges". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159485. Compara las habilidades y credenciales que buscan los/las reclutadores/as de la industria de la tecnología con las que brindan las carrera de grado de cuatro años y los campamentos de entrenamiento.

Butl2017

Zack Butler, Ivona Bezakova, and Kimberly Fluet: "Pencil Puzzles for Introductory Computer Science". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017765. Describe acertijos de lápiz y papel que se pueden convertir en tareas de CS1/CS2, e informa que los/las estudiantes disfrutan de estos ejercicios y que fomentan la metacognición.

Byck2005

Pauli Byckling, Petri Gerdt, and Jorma Sajaniemi: "Roles of Variables in Object-Oriented Programming". In 2005 Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA'05), 2005, doi:10.1145/1094855.1094972. Presenta patrones de diseño de una sola variable comunes en programas de principiantes.

Camp2016

Jennifer Campbell, Diane Horton, and Michelle Craig: "Factors for Success in Online CS1". In 2016 Conference on Innovation and Technology in Computer Science Education (ITiCSE'16), 2016, doi:10.1145/2899415.2899457. Compara a estudiantes que optaron por una clase de CS1 en línea con quienes la tomaron en persona en un aula invertida.

Carr1987

John Carroll, Penny Smith-Kerker, James Ford, and Sandra Mazur-Rimetz: "The Minimal Manual". Human-Computer Interaction, 3(2), 6 1987, doi:10.1207/s15327051hci0302_2. El artículo fundacional sobre la instrucción minimalista.

Carr2014

John Carroll: "Creating Minimalist Instruction". International Journal of Designs for Learning, 5(2), 11 2014, doi:10.14434/ijdl.v5i2.12887. Una mirada retrospectiva al trabajo del autor sobre la instrucción minimalista.

Cart2017

Adam Scott Carter and Christopher David Hundhausen: "Using Programming Process Data to Detect Differences in Students' Patterns of Programming". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017785. Muestra que los/las estudiantes de diferentes niveles abordan las tareas de programación de manera diferente y que estas diferencias se pueden detectar automáticamente.

Casp2007

Michael E. Caspersen and Jens Bennedsen: "Instructional Design of a Programming Course". In 2007 International Computing Education Research Conference (ICER'07), 2007, doi:10.1145/1288580.1288595. Pasa de un modelo de cognición humana a tres teorías de aprendizaje, y de ahí al diseño de un curso introductorio de programación orientada a objetos.

Cele2018

Mehmet Celepkolu and Kristy Elizabeth Boyer: "Thematic Analysis of Students' Reflections on Pair Programming in CS1". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159516. Informa que la programación en parejas tiene las mismas ganancias de aprendizaje que la programación en paralelo, pero una mayor satisfacción de los/las estudiantes.

Ceti2016

Ibrahim Cetin and Christine Andrews-Larson: "Learning Sorting Algorithms Through Visualization Construction". Computer Science Education, 26(1), 1 2016, doi:10.1080/08993408.2016.1160664. Informa que la gente aprende más al construir visualizaciones de algoritmos que al ver visualizaciones construidas por otras personas.

Chen2009

Nicholas Chen and Maurice Rabb: "A Pattern Language for Screencasting". In 2009 Conference on Pattern Languages of Programs (PLoP'09), 2009, doi:10.1145/1943226.1943234. Una colección breve y bien organizada de consejos para hacer grabación de pantalla.

Chen2017

Nick Cheng and Brian Harrington: "The Code Mangler: Evaluating Coding Ability Without Writing Any Code". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017704. Informa que el rendimiento de los/las estudiantes en los ejercicios en los que deshacen manipulación de código se correlaciona fuertemente con el rendimiento en las evaluaciones tradicionales.

Chen2018

Chen Chen, Paulina Haduong, Karen Brennan, Gerhard Sonnert, and Philip Sadler: "The effects of first programming language on college students' computing attitude and achievement: a comparison of graphical and textual languages". Computer Science Education, 29(1), 11 2018, doi:10.1080/08993408.2018.1547564. Encuentra que los/las estudiantes cuyo primer lenguaje fue el gráfico obtuvieron calificaciones más altas que los/las estudiantes cuyo primer lenguaje fue textual cuando se introdujeron esos idiomas en la adolescencia o antes.

Cher2007

Mauro Cherubini, Gina Venolia, Rob DeLine, and Amy J. Ko: "Let's Go to the Whiteboard: How and Why Software Developers Use Drawings". In 2007 Conference on Human Factors in Computing Systems (CHI'07), 2007, doi:10.1145/1240624.1240714. Informa que los/las desarrolladores/as dibujan diagramas para ayudarse en la discusión en lugar de documentar los diseños.

Cher2009

Sapna Cheryan, Victoria C. Plaut, Paul G. Davies, and Claude M. Steele: "Ambient Belonging: How Stereotypical Cues Impact Gender Participation in Computer Science". Journal of Personality and Social Psychology, 97(6), 2009, doi:10.1037/a0016239. Informa que pistas ambientales sutiles tienen un impacto medible en el interés que las personas de diferentes géneros tienen en la informática.

Chet2014

Raj Chetty, John N. Friedman, and Jonah E. Rockoff: "Measuring the Impacts of Teachers II: Teacher Value-Added and Student Outcomes in Adulthood". American Economic Review, 104(9), 9 2014, doi:10.1257/aer.104.9.2633. Informa que los/las buenos/as docentes tienen un impacto pequeño pero medible en los resultados de los/las estudiantes.

Chi1989

Michelene T. H. Chi, Miriam Bassok, Matthew W. Lewis, Peter Reimann, and Robert Glaser: "Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems". Cognitive Science, 13(2), 4 1989, doi:10.1207/s15516709cog1302_1. Un artículo fundacional sobre el poder de la autoexplicación.

Coco2018

Center for Community Organizations: "The ``Problem'' Woman of Colour in the Workplace". https://coco-net.org/problem-woman-colour-nonprofit-organizations/, 2018. Describe la experiencia de muchas mujeres de color en su lugar de trabajo.

Coll1991

Allan Collins, John Seely Brown, and Ann Holum: "Cognitive Apprenticeship: Making Thinking Visible". American Educator, 6, 1991. Describe un modelo educativo basado en la noción de aprendizaje y orientación maestra.

Coom2012

Norman Coombs: Making Online Teaching Accessible. Jossey-Bass, 2012, 9781458725288. Una guía accesible para hacer accesibles las lecciones en línea.

Covi2017

Martin V. Covington, Linda M. von Hoene, and Dominic J. Voge: Life Beyond Grades: Designing College Courses to Promote Intrinsic Motivation. Cambridge University Press, 2017, 9780521805230. Explora formas de equilibrar la motivación intrínseca y extrínseca en la educación institucional.

Craw2010

Matthew B. Crawford: Shop Class as Soulcraft: An Inquiry into the Value of Work. Penguin, 2010, 9780143117469. Un análisis profundo de lo que aprendemos sobre nosotros/as mismos/as al realizar determinados tipos de trabajo.

Crou2001

Catherine H. Crouch and Eric Mazur: "Peer Instruction: Ten Years of Experience and Results". American Journal of Physics, 69(9), 9 2001, doi:10.1119/1.1374249. Informa los resultados de los primeros diez años de instrucción entre pares en las clases de física de pregrado y describe las formas en que su implementación cambió durante ese tiempo.

Csik2008

Mihaly Csikszentmihaly: Flow: The Psychology of Optimal Experience. Harper, 2008, 978-0061339202. Una discusión influyente sobre lo que significa estar completamente inmerso/a en una tarea.

Cunn2017

Kathryn Cunningham, Sarah Blanchard, Barbara J. Ericson, and Mark Guzdial: "Using Tracing and Sketching to Solve Programming Problems". In 2017 Conference on International Computing Education Research (ICER'17), 2017, doi:10.1145/3105726.3106190. Descubre que escribir nuevos valores cerca de los nombres de las variables a medida que cambian es la técnica de rastreo más efectiva.

Cutt2017

Quintin Cutts, Charles Riedesel, Elizabeth Patitsas, Elizabeth Cole, Peter Donaldson, Bedour Alshaigy, Mirela Gutica, Arto Hellas, Edurne Larraza-Mendiluze, and Robert McCartney: "Early Developmental Activities and Computing Proficiency". In 2017 Conference on Innovation and Technology in Computer Science Education (ITiCSE'17), 2017, doi:10.1145/3174781.3174789. Se encuestó a personas adultas usuarias de computadoras sobre las actividades de su infancia y se encontró una fuerte correlación entre la confianza y el uso de la computadora basado en poder leer por su cuenta y a jugar con juguetes de construcción sin partes móviles (como los Lego).

Dage2010

Barthélémy Dagenais, Harold Ossher, Rachel K. E. Bellamy, Martin P. Robillard, and Jacqueline P. de Vries: "Moving Into a New Software Project Landscape". In 2010 International Conference on Software Engineering (ICSE'10), 2010, doi:10.1145/1806799.1806842. Una mirada a cómo las personas se mueven de un proyecto o dominio a otro.

Dahl2018

Sarah Dahlby Albright, Titus H. Klinge, and Samuel A. Rebelsky: "A Functional Approach to Data Science in CS1". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159550. Describe el diseño de una clase CS1 basada en la ciencia de datos.

Deb2018

Debzani Deb, Muztaba Fuad, James Etim, and Clay Gloster: "MRS: Automated Assessment of Interactive Classroom Exercises". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159607. Reporta que hacer ejercicios en clase con comentarios en tiempo real utilizando dispositivos móviles mejoró la retención de conceptos y la participación de los/las estudiantes al tiempo que redujo las tasas de falla.

DeBr2015

Pedro De Bruyckere, Paul A. Kirschner, and Casper D. Hulshof: Urban Myths about Learning and Education. Academic Press, 2015, 9780128015377. Describe y desacredita algunos mitos generalizados sobre cómo aprenden las personas.

Denn2019

Paul Denny, Brett A. Becker, Michelle Craig, Greg Wilson, and Piotr Banaszkiewicz: "Research This! Questions that Computing Educators Most Want Computing Education Researchers to Answer". In 2019 Conference on International Computing Education Research (ICER'19), 2019. Encontró poca superposición entre las preguntas que más interesan a los/las investigadores en educación informática y las preguntas que los/las profesionales quieren responder.

Derb2006

Esther Derby and Diana Larsen: Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2006, 0977616649. Describe cómo ejecutar una buena revisión de proyectos.

Deve2018

Gabriel A. Devenyi, Rémi Emonet, Rayna M. Harris, Kate L. Hertweck, Damien Irving, Ian Milligan, and Greg Wilson: "Ten Simple Rules for Collaborative Lesson Development". PLoS Computational Biology, 14(3), 3 2018, doi:10.1371/journal.pcbi.1005963. Describe cómo desarrollar lecciones juntos/as.

Dida2016

David Didau and Nick Rose: What Every Teacher Needs to Know About Psychology. John Catt Educational, 2016, 1909717851. Una explicación informativa y opinada de lo que la psicología moderna tiene que decir sobre la enseñanza.

DiSa2014a

Betsy DiSalvo, Mark Guzdial, Amy Bruckman, and Tom McKlin: "Saving Face While Geeking Out: Video Game Testing as a Justification for Learning Computer Science". Journal of the Learning Sciences, 23(3), 7 2014, doi:10.1080/10508406.2014.893434. Encontró que el 65\% de los hombres afroamericanos que participaron en un programa de prueba de juegos decidió estudiar informática.

DiSa2014b

Betsy DiSalvo, Cecili Reid, and Parisa Khanipour Roshan: "They Can't Find Us". In 2014 Technical Symposium on Computer Science Education (SIGCSE'14), 2014, doi:10.1145/2538862.2538933. Informa que los términos de búsqueda que los padres y las madres probablemente usarían para buscar las clases de informática extraescolar no fueron útiles para encontrar esas clases.

Douc2005

Christopher Douce, David Livingstone, and James Orwell: "Automatic Test-Based Assessment of Programming". Journal on Educational Resources in Computing, 5(3), 9 2005, doi:10.1145/1163405.1163409. Revisa el estado de los autocalificadores hasta la fecha del trabajo.

DuBo1986

Benedict Du Boulay: "Some Difficulties of Learning to Program". Journal of Educational Computing Research, 2(1), 2 1986, doi:10.2190/3lfx-9rrf-67t8-uvk9. Introduce la idea de una máquina teórica/nocional.

Edwa2014a

Stephen H. Edwards, Zalia Shams, and Craig Estep: "Adaptively Identifying Non-Terminating Code when Testing Student Programs". In 2014 Technical Symposium on Computer Science Education (SIGCSE'14), 2014, doi:10.1145/2538862.2538926. Describe un esquema adaptativo para detectar envíos de codificación de estudiantes que no terminan.

Edwa2014b

Stephen H. Edwards and Zalia Shams: "Do Student Programmers All Tend to Write the Same Software Tests?". In 2014 Conference on Innovation and Technology in Computer Science Education (ITiCSE'14), 2014, doi:10.1145/2591708.2591757. Informa que los/las estudiantes escribieron pruebas para el ``camino feliz'' en lugar de detectar errores ocultos.

Endr2014

Stefan Endrikat, Stefan Hanenberg, Romain Robbes, and Andreas Stefik: "How Do API Documentation and Static Typing Affect API Usability?". In 2014 International Conference on Software Engineering (ICSE'14), 2014, doi:10.1145/2568225.2568299. Muestra que los tipos agregan complejidad a los programas, pero se amortiza con bastante rapidez al actuar como sugerencias de documentación para el uso de un método.

Ensm2003

Nathan L. Ensmenger: "Letting the ``Computer Boys'' Take Over: Technology and the Politics of Organizational Transformation". International Review of Social History, 48(S11), 12 2003, doi:10.1017/s0020859003001305. Describe cómo la programación pasó de ser una profesión femenina a una masculina en la década de 1960.

Ensm2012

Nathan L. Ensmenger: The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise. MIT Press, 2012, 9780262517966. Rastrea el surgimiento y ascenso de los expertos en informática en el siglo XX y, en particular, la forma en que la informática adquirió un género masculino.

Eppl2006

Martin J. Eppler: "A Comparison Between Concept Maps, Mind Maps, Conceptual Diagrams, and Visual Metaphors as Complementary Tools for Knowledge Construction and Sharing". Information Visualization, 5(3), 6 2006, doi:10.1057/palgrave.ivs.9500131. Compara mapas conceptuales, mapas mentales, diagramas conceptuales y metáforas visuales como herramientas de aprendizaje.

Epst2002

Lewis Carroll Epstein: Thinking Physics: Understandable Practical Reality. Insight Press, 2002, 0935218084. Una entretenida introducción basada en problemas para pensar como un/a físico/a.

Eric2015

Barbara J. Ericson, Steven Moore, Briana B. Morrison, and Mark Guzdial: "Usability and Usage of Interactive Features in an Online Ebook for CS Teachers". In 2015 Workshop in Primary and Secondary Computing Education (WiPSCE'15), 2015, doi:10.1145/2818314.2818335. Informa que es más probable que los/las estudiantes intenten problemas de Parsons que preguntas de opción múltiple cercanas en un libro electrónico.

Eric2016

K. Anders Ericsson: "Summing Up Hours of Any Type of Practice Versus Identifying Optimal Practice Activities". Perspectives on Psychological Science, 11(3), 5 2016, doi:10.1177/1745691616635600. Una crítica de un meta\-estudio sobre la práctica deliberada basada en la inclusión de actividades demasiado amplias de este último.

Eric2017

Barbara J. Ericson, Lauren E. Margulieux, and Jochen Rick: "Solving Parsons Problems versus Fixing and Writing Code". In 2017 Koli Calling Conference on Computing Education Research (Koli'17), 2017, doi:10.1145/3141880.3141895. Informa que resolver problemas de Parsons 2D con distractores lleva menos tiempo que escribir o corregir código, pero tiene resultados de aprendizaje equivalentes.

Farm2006

Eugene Farmer: "The Gatekeeper's Guide, or How to Kill a Tool". IEEE Software, 23(6), 11 2006, doi:10.1109/ms.2006.174. Diez reglas irónicas para asegurarse de que no se adopte una nueva herramienta de software.

Fehi2008

Chris Fehily: SQL: Visual QuickStart Guide. Peachpit Press, 2008, 0321553578. Una introducción a SQL que es tanto un buen tutorial como una buena guía de referencia.

Finc2007

Sally Fincher and Josh Tenenberg: "Warren's Question". In 2007 International Computing Education Research Conference (ICER'07), 2007, doi:10.1145/1288580.1288588. Una mirada detallada a un caso particular de transferencia de una práctica docente.

Finc2012

Sally Fincher, Brad Richards, Janet Finlay, Helen Sharp, and Isobel Falconer: "Stories of Change: How Educators Change Their Practice". In 2012 Frontiers in Education Conference (FIE'12), 10 2012, doi:10.1109/fie.2012.6462317. Una mirada detallada a cómo los/las docentes adoptan realmente nuevas prácticas de enseñanza.

Finc2019

Sally Fincher and Anthony Robins (eds.): The Cambridge Handbook of Computing Education Research. Cambridge University Press, 2019, 978-1108721899. Un resumen de 900 páginas de lo que sabemos sobre educación informática.

Fink2013

L. Dee Fink: Creating Significant Learning Experiences: An Integrated Approach to Designing College Courses. Jossey-Bass, 2013, 1118124251. Una guía paso a paso para un proceso sistemático de diseño de lecciones.

Fisc2015

Lars Fischer and Stefan Hanenberg: "An empirical investigation of the effects of type systems and code completion on API usability using TypeScript and JavaScript in MS Visual Studio". In 11th Symposium on Dynamic Languages (DLS'15), 2015, doi:10.1145/2816707.2816720. Descubre que la escritura estática mejoraba la eficiencia del programador/a independientemente de la finalización del código.

Fisl2014

Kathi Fisler: "The Recurring Rainfall Problem". In 2014 International Computing Education Research Conference (ICER'14), 2014, doi:10.1145/2632320.2632346. Informa que los/las estudiantes cometieron menos errores de bajo nivel al resolver el problema de la lluvia en un lenguaje funcional.

Fitz2008

Sue Fitzgerald, Gary Lewandowski, Renée McCauley, Laurie Murphy, Beth Simon, Lynda Thomas, and Carol Zander: "Debugging: Finding, Fixing and Flailing, a Multi-Institutional Study of Novice Debuggers". Computer Science Education, 18(2), 6 2008, doi:10.1080/08993400802114508. Informa que los/las buenos/as depuradores/as de pregrado son buenos/as programadores/as, pero no necesariamente al revés, y que las personas principiantes utilizan el rastreo y las pruebas en lugar del razonamiento causal.

Ford2016

Denae Ford, Justin Smith, Philip J. Guo, and Chris Parnin: "Paradise Unplugged: Identifying Barriers for Female Participation on Stack Overflow". In 2016 International Symposium on Foundations of Software Engineering (FSE'16), 2016, doi:10.1145/2950290.2950331. Reporta que la falta de conocimiento de las características del sitio, la sensación de no estar calificada para responder preguntas, el tamaño de la comunidad, la incomodidad al interactuar con gente extraña o depender de ella y la percepción de que no deberían estar holgazaneando fueron considerados significativamente más problemáticos por las colaboradoras de Stack Overflow que por los colaboradores.

Foge2005

Karl Fogel: Producing Open Source Software: How to Run a Successful Free Software Project. O'Reilly Media, 2005, 0596007590. La guía definitiva para la gestión de proyectos de desarrollo de software de código abierto.

Fran2018

Pablo Frank-Bolton and Rahul Simha: "Docendo Discimus: Students Learn by Teaching Peers Through Video". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159466. Informa que los/las estudiantes que hacen videos cortos para enseñar conceptos a sus pares tienen un aumento significativo en su propio aprendizaje en comparación con quienes solo estudian el material o ven videos.

Free1972

Jo Freeman: "The Tyranny of Structurelessness". The Second Wave, 2(1), 1972. Señala que toda organización tiene una estructura de poder: la única pregunta es si es responsable o no.

Free2014

S. Freeman, S. L. Eddy, M. McDonough, M. K. Smith, N. Okoroafor, H. Jordt, and M. P. Wenderoth: "Active learning increases student performance in science, engineering, and mathematics". Proc. National Academy of Sciences, 111(23), 5 2014, doi:10.1073/pnas.1319030111. Presenta un metaanálisis de los beneficios del aprendizaje activo.

Frie2016

Marilyn Friend and Lynne Cook: Interactions: Collaboration Skills for School Professionals. Pearson, 2016, 0134168542. Un libro de texto sobre cómo los/las docentes pueden trabajar con otros/as docentes.

Galp2002

Vashti Galpin: "Women in Computing Around the World". ACM SIGCSE Bulletin, 34(2), 6 2002, doi:10.1145/543812.543839. Analiza la participación femenina en informática en 35 países.

Gauc2011

Danielle Gaucher, Justin Friesen, and Aaron C. Kay: "Evidence that Gendered Wording in Job Advertisements Exists and Sustains Gender Inequality". Journal of Personality and Social Psychology, 101(1), 2011, doi:10.1037/a0022530. Informa que la marca de género en la redacción de los materiales y anuncios de contratación laboral puede mantener la desigualdad de género en ocupaciones tradicionalmente dominadas por hombres.

Gawa2007

Atul Gawande: "The Checklist". The New Yorker, 12 2007. Describe los efectos de las listas de verificación simples para salvar vidas.

Gawa2011

Atul Gawande: "Personal Best". The New Yorker, 10 2011. Describe cómo tener un/a entrenador/a puede mejorar la práctica en una variedad de campos.

Gick1987

Mary L. Gick and Keith J. Holyoak: "The Cognitive Basis of Knowledge Transfer". In Transfer of Learning: Contemporary Research and Applications, Elsevier, 1987, doi:10.1016/b978-0-12-188950-0.50008-4. Encuentra que la transferencia solo llega con maestría.

Gorm2014

Cara Gormally, Mara Evans, and Peggy Brickman: "Feedback About Teaching in Higher Ed: Neglected Opportunities to Promote Change". Cell Biology Education, 13(2), 6 2014, doi:10.1187/cbe.13-12-0235. Resume las mejores prácticas para proporcionar una devolución instruccional y recomienda algunas estrategias específicas.

Gree2014

Elizabeth Green: Building a Better Teacher: How Teaching Works (and How to Teach It to Everyone). W. W. Norton & Company, 2014, 0393351084. Explica por qué la mayoría de las reformas educativas de los últimos cincuenta años han fallado y qué deberíamos hacer en su lugar.

Grif2016

Jean M. Griffin: "Learning by Taking Apart". In 2016 Conference on Information Technology Education (SIGITE'16), 2016, doi:10.1145/2978192.2978231. Informa que las personas aprenden a programar más rápidamente deconstruyendo el código que escribiéndolo.

Grov2017

Shuchi Grover and Satabdi Basu: "Measuring Student Learning in Introductory Block-Based Programming". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017723. Informa que los/las estudiantes de nivel medio que utilizan programación basada en bloques encuentran que los bucles, las variables y los operadores booleanos son difíciles de entender.

Gull2004

Ned Gulley: "In Praise of Tweaking". interactions, 11(3), 5 2004, doi:10.1145/986253.986264. Describe un concurso innovador de codificación colaborativa.

Guo2013

Philip J. Guo: "Online Python Tutor". In 2013 Technical Symposium on Computer Science Education (SIGCSE'13), 2013, doi:10.1145/2445196.2445368. Describe el diseño y uso de una herramienta de visualización de ejecución basada en web.

Guo2014

Philip J. Guo, Juho Kim, and Rob Rubin: "How Video Production Affects Student Engagement". In 2014 Conference on Learning @ Scale (L@S'14), 2014, doi:10.1145/2556325.2566239. Mide la participación de los/las estudiantes con los videos de los MOOC y reporta que los videos cortos son más atractivos que los largos y que ver la cara de las personas hablando es más atractivo que dibujos en tabletas.

Guzd2013

Mark Guzdial: "Exploring Hypotheses about Media Computation". In 2013 International Computing Education Research Conference (ICER'13), 2013, doi:10.1145/2493394.2493397. Una mirada retrospectiva a diez años de investigación en computación de medios.

Guzd2015a

Mark Guzdial: Learner-Centered Design of Computing Education: Research on Computing for Everyone. Morgan & Claypool Publishers, 2015, 9781627053518. Sostiene que debemos diseñar la educación informática para todas las personas, no solo para las que creen que se van a convertir en programadores/as profesionales.

Guzd2015b

Mark Guzdial: "Top 10 Myths About Teaching Computer Science". https://cacm.acm.org/blogs/blog-cacm/189498-top-10-myths-about-teaching-computer-science/fulltext, 2015. Diez cosas que mucha gente cree sobre la enseñanza de la informática que simplemente no son ciertas.

Guzd2016

Mark Guzdial: "Five Principles for Programming Languages for Learners". https://cacm.acm.org/blogs/blog-cacm/203554-five-principles-for-programming-languages-for-learners/fulltext, 2016. Explica cómo elegir un lenguaje de programación para personas que son nuevas en programación.

Haar2017

Lassi Haaranen: "Programming as a Performance - Live-streaming and Its Implications for Computer Science Education". In 2017 Conference on Innovation and Technology in Computer Science Education (ITiCSE'17), 2017, doi:10.1145/3059009.3059035. Una mirada temprana a la transmisión en vivo de la programación como técnica de enseñanza.

Hagg2016

M. S. Hagger, N. L. D. Chatzisarantis, H. Alberts, C. O. Anggono, C. Batailler, A. R. Birt, R. Brand, M. J. Brandt, G. Brewer, S. Bruyneel, D. P. Calvillo, W. K. Campbell, P. R. Cannon, M. Carlucci, N. P. Carruth, T. Cheung, A. Crowell, D. T. D. De Ridder, S. Dewitte, M. Elson, J. R. Evans, B. A. Fay, B. M. Fennis, A. Finley, Z. Francis, E. Heise, H. Hoemann, M. Inzlicht, S. L. Koole, L. Koppel, F. Kroese, F. Lange, K. Lau, B. P. Lynch, C. Martijn, H. Merckelbach, N. V. Mills, A. Michirev, A. Miyake, A. E. Mosser, M. Muise, D. Muller, M. Muzi, D. Nalis, R. Nurwanti, H. Otgaar, M. C. Philipp, P. Primoceri, K. Rentzsch, L. Ringos, C. Schlinkert, B. J. Schmeichel, S. F. Schoch, M. Schrama, A. Schütz, A. Stamos, G. Tinghög, J. Ullrich, M. vanDellen, S. Wimbarti, W. Wolff, C. Yusainy, O. Zerhouni, and M. Zwienenberg: "A Multilab Preregistered Replication of the Ego-Depletion Effect". Perspectives on Psychological Science, 11(4), 2016, doi:10.1177/1745691616652873. Un metanálisis que encontró evidencia insuficiente que corrobore el efecto de agotamiento del ego.

Hake1998

Richard R. Hake: "Interactive Engagement versus Traditional Methods: A Six-Thousand-Student Survey of Mechanics Test Data for Introductory Physics Courses". American Journal of Physics, 66(1), 1 1998, doi:10.1119/1.18809. Informa sobre el uso de un inventario de conceptos para medir los beneficios del compromiso interactivo como técnica de enseñanza.

Hamo2017

Sally Hamouda, Stephen H. Edwards, Hicham G. Elmongui, Jeremy V. Ernst, and Clifford A. Shaffer: "A Basic Recursion Concept Inventory". Computer Science Education, 27(2), 4 2017, doi:10.1080/08993408.2017.1414728. Informa el trabajo inicial sobre el desarrollo de un inventario de conceptos para la recursividad.

Hank2011

Brian Hanks, Sue Fitzgerald, Renée McCauley, Laurie Murphy, and Carol Zander: "Pair Programming in Education: a Literature Review". Computer Science Education, 21(2), 6 2011, doi:10.1080/08993408.2011.579808. Informa un aumento de las tasas de éxito y retención con la programación en parejas, con alguna evidencia de que es particularmente beneficiosa para las mujeres, pero encuentra que la coordinación y la compatibilidad de la pareja pueden ser problemáticas.

Hann2009

Jo Erskine Hannay, Tore Dybå, Erik Arisholm, and Dag I. K. Sjøberg: "The Effectiveness of Pair Programming: A Meta-analysis". Information and Software Technology, 51(7), 7 2009, doi:10.1016/j.infsof.2009.02.001. Un metaanálisis completo de la investigación sobre la programación en parejas.

Hann2010

Jo Erskine Hannay, Erik Arisholm, Harald Engvik, and Dag I. K. Sjøberg: "Effects of Personality on Pair Programming". IEEE Transactions on Software Engineering, 36(1), 1 2010, doi:10.1109/tse.2009.41. Informa una correlación débil entre los rasgos de personalidad de los ``Cinco grandes'' y el rendimiento en la programación en parejas.

Hans2015

John D. Hansen and Justin Reich: "Democratizing education? Examining access and usage patterns in massive open online courses". Science, 350(6265), 12 2015, doi:10.1126/science.aab3782. Informa que los MOOC son utilizados principalmente por personas con alto poder adquisitivo.

Harm2016

Kyle James Harms, Jason Chen, and Caitlin L. Kelleher: "Distractors in Parsons Problems Decrease Learning Efficiency for Young Novice Programmers". In 2016 International Computing Education Research Conference (ICER'16), 2016, doi:10.1145/2960310.2960314. Muestra que agregar distractores a los problemas de Parsons no mejora los resultados del aprendizaje, pero aumenta los tiempos de solución.

Harr2018

Brian Harrington and Nick Cheng: "Tracing vs. Writing Code: Beyond the Learning Hierarchy". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159530. Encuentra que la brecha entre ser capaz de rastrear código y ser capaz de escribirlo se ha cerrado en gran medida por CS2 y que los/las estudiantes que todavía tienen una brecha (en cualquier dirección) probablemente tengan un desempeño pobre en el curso.

Hazz2014

Orit Hazzan, Tami Lapidot, and Noa Ragonis: Guide to Teaching Computer Science: An Activity-Based Approach. Springer, 2014, 9781447166290. Un libro de texto para enseñar ciencias de la computación en el nivel K-12 con docenas de actividades.

Hend2015a

Charles Henderson, Renée Cole, Jeff Froyd, Debra Friedrichsen, Raina Khatri, and Courtney Stanford: Designing Educational Innovations for Sustained Adoption. Increase the Impact, 2015, 0996835210. Un análisis detallado de las estrategias para lograr que las instituciones de educación superior realicen cambios.

Hend2015b

Charles Henderson, Renée Cole, Jeff Froyd, Debra Friedrichsen, Raina Khatri, and Courtney Stanford: "Designing Educational Innovations for Sustained Adoption (Executive Summary)". http://www.increasetheimpact.com/resources.html, 2015. Un breve resumen de los puntos clave del trabajo de los/las autores/as sobre cómo efectuar cambios en la educación superior.

Hend2017

Carl Hendrick and Robin Macpherson: What Does This Look Like In The Classroom?: Bridging The Gap Between Research And Practice. John Catt Educational, 2017, 9781911382379. Una colección de respuestas de personas expertas en educación a las preguntas formuladas por docentes en aulas, con prefacios de los autores.

Henr2010

Joseph Henrich, Steven J. Heine, and Ara Norenzayan: "The Weirdest People in the World?". Behavioral and Brain Sciences, 33(2-3), 6 2010, doi:10.1017/s0140525x0999152x. Señala que los sujetos de la mayoría de los estudios psicológicos publicados son personas occidentales, con educación, industrializadas, ricas y viviendo en democracias.

Hest1992

David Hestenes, Malcolm Wells, and Gregg Swackhamer: "Force Concept Inventory". The Physics Teacher, 30(3), 3 1992, doi:10.1119/1.2343497. Describe la motivación, el diseño y el impacto del Force Concept Inventory (\emphForce Concept Inventory en inglés).

Hick2018

Marie Hicks: Programmed Inequality: How Britain Discarded Women Technologists and Lost Its Edge in Computing. MIT Press, 2018, 9780262535182. Describe cómo Gran Bretaña perdió su dominio temprano en la informática al discriminar sistemáticamente a sus trabajadoras más calificadas: las mujeres.

Hofm2017

Johannes Hofmeister, Janet Siegmund, and Daniel V. Holt: "Shorter Identifier Names Take Longer to Comprehend". In 2017 Conference on Software Analysis, Evolution and Reengineering (SANER'17), 2 2017, doi:10.1109/saner.2017.7884623. Informa que el uso de palabras completas para nombrar variables hace que la comprensión sea más rápida que el uso de abreviaturas o nombres de una sola letra.

Holl1960

Jack Hollingsworth: "Automatic Graders for Programming Classes". Communications of the ACM, 3(10), 10 1960, doi:10.1145/367415.367422. Una breve nota que describe lo que pudo haber sido la primera calificadora automática del mundo.

Hu2017

Helen H. Hu, Cecily Heiner, Thomas Gagne, and Carl Lyman: "Building a Statewide Computer Science Teacher Pipeline". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017788. Informa que un programa de seis meses para docentes de secundaria que se están entrenando para enseñar informática cuadriplica el número de docentes sin una reducción notable de los resultados de los/las estudiantes y aumenta la creencia de los docentes de que cualquiera puede programar.

Hust2012

Therese Huston: Teaching What You Don't Know. Harvard University Press, 2012, 0674066170. Una exploración puntual, divertida y muy útil de exactamente lo que dice el título: enseñar lo que no conoces.

Ihan2010

Petri Ihantola, Tuukka Ahoniemi, Ville Karavirta, and Otto Seppälä: "Review of Recent Systems for Automatic Assessment of Programming Assignments". In 2010 Koli Calling Conference on Computing Education Research (Koli'10), 2010, doi:10.1145/1930464.1930480. Revisa las herramientas de calificación automática de la época.

Ihan2011

Petri Ihantola and Ville Karavirta: "Two-dimensional Parson's Puzzles: The Concept, Tools, and First Observations". Journal of Information Technology Education: Innovations in Practice, 10, 2011, doi:10.28945/1394. Describe una herramienta de problemas de Parsons 2D y las primeras experiencias con ella que confirman que las personas expertas resuelven de afuera hacia adentro en lugar de línea por línea.

Ihan2016

Petri Ihantola, Kelly Rivers, Miguel Ángel Rubio, Judy Sheard, Bronius Skupas, Jaime Spacco, Claudia Szabo, Daniel Toll, Arto Vihavainen, Alireza Ahadi, Matthew Butler, Jürgen Börstler, Stephen H. Edwards, Essi Isohanni, Ari Korhonen, and Andrew Petersen: "Educational Data Mining and Learning Analytics in Programming: Literature Review and Case Studies". In 2016 Conference on Innovation and Technology in Computer Science Education (ITiCSE'16), 2016, doi:10.1145/2858796.2858798. Un estudio de los métodos utilizados en la minería y el análisis de datos de programación.

Ijss2000

Wijnand A. IJsselsteijn, Huib de Ridder, Jonathan Freeman, and Steve E. Avons: "Presence: Concept, Determinants, and Measurement". In 2000 Conference on Human Vision and Electronic Imaging, 6 2000, doi:10.1117/12.387188. Resume el pensamiento de la época sobre presencia real y virtual.

Irib2009

Alicia Iriberri and Gondy Leroy: "A Life-Cycle Perspective on Online Community Success". ACM Computing Surveys, 41(2), 2 2009, doi:10.1145/1459352.1459356. Revisa la investigación sobre comunidades en línea organizadas según un modelo de ciclo de vida de cinco etapas.

Juss2005

Lee Jussim and Kent D. Harber: "Teacher Expectations and Self-Fulfilling Prophecies: Knowns and Unknowns, Resolved and Unresolved Controversies". Personality and Social Psychology Review, 9(2), 5 2005, doi:10.1207/s15327957pspr0902_3. Un relevamiento sobre los efectos de las expectativas de los/las docentes en los resultados de los/las estudiantes.

Kaly2003

Slava Kalyuga, Paul Ayres, Paul Chandler, and John Sweller: "The Expertise Reversal Effect". Educational Psychologist, 38(1), 3 2003, doi:10.1207/s15326985ep3801_4. Informa que las técnicas de instrucción que funcionan bien con estudiantes sin experiencia pierden su eficacia o tienen consecuencias negativas cuando se utilizan con estudiantes con más experiencia.

Kaly2015

Slava Kalyuga and Anne-Marie Singh: "Rethinking the Boundaries of Cognitive Load Theory in Complex Learning". Educational Psychology Review, 28(4), 12 2015, doi:10.1007/s10648-015-9352-0. Sostiene que la teoría de la carga cognitiva es básicamente una microgestión dentro de un contexto pedagógico más amplio.

Kang2016

Sean H. K. Kang: "Spaced Repetition Promotes Efficient and Effective Learning". Policy Insights from the Behavioral and Brain Sciences, 3(1), 1 2016, doi:10.1177/2372732215624708. Resume la investigación sobre la repetición espaciada y lo que significa para la enseñanza en el aula.

Kapu2016

Manu Kapur: "Examining Productive Failure, Productive Success, Unproductive Failure, and Unproductive Success in Learning". Educational Psychologist, 51(2), 4 2016, doi:10.1080/00461520.2016.1155457. Considera el fracaso productivo como una alternativa al aprendizaje basado en la investigación y enfoques basados en la teoría de la carga cognitiva.

Karp2008

Jeffrey D. Karpicke and Henry L. Roediger: "The Critical Importance of Retrieval for Learning". Science, 319(5865), 2 2008, doi:10.1126/science.1152408. Reporta que las pruebas repetidas mejoran la memorización de listas de palabras de un 35\% a un 80\%, incluso cuando los/las estudiantes aún pueden acceder al material pero no se les realiza la prueba.

Kauf2000

Deborah B. Kaufman and Richard M. Felder: "Accounting for Individual Effort in Cooperative Learning Teams". Journal of Engineering Education, 89(2), 2000. Informa que la autoevaluación y las calificaciones entre pares en los cursos de pregrado están de acuerdo, que la confabulación no es significativa, que los/las estudiantes no inflan sus autoevaluaciones y que las calificaciones no están sesgadas por cuestiones de género o por racismo.

Keme2009

Chris F. Kemerer and Mark C. Paulk: "The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data". IEEE Transactions on Software Engineering, 35(4), 7 2009, doi:10.1109/tse.2009.27. Utiliza datos individuales para explorar la efectividad de la revisión del código.

Kepp2008

Jeroen Keppens and David Hay: "Concept Map Assessment for Teaching Computer Programming". Computer Science Education, 18(1), 3 2008, doi:10.1080/08993400701864880. Una breve revisión de las formas en que se puede utilizar el mapeo de conceptos en la educación informática.

Kern1978

Brian W. Kernighan and P. J. Plauger: The Elements of Programming Style. McGraw-Hill, 1978, 0070342075. Una descripción inicial e influyente de la filosofía de programación de Unix.

Kern1983

Brian W. Kernighan and Rob Pike: The Unix Programming Environment. Prentice-Hall, 1983, 013937681X. Una descripción inicial e influyente de Unix.

Kern1988

Brian W. Kernighan and Dennis M. Ritchie: The C Programming Language. Prentice-Hall, 1988, 0131103628. El libro que convirtió a C en un lenguaje de programación popular.

Kern1999

Brian W. Kernighan and Rob Pike: The Practice of Programming. Addison-Wesley, 1999, 9788177582482. Un manual de estilo de programación escrito por dos de los creadores de la informática moderna.

Keun2016a

Hieke Keuning, Johan Jeuring, and Bastiaan Heeren: "Towards a Systematic Review of Automated Feedback Generation for Programming Exercises". In 2016 Conference on Innovation and Technology in Computer Science Education (ITiCSE'16), 2016, doi:10.1145/2899415.2899422. Informa que las herramientas de autoevaluación a menudo no brindan retroalimentación sobre qué hacer a continuación y que los/las docentes no pueden adaptar fácilmente la mayoría de las herramientas a sus necesidades.

Keun2016b

Hieke Keuning, Johan Jeuring, and Bastiaan Heeren: "Towards a Systematic Review of Automated Feedback Generation for Programming Exercises - Extended Version". Technical Report UU-CS-2016-001, Utrecht University, 2016. Una mirada ampliada a los mensajes de devolución de las herramientas de autoevaluación.

Kim2017

Ada S. Kim and Amy J. Ko: "A Pedagogical Analysis of Online Coding Tutorials". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017728. Informa que los tutoriales de programación en línea enseñan en gran medida contenido similar, organizan el contenido de abajo hacia arriba y brindan prácticas dirigidas a objetivos con retroalimentación inmediata, pero no se adaptan al conocimiento previo de programación de los/las estudiantes y generalmente no les dicen a los/las estudiantes cómo transferir y aplicar el conocimiento.

King1993

Alison King: "From Sage on the Stage to Guide on the Side". College Teaching, 41(1), 1 1993, doi:10.1080/87567555.1993.9926781. Una propuesta incial para dar vuelta la clase.

Kirk1994

Donald L. Kirkpatrick: Evaluating Training Programs: The Four Levels. Berrett-Koehle, 1994, 1881052494. Define un modelo de cuatro niveles ampliamente utilizado para evaluar la formación.

Kirs2006

Paul A. Kirschner, John Sweller, and Richard E. Clark: "Why Minimal Guidance During Instruction does not Work: An Analysis of the Failure of Constructivist, Discovery, Problem-Based, Experiential, and Inquiry-Based Teaching". Educational Psychologist, 41(2), 6 2006, doi:10.1207/s15326985ep4102_1. Sostiene que el aprendizaje basado en la indagación es menos efectivo para los/las principiantes que la instrucción guiada.

Kirs2013

Paul A. Kirschner and Jeroen J. G. van Merriënboer: "Do Learners Really Know Best? Urban Legends in Education". Educational Psychologist, 48(3), 7 2013, doi:10.1080/00461520.2013.804395. Sostiene que tres mitos de aprendizaje (nativos/as digitales, estilos de aprendizaje y autoeducadores/as) reflejan la creencia errónea que los/las estudiantes saben qué es lo mejor para ellos/as y advierte que podemos estar en una espiral descendente en la que cada intento de que los/las investigadores/as de la educación refuten estos mitos confirma la creencia de sus oponentes de que la ciencia de la educación y el aprendizaje es pseudociencia.

Kirs2018

Paul A. Kirschner, John Sweller, Femke Kirschner, and Jimmy Zambrano R.: "From Cognitive Load Theory to Collaborative Cognitive Load Theory". International Journal of Computer-Supported Collaborative Learning, 4 2018, doi:10.1007/s11412-018-9277-y. Extiende la teoría de la carga cognitiva para incluir aspectos colaborativos del aprendizaje.

Koed2015

Kenneth R. Koedinger, Jihee Kim, Julianna Zhuxin Jia, Elizabeth A. McLaughlin, and Norman L. Bier: "Learning is Not a Spectator Sport: Doing is Better than Watching for Learning from a MOOC". In 2015 Conference on Learning @ Scale (L@S'15), 2015, doi:10.1145/2724660.2724681. Mide los beneficios de hacer en lugar de mirar.

Koeh2013

Matthew J. Koehler, Punya Mishra, and William Cain: "What is Technological Pedagogical Content Knowledge (TPACK)?". Journal of Education, 193(3), 2013, doi:10.1177/002205741319300303. Refina la discusión sobre el conocimiento de contenido pedagógico, agregando tecnología, y esboza estrategias para desarrollar la comprensión de cómo usarla.

Kohn2017

Tobias Kohn: "Variable Evaluation: An Exploration of Novice Programmers' Understanding and Common Misconceptions". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017724. Informa que los/las estudiantes a menudo creen en la evaluación retrasada o que las ecuaciones completas se almacenan en variables.

Koll2015

Michael Kölling: "Lessons From the Design of Three Educational Programming Environments". International Journal of People-Oriented Programming, 4(1), 1 2015, doi:10.4018/ijpop.2015010102. Compara tres generaciones de entornos de programación destinados a un uso novato.

Krau2016

Robert E. Kraut and Paul Resnick: Building Successful Online Communities: Evidence-Based Social Design. MIT Press, 2016, 0262528916. Resume lo que realmente sabemos sobre cómo crear comunidades en línea prósperas y por qué creemos que es cierto.

Krug1999

Justin Kruger and David Dunning: "Unskilled and Unaware of it: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments". Journal of Personality and Social Psychology, 77(6), 1999, doi:10.1037/0022-3514.77.6.1121. El informe original sobre el efecto Dunning-Kruger: cuanto menos sabe la gente, menos precisa es su estimación de su conocimiento.

Kuch2011

Marc J. Kuchner: Marketing for Scientists: How to Shine in Tough Times. Island Press, 2011, 1597269948. Una guía breve y accesible para que las personas conozcan y se preocupen por tu trabajo.

Kuit2004

Marja Kuittinen and Jorma Sajaniemi: "Teaching Roles of Variables in Elementary Programming Courses". ACM SIGCSE Bulletin, 36(3), 9 2004, doi:10.1145/1026487.1008014. Presenta algunos patrones utilizados en la programación para personas novatas y el valor pedagógico de enseñarlos.

Kulk2013

Chinmay Kulkarni, Koh Pang Wei, Huy Le, Daniel Chia, Kathryn Papadopoulos, Justin Cheng, Daphne Koller, and Scott R. Klemmer: "Peer and Self Assessment in Massive Online Classes". ACM Transactions on Computer-Human Interaction, 20(6), 12 2013, doi:10.1145/2505057. Muestra que la calificación por pares puede ser tan efectiva a escala como la calificación por personas expertas.

Laba2008

David F. Labaree: "The Winning Ways of a Losing Strategy: Educationalizing Social Problems in the United States". Educational Theory, 58(4), 11 2008, doi:10.1111/j.1741-5446.2008.00299.x. Explora por qué Estados Unidos sigue impulsando la solución de problemas sociales a las instituciones educativas y por qué eso sigue sin funcionar.

Lach2018

Michael Lachney: "Computational Communities: African-American Cultural Capital in Computer Science Education". Computer Science Education, 2 2018, doi:10.1080/08993408.2018.1429062. Explora el uso de la representación comunitaria y la integración computacional para unir la computación y el capital cultural afroamericano en la educación informática.

Lake2018

George Lakey: How We Win: A Guide to Nonviolent Direct Action Campaigning. Melville House, 2018, 978-1612197531. Una breve guía basada en la experiencia para campañas efectivas.

Lang2013

James M. Lang: Cheating Lessons: Learning from Academic Dishonesty. Harvard University Press, 2013, 0674724631. Explora por qué los/las estudiantes hacen trampa y cómo los cursos a menudo les dan incentivos para hacerlo.

Lang2016

James M. Lang: Small Teaching: Everyday Lessons from the Science of Learning. Jossey-Bass, 2016, 9781118944493. Presenta una selección de prácticas accesibles basadas en evidencia que los/las docentes pueden adoptar cuando tienen poco tiempo y pocos recursos.

Lazo1993

Ard W. Lazonder and Hans van der Meij: "The Minimal Manual: Is Less Really More?". International Journal of Man-Machine Studies, 39(5), 11 1993, doi:10.1006/imms.1993.1081. Informa que el enfoque manual mínimo para la instrucción supera a los enfoques tradicionales independientemente de la experiencia previa con computadoras.

Leak2017

Mackenzie Leake and Colleen M. Lewis: "Recommendations for Designing CS Resource Sharing Sites for All Teachers". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017780. Explora por qué los/las docentes de informática no utilizan sitios para compartir recursos y recomienda formas de hacer estos sitios más atractivos.

Lee2013

Cynthia Bailey Lee: "Experience Report: CS1 in MATLAB for Non-Majors, with Media Computation and Peer Instruction". In 2013 Technical Symposium on Computer Science Education (SIGCSE'13), 2013, doi:10.1145/2445196.2445214. Describe una adaptación de computación de medios a un curso de MATLAB de primer año.

Lee2017

Cynthia Bailey Lee: "What Can I Do Today to Create a More Inclusive Community in CS?". http://bit.ly/2oynmSH, 2017. Una lista práctica de acciones que los/las docentes pueden hacer para que sus clases de computación sean más inclusivas.

Lemo2014

Doug Lemov: Teach Like a Champion 2.0: 62 Techniques that Put Students on the Path to College. Jossey-Bass, 2014, 1118901851. Presenta 62 técnicas de aula extraídas del estudio intensivo de miles de horas de video de buenos/as docentes en acción.

Lewi2015

Colleen M. Lewis and Niral Shah: "How Equity and Inequity Can Emerge in Pair Programming". In 2015 International Computing Education Research Conference (ICER'15), 2015, doi:10.1145/2787622.2787716. Informa un estudio de programación en parejas en un aula de grado medio en el que las parejas menos equitativas eran las que buscaban completar la tarea rápidamente.

List2004

Raymond Lister, Otto Seppälä, Beth Simon, Lynda Thomas, Elizabeth S. Adams, Sue Fitzgerald, William Fone, John Hamer, Morten Lindholm, Robert McCartney, Jan Erik Moström, and Kate Sanders: "A Multi-National Study of Reading and Tracing Skills in Novice Programmers". In 2004 Conference on Innovation and Technology in Computer Science Education (ITiCSE'04), 2004, doi:10.1145/1044550.1041673. Informa que los/las estudiantes no son tan buenos para predecir el resultado de ejecutar un fragmento corto de código ni para seleccionar la finalización correcta.

List2009

Raymond Lister, Colin Fidge, and Donna Teague: "Further Evidence of a Relationship Between Explaining, Tracing and Writing Skills in Introductory Programming". ACM SIGCSE Bulletin, 41(3), 8 2009, doi:10.1145/1595496.1562930. Replica estudios anteriores que muestran que los/las estudiantes que no pueden revisar el código generalmente no pueden explicarlo y que los/las estudiantes que tienden a desempeñarse razonablemente bien en las tareas de escritura de código también generalmente han adquirido la capacidad tanto de revisar el código como de explicarlo.

Litt2004

Dennis Littky: The Big Picture: Education Is Everyone's Business. Association for Supervision & Curriculum Development (ASCD), 2004, 0871209713. Ensayos sobre el propósito de la educación y cómo mejorar las escuelas.

Luxt2009

Andrew Luxton-Reilly: "A Systematic Review of Tools That Support Peer Assessment". Computer Science Education, 19(4), 12 2009, doi:10.1080/08993400903384844. Relevamiento de herramientas de evaluación entre pares que pueden ser útiles en la educación informática.

Luxt2017

Andrew Luxton-Reilly, Jacqueline Whalley, Brett A. Becker, Yingjun Cao, Roger McDermott, Claudio Mirolo, Andreas Mühling, Andrew Petersen, Kate Sanders, and Simon: "Developing Assessments to Determine Mastery of Programming Fundamentals". In 2017 Conference on Innovation and Technology in Computer Science Education (ITiCSE'17), 2017, doi:10.1145/3174781.3174784. Sintetiza el trabajo de muchos trabajos anteriores que determinan qué enseñan realmente los/las docentes de informática, cómo esas cosas dependen unas de otras y cómo se pueden evaluar.

Macn2014

Brooke N. Macnamara, David Z. Hambrick, and Frederick L. Oswald: "Deliberate Practice and Performance in Music, Games, Sports, Education, and Professions: A Meta-Analysis". Psychological Science, 25(8), 7 2014, doi:10.1177/0956797614535810. Un metaestudio sobre la efectividad de la práctica deliberada.

Magu2018

Phil Maguire, Rebecca Maguire, and Robert Kelly: "Using Automatic Machine Assessment to Teach Computer Programming". Computer Science Education, 2 2018, doi:10.1080/08993408.2018.1435113. Informa que las pruebas semanales evaluadas por máquinas predicen mejor los puntajes de los exámenes que los laboratorios (pero que a los/las estudiantes no les gustó el sistema).

Malo2010

John Maloney, Mitchel Resnick, Natalie Rusk, Brian Silverman, and Evelyn Eastmond: "The Scratch Programming Language and Environment". ACM Transactions on Computing Education, 10(4), 11 2010, doi:10.1145/1868358.1868363. Resume el diseño de la primera generación de Scratch.

Majo2015

Claire Howell Major, Michael S. Harris, and Tod Zakrajsek: Teaching for Learning: 101 Intentionally Designed Educational Activities to Put Students on the Path to Success. Routledge, 2015, 0415699363. Cataloga cien tipos diferentes de ejercicios para hacer con estudiantes.

Mann2015

Mary Lynn Manns and Linda Rising: Fearless Change: Patterns for Introducing New Ideas. Addison-Wesley, 2015, 9780201741575. Un catálogo de patrones para hacer que el cambio ocurra en grandes organizaciones.

Marc2011

Guillaume Marceau, Kathi Fisler, and Shriram Krishnamurthi: "Measuring the Effectiveness of Error Messages Designed for Novice Programmers". In 2011 Technical Symposium on Computer Science Education (SIGCSE'11), 2011, doi:10.1145/1953163.1953308. Examina las respuestas de nivel de edición a los mensajes de error e introduce una rúbrica útil para clasificar las respuestas de los/las usuarios/as a los errores.

Marg2015

Anoush Margaryan, Manuela Bianco, and Allison Littlejohn: "Instructional Quality of Massive Open Online Courses (MOOCs)". Computers & Education, 80, 1 2015, doi:10.1016/j.compedu.2014.08.005. Informa que la calidad del diseño instruccional en los cursos abiertos masivos en línea (MOOCs) es deficiente, pero que la organización y presentación del material es buena.

Marg2003

Jane Margolis and Allan Fisher: Unlocking the Clubhouse: Women in Computing. MIT Press, 2003, 0262632691. Un informe innovador sobre el desequilibrio de género en la informática y los pasos que tomó Carnegie Mellon para abordar el problema.

Marg2010

Jane Margolis, Rachel Estrella, Joanna Goode, Jennifer Jellison Holme, and Kim Nao: Stuck in the Shallow End: Education, Race, and Computing. MIT Press, 2010, 0262514044. Analiza las estructuras escolares y los sistemas de creencias que conducen a una subrepresentación de estudiantes afroamericanos/as y latinos/as en informática.

Marg2012

Lauren E. Margulieux, Mark Guzdial, and Richard Catrambone: "Subgoal-labeled Instructional Material Improves Performance and Transfer in Learning to Develop Mobile Applications". In 2012 International Computing Education Research Conference (ICER'12), 2012, doi:10.1145/2361276.2361291. Reporta que los sub\-objetivos con etiquetas mejoran los resultados y la transferencia al aprender sobre el desarrollo de aplicaciones móviles.

Marg2016

Lauren E. Margulieux, Richard Catrambone, and Mark Guzdial: "Employing Subgoals in Computer Programming Education". Computer Science Education, 26(1), 1 2016, doi:10.1080/08993408.2016.1144429. Reporta que los sub\-objetivos etiquetados mejoran los resultados del aprendizaje en los cursos de introducción a la informática.

Mark2018

Rebecca A. Markovits and Yana Weinstein: "Can Cognitive Processes Help Explain the Success of Instructional Techniques Recommended by Behavior Analysts?". NPJ Science of Learning, 3(1), 1 2018, doi:10.1038/s41539-017-0018-1. Señala que los/as conductistas y los/as psicólogos/as cognitivos difieren en el enfoque, pero terminan haciendo recomendaciones muy similares sobre cómo enseñar, y da dos ejemplos específicos.

Mars2002

Herbert W. Marsh and John Hattie: "The Relation Between Research Productivity and Teaching Effectiveness: Complementary, Antagonistic, or Independent Constructs?". Journal of Higher Education, 73(5), 2002, doi:10.1353/jhe.2002.0047. Uno de muchos estudios que muestra que no hay correlación entre la capacidad de investigación y la eficacia en la enseñanza.

Masa2018

Susana Masapanta-Carrión and J. Ángel Velázquez-Iturbide: "A Systematic Review of the Use of Bloom's Taxonomy in Computer Science Education". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159491. Informa que incluso docentes experimentados/as tienen problemas para ponerse de acuerdo sobre la clasificación correcta para una pregunta o idea utilizando la taxonomía de Bloom.

Maso2016

Raina Mason, Carolyn Seton, and Graham Cooper: "Applying Cognitive Load Theory to the Redesign of a Conventional Database Systems Course". Computer Science Education, 26(1), 1 2016, doi:10.1080/08993408.2016.1160597. Informa cómo el rediseño de un curso de base de datos utilizando la teoría de la carga cognitiva redujo la tasa de desaprobación y al mismo tiempo aumentó la satisfacción de los/las estudiantes.

Matt2019

Eric Matthes: Python Flash Cards: Syntax, Concepts, and Examples. No Starch Press, 2019, 978-1593278960. Prácticas tarjetas didácticas que resumen lo principal de Python 3.

Maye2003

Richard E. Mayer and Roxana Moreno: "Nine Ways to Reduce Cognitive Load in Multimedia Learning". Educational Psychologist, 38(1), 3 2003, doi:10.1207/s15326985ep3801_6. Muestra cómo la investigación sobre cómo absorbemos y procesamos la información se puede aplicar al diseño de materiales de enseñanza.

Maye2004

Richard E. Mayer: "Teaching of Subject Matter". Annual Review of Psychology, 55(1), 2 2004, doi:10.1146/annurev.psych.55.082602.133124. Una descripción general de cómo y por qué la enseñanza y el aprendizaje son específicos de una asignatura.

Maye2009

Richard E. Mayer: Multimedia Learning. Cambridge University Press, 2009, 9780521735353. Presenta una teoría cognitiva del aprendizaje multimedia.

Mazu1996

Eric Mazur: Peer Instruction: A User's Manual. Prentice-Hall, 1996. Una guía para implementar la instrucción entre pares.

McCa2008

Renée McCauley, Sue Fitzgerald, Gary Lewandowski, Laurie Murphy, Beth Simon, Lynda Thomas, and Carol Zander: "Debugging: A Review of the Literature from an Educational Perspective". Computer Science Education, 18(2), 6 2008, doi:10.1080/08993400802114581. Resume la investigación sobre por qué ocurren los errores, qué tipos de errores hay, cómo las personas depuran código y si podemos enseñar habilidades de depuración.

McCr2001

Michael McCracken, Tadeusz Wilusz, Vicki Almstrum, Danny Diaz, Mark Guzdial, Dianne Hagan, Yifat Ben-David Kolikant, Cary Laxer, Lynda Thomas, and Ian Utting: "A Multi-National, Multi-Institutional Study of Assessment of Programming Skills of First-Year CS Students". In 2001 Conference on Innovation and Technology in Computer Science Education (ITiCSE'01), 2001, doi:10.1145/572133.572137. Informa que la mayoría de los/las estudiantes todavía tienen dificultades para resolver incluso los problemas básicos de programación al final de su curso introductorio.

McDo2006

Charlie McDowell, Linda Werner, Heather E. Bullock, and Julian Fernald: "Pair Programming Improves Student Retention, Confidence, and Program Quality". Communications of the ACM, 49(8), 8 2006, doi:10.1145/1145287.1145293. Un resumen de la investigación que muestra que la programación en parejas mejora la retención y la confianza.

McGu2015

Saundra Yancey McGuire: Teach Students How to Learn: Strategies You Can Incorporate Into Any Course to Improve Student Metacognition, Study Skills, and Motivation. Stylus Publishing, 2015, 162036316X. Explica cómo las estrategias metacognitivas pueden mejorar el aprendizaje.

McMi2017

Tressie McMillan Cottom: Lower Ed: The Troubling Rise of For-Profit Colleges in the New Economy. The New Press, 2017, 1620970600. Pone al descubierto la dinámica de la creciente industria de la educación para mostrar cómo conduce a una mayor desigualdad en lugar de a una menor.

McTi2013

Jay McTighe and Grant Wiggins: "Understanding by Design Framework". http://www.ascd.org/ASCD/pdf/siteASCD/publications/UbD_WhitePaper0312.pdf, 2013. Resume el proceso de diseño instruccional de atrás hacia adelante.

Metc2016

Janet Metcalfe: "Learning from Errors". Annual Review of Psychology, 68(1), 1 2016, doi:10.1146/annurev-psych-010416-044022. Resume el trabajo sobre el efecto de hipercorrección en el aprendizaje.

Meys2018

Mark Meysenburg, Tessa Durham Brooks, Raychelle Burks, Erin Doyle, and Timothy Frey: "DIVAS: Outreach to the Natural Sciences Through Image Processing". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159537. Describe los primeros resultados de un curso de programación para estudiantes de ciencias basado en el procesamiento de imágenes.

Midw2010

Midwest Academy: Organizing for Social Change: Midwest Academy Manual for Activists. The Forum Press, 2010, 0984275215. Un manual de formación para personas que construyen movimientos sociales progresistas.

Mill1956

George A. Miller: "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information". Psychological Review, 63(2), 1956, doi:10.1037/h0043158. El documento original sobre el tamaño limitado de la memoria a corto plazo.

Mill2013

Kelly Miller, Nathaniel Lasry, Kelvin Chu, and Eric Mazur: "Role of Physics Lecture Demonstrations in Conceptual Learning". Physical Review Special Topics - Physics Education Research, 9(2), 9 2013, doi:10.1103/physrevstper.9.020113. Informa un estudio detallado de lo que los/las estudiantes aprenden durante las demostraciones y por qué.

Mill2015

David I. Miller and Jonathan Wai: "The Bachelor's to Ph.D. STEM Pipeline No Longer Leaks More Women Than Men: a 30-year Analysis". Frontiers in Psychology, 6, 2 2015, doi:10.3389/fpsyg.2015.00037. Muestra que la metáfora de la ``tubería con fugas'' dejó de ser precisa en algún momento de la década de 1990.

Mill2016a

Michelle D. Miller: Minds Online: Teaching Effectively with Technology. Harvard University Press, 2016, 0674660021. Describe las formas en que los conocimientos de la neurociencia se pueden utilizar para mejorar la enseñanza en línea.

Mill2016b

Craig S. Miller and Amber Settle: "Some Trouble with Transparency: An Analysis of Student Errors with Object-Oriented Python". In 2016 International Computing Education Research Conference (ICER'16), 2016, doi:10.1145/2960310.2960327. Informa que los/las estudiantes tienen dificultades con self en Python.

Milt2018

Kate M. Miltner: "Girls Who Coded: Gender in Twentieth Century U.K. and U.S. Computing". Science, Technology, & Human Values, 5 2018, doi:10.1177/0162243918770287. Una revisión de tres libros sobre cómo las mujeres fueron expulsadas sistemáticamente de la informática.

Mina1986

Anne Minahan: "Martha's Rules". Affilia, 1(2), 6 1986, doi:10.1177/088610998600100206. Describe un conjunto ligero de reglas para la toma de decisiones basada en consenso.

Miya2018

Toshiya Miyatsu, Khuyen Nguyen, and Mark A. McDaniel: "Five Popular Study Strategies: Their Pitfalls and Optimal Implementations". Perspectives on Psychological Science, 13(3), 5 2018, doi:10.1177/1745691617710510. Explica cómo los/las estudiantes hacen un mal uso de las estrategias de estudio comunes y qué deberían hacer en su lugar.

Mlad2017

Monika Mladenović, Ivica Boljat, and Žana Žanko: "Comparing Loops Misconceptions in Block-Based and Text-Based Programming Languages at the K-12 Level". Education and Information Technologies, 11 2017, doi:10.1007/s10639-017-9673-3. Informa que los/las estudiantes de K-12 tienen menos conceptos erróneos sobre los bucles con Scratch que con Logo o Python, y menos conceptos erróneos sobre los bucles anidados con Logo que con Python.

More2019

Kayla Morehead, John Dunlosky, and Katherine A. Rawson: "How Much Mightier Is the Pen than the Keyboard for Note-Taking? A Replication and Extension of Mueller and Oppenheimer (2014)". Educational Psychology Review, 2 2019, doi:10.1007/s10648-019-09468-2. Informa que no se pudo reproducir un estudio anterior que comparaba la toma de notas a mano y con computadoras.

Morr2016

Briana B. Morrison, Lauren E. Margulieux, Barbara J. Ericson, and Mark Guzdial: "Subgoals Help Students Solve Parsons Problems". In 2016 Technical Symposium on Computer Science Education (SIGCSE'16), 2016, doi:10.1145/2839509.2844617. Informa que los/las estudiantes que usan sub\-objetivos etiquetados resuelven los problemas de Parsons mejor que los estudiantes sin sub\-objetivos etiquetados.

Muel2014

Pam A. Mueller and Daniel M. Oppenheimer: "The Pen is Mightier than the Keyboard". Psychological Science, 25(6), 4 2014, doi:10.1177/0956797614524581. Presenta evidencia de que tomar notas a mano es más efectivo que tomar notas en una computadora portátil.

Mull2007a

Derek A. Muller, James Bewes, Manjula D. Sharma, and Peter Reimann: "Saying the Wrong Thing: Improving Learning with Multimedia by Including Misconceptions". Journal of Computer Assisted Learning, 24(2), 7 2007, doi:10.1111/j.1365-2729.2007.00248.x. Informa que incluir una discusión explícita sobre conceptos erróneos mejora significativamente los resultados del aprendizaje: los/las estudiantes con pocos conocimientos previos son quienes más se benefician y los/las estudiantes con más conocimientos previos no están en desventaja.

Mull2007b

Orna Muller, David Ginat, and Bruria Haberman: "Pattern-Oriented Instruction and Its Influence on Problem Decomposition and Solution Construction". In 2007 Technical Symposium on Computer Science Education (SIGCSE'07), 2007, doi:10.1145/1268784.1268830. Informa que la enseñanza explícita de patrones de solución mejora los resultados del aprendizaje.

Murp2008

Laurie Murphy, Gary Lewandowski, Renée McCauley, Beth Simon, Lynda Thomas, and Carol Zander: "Debugging: The Good, the Bad, and the Quirky - A Qualitative Analysis of Novices' Strategies". ACM SIGCSE Bulletin, 40(1), 2 2008, doi:10.1145/1352322.1352191. Informa que muchos/as estudiantes de CS1 usan buenas estrategias de depuración, pero muchos/as otros/as no lo hacen, y los/las estudiantes a menudo no reconocen cuando están atascados/as.

Nara2018

Sathya Narayanan, Kathryn Cunningham, Sonia Arteaga, William J. Welch, Leslie Maxwell, Zechariah Chawinga, and Bude Su: "Upward Mobility for Underrepresented Students". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159551. Describe un programa de licenciatura intensivo de tres años basado en cohortes muy unidas y apoyo administrativo que triplicó las tasas de graduación.

Nath2003

Mitchell J. Nathan and Anthony Petrosino: "Expert Blind Spot Among Preservice Teachers". American Educational Research Journal, 40(4), 1 2003, doi:10.3102/00028312040004905. Trabajo inicial sobre punto ciego del experto/a.

Hpl2018

National Academies of Sciences, Engineering, and Medicine: How People Learn II: Learners, Contexts, and Cultures. National Academies Press, 2018, 978-0309459648. Un relevamiento completo de lo que sabemos sobre el aprendizaje.

Nils2017

Linda B. Nilson and Ludwika A. Goodson: Online Teaching at Its Best: Merging Instructional Design with Teaching and Learning Research. Jossey-Bass, 2017, 1119242290. Una guía para instructores/as universitarios/as que se centra en la enseñanza en línea.

Nord2017

Emily Nordmann, Colin Calder, Paul Bishop, Amy Irwin, and Darren Comber: "Turn Up, Tune In, Don'T Drop Out: The Relationship Between Lecture Attendance, Use of Lecture Recordings, and Achievement at Different Levels of Study". https://psyarxiv.com/fd3yj, 2017, doi:10.17605/OSF.IO/FD3YJ. Informa sobre los pros y contras de grabar conferencias.

Nutb2016

Stephen Nutbrown and Colin Higgins: "Static Analysis of Programming Exercises: Fairness, Usefulness and a Method for Application". Computer Science Education, 26(2-3), 5 2016, doi:10.1080/08993408.2016.1179865. Describe las formas en que se modificaron las reglas de autoevaluación y se ponderaron las calificaciones para mejorar la correlación entre la retroalimentación automática y las calificaciones manuales.

Nuth2007

Graham Nuthall: The Hidden Lives of Learners. NZCER Press, 2007, 1877398241. Resume toda una vida de trabajo observando lo que los/las estudiantes hacen realmente en las aulas y cómo aprenden realmente.

Ojos2015

Bobby Ojose: Common Misconceptions in Mathematics: Strategies to Correct Them. UPA, 2015, 0761858857. Un catálogo de conceptos erróneos de K-12 en matemáticas y qué hacer al respecto.

Ornd2015

Harold N. Orndorff III: "Collaborative Note-Taking: The Impact of Cloud Computing on Classroom Performance". International Journal of Teaching and Learning in Higher Education, 27(3), 2015. Informa que tomar notas de forma colaborativa en línea es más efectivo que tomar notas de forma individual.

Ostr2015

Elinor Ostrom: Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge University Press, 2015, 978-1107569782. Una descripción y un análisis magistrales de la gobernanza cooperativa.

Pape1993

Seymour A. Papert: Mindstorms: Children, Computers, and Powerful Ideas. Basic Books, 1993, 0465046746. El texto fundacional sobre cómo las computadoras pueden respaldar un nuevo tipo de educación.

Pare2008

Dwayne E. Paré and Steve Joordens: "Peering Into Large Lectures: Examining Peer and Expert Mark Agreement Using peerScholar, an Online Peer Assessment Tool". Journal of Computer Assisted Learning, 24(6), 10 2008, doi:10.1111/j.1365-2729.2008.00290.x. Muestra que la calificación entre pares por grupos pequeños puede ser tan efectiva como la calificación de expertos una vez que se introducen las funciones de responsabilidad.

Park2015

Thomas H. Park, Brian Dorn, and Andrea Forte: "An Analysis of HTML and CSS Syntax Errors in a Web Development Course". ACM Transactions on Computing Education, 15(1), 3 2015, doi:10.1145/2700514. Describe los errores que cometen los/las estudiantes en un curso de introducción a HTML y CSS.

Park2016

Miranda C. Parker, Mark Guzdial, and Shelly Engleman: "Replication, Validation, and Use of a Language Independent CS1 Knowledge Assessment". In 2016 International Computing Education Research Conference (ICER'16), 2016, doi:10.1145/2960310.2960316. Describe la construcción y replicación de un segundo inventario de conceptos para conocimientos básicos de computación.

Parn1986

David Lorge Parnas and Paul C. Clements: "A Rational Design Process: How and Why to Fake It". IEEE Transactions on Software Engineering, SE-12(2), 2 1986, doi:10.1109/tse.1986.6312940. Sostiene que usar un proceso de diseño racional es menos importante que lucir como si lo hubiera hecho.

Parn2017

Chris Parnin, Janet Siegmund, and Norman Peitek: "On the Nature of Programmer Expertise". In Psychology of Programming Interest Group Workshop 2017, 2017. Una exploración comentada de lo que significa ``experiencia'' en programación.

Pars2006

Dale Parsons and Patricia Haden: "Parson's Programming Puzzles: A Fun and Effective Learning Tool for First Programming Courses". In 2006 Australasian Conference on Computing Education (ACE'06), 2006. La primera descripción de los problemas de Parson.

Part2011

Anu Partanen: "What Americans Keep Ignoring About Finland's School Success". https://www.theatlantic.com/national/archive/2011/12/what-americans-keep-ignoring-about-finlands-school-success/250564/, 2011. Explica que otros países no pueden replicar el éxito de las escuelas de Finlandia porque no están dispuestos a abordar factores sociales más importantes.

Pati2016

Elizabeth Patitsas, Jesse Berlin, Michelle Craig, and Steve Easterbrook: "Evidence that Computer Science Grades are not Bimodal". In 2016 International Computing Education Research Conference (ICER'16), 2016, doi:10.1145/2960310.2960312. Presenta un análisis estadístico y un experimento que en conjunto muestran que las notas en las clases de informática no son bimodales.

Pea1986

Roy D. Pea: "Language-Independent Conceptual ``Bugs'' in Novice Programming". Journal of Educational Computing Research, 2(1), 2 1986, doi:10.2190/689t-1r2a-x4w4-29j2. Llamado el ``super error'' en la programación: la mayoría de los/las principiantes piensan que la computadora entiende lo que quieren hacer, de la misma manera que lo haría un ser humano.

Petr2016

Marian Petre and André van der Hoek: Software Design Decoded: 66 Ways Experts Think. MIT Press, 2016, 0262035189. Una breve descripción ilustrada de cómo piensan los/las expertos/as en desarrollo de software.

Pign2016

Alessandra Pigni: The Idealist's Survival Kit: 75 Simple Ways to Prevent Burnout. Parallax Press, 2016, 1941529348. Una guía para mantenerse cuerdo/a y saludable mientras haces el bien.

Port2013

Leo Porter, Mark Guzdial, Charlie McDowell, and Beth Simon: "Success in Introductory Programming: What Works?". Communications of the ACM, 56(8), 8 2013, doi:10.1145/2492007.2492020. Resume la evidencia que muestra que la instrucción entre pares, la computación de medios y la programación en parejas pueden mejorar significativamente los resultados en los cursos de introducción a la programación.

Port2016

Leo Porter, Dennis Bouvier, Quintin Cutts, Scott Grissom, Cynthia Bailey Lee, Robert McCartney, Daniel Zingaro, and Beth Simon: "A Multi-Institutional Study of Peer Instruction in Introductory Computing". In 2016 Technical Symposium on Computer Science Education (SIGCSE'16), 2016, doi:10.1145/2839509.2844642. Informa que los/las estudiantes de las clases de introducción a la programación valoran la instrucción entre compañeros/as y que mejora los resultados del aprendizaje.

Qian2017

Yizhou Qian and James Lehman: "Students' Misconceptions and Other Difficulties in Introductory Programming". ACM Transactions on Computing Education, 18(1), 10 2017, doi:10.1145/3077618. Resume la investigación sobre los conceptos erróneos de los/las estudiantes sobre la informática.

Rago2017

Noa Ragonis and Ronit Shmallo: "On the (Mis)understanding of the this Reference". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017715. Informa que la mayoría de los/las estudiantes no entienden cuándo usar this, y que los/las docentes tampoco suelen ser claros/as sobre el tema.

Raj2018

Adalbert Gerald Soosai Raj, Jignesh M. Patel, Richard Halverson, and Erica Rosenfeld Halverson: "Role of Live-Coding in Learning Introductory Programming". In 2018 Koli Calling International Conference on Computing Education Research (Koli'18), 2018, doi:10.1145/3279720.3279725. Un análisis teórico fundamentado de la programación en vivo que incluye referencias a trabajos anteriores.

Rams2019

G. Ramsay, A. B. Haynes, S. R. Lipsitz, I. Solsky, J. Leitch, A. A. Gawande, and M. Kumar: "Reducing surgical mortality in Scotland by use of the WHO Surgical Safety Checklist". BJS, 4 2019, doi:10.1002/bjs.11151. Descubrió que la introducción de listas de verificación quirúrgica en los hospitales escoceses redujo significativamente las tasas de mortalidad.

Raws2014

Katherine A. Rawson, Ruthann C. Thomas, and Larry L. Jacoby: "The Power of Examples: Illustrative Examples Enhance Conceptual Learning of Declarative Concepts". Educational Psychology Review, 27(3), 6 2014, doi:10.1007/s10648-014-9273-3. Informa que la presentación de ejemplos ayuda a los/las estudiantes a comprender las definiciones, siempre que los ejemplos y las definiciones estén intercalados.

Ray2014

Eric J. Ray and Deborah S. Ray: Unix and Linux: Visual QuickStart Guide. Peachpit Press, 2014, 0321997549. Una introducción a Unix que es tanto un buen tutorial como una buena guía de referencia.

Rice2018

Gail Taylor Rice: Hitting Pause: 65 Lecture Breaks to Refresh and Reinforce Learning. Stylus Publishing, 2018, 9781620366530. Justifica y cataloga formas de hacer una pausa en clase para ayudar al aprendizaje.

Rich2017

Kathryn M. Rich, Carla Strickland, T. Andrew Binkowski, Cheryl Moran, and Diana Franklin: "K-8 learning Trajectories Derived from Research Literature". In 2017 International Computing Education Research Conference (ICER'17), 2017, doi:10.1145/3105726.3106166. Presenta trayectorias de aprendizaje para las clases de computación K-8 para secuencia, repetición y condiciones extraídas de la literatura.

Ritz2018

Anna Ritz: "Programming the Central Dogma: An Integrated Unit on Computer Science and Molecular Biology Concepts". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159590. Describe un curso de introducción a la computación para biólogos/as cuyos problemas se extraen de los procesos de ADN a proteína en las células.

Robe2017

Eric Roberts: "Assessing and Responding to the Growth of Computer Science Undergraduate Enrollments: Annotated Findings". http://cs.stanford.edu/people/eroberts/ResourcesForTheCSCapacityCrisis/files/AnnotatedFindings.pptx, 2017. Resume los hallazgos de un estudio de las Academias Nacionales sobre las inscripciones en informática.

Robi2005

Evan Robinson: "Why Crunch Mode Doesn't Work: 6 Lessons". http://www.igda.org/articles/erobinson_crunch.php, 2005. Resume la investigación sobre los efectos del exceso de trabajo y la falta de sueño.

Roge2018

Steven G. Rogelberg: The Surprising Science of Meetings. Oxford University Press, 2018, 978-0190689216. Un breve resumen de la investigación sobre reuniones efectivas.

Rohr2015

Doug Rohrer, Robert F. Dedrick, and Sandra Stershic: "Interleaved Practice Improves Mathematics Learning". Journal of Educational Psychology, 107(3), 2015, doi:10.1037/edu0000001. Informa que la práctica intercalada es más eficaz que la práctica monótona durante el aprendizaje.

Rubi2013

Marc J. Rubin: "The Effectiveness of Live-coding to Teach Introductory Programming". In 2013 Technical Symposium on Computer Science Education (SIGCSE'13), 2013, doi:10.1145/2445196.2445388. Reporta que la programación en vivo es tan buena o mejor que usar ejemplos de código estático.

Rubi2014

Manuel Rubio-Sánchez, Päivi Kinnunen, Cristóbal Pareja-Flores, and J. Ángel Velázquez-Iturbide: "Student Perception and Usage of an Automated Programming Assessment Tool". Computers in Human Behavior, 31, 2 2014, doi:10.1016/j.chb.2013.04.001. Describe el uso de autoevaluación para las tareas de los/las estudiantes.

Sahl2015

Pasi Sahlberg: Finnish Lessons 2.0: What Can the World Learn from Educational Change in Finland?. Teachers College Press, 2015, 978-0807755853. Una mirada franca al éxito del sistema educativo de Finlandia y por qué otros países no pueden replicarlo.

Saja2006

Jorma Sajaniemi, Mordechai Ben-Ari, Pauli Byckling, Petri Gerdt, and Yevgeniya Kulikova: "Roles of Variables in Three Programming Paradigms". Computer Science Education, 16(4), 12 2006, doi:10.1080/08993400600874584. Una mirada detallada al trabajo de los autores sobre los roles de las variables.

Sala2017

Giovanni Sala and Fernand Gobet: "Does Far Transfer Exist? Negative Evidence From Chess, Music, and Working Memory Training". Current Directions in Psychological Science, 26(6), 10 2017, doi:10.1177/0963721417712760. Un metaanálisis que muestra que la transferencia lejana rara vez ocurre.

Sand2013

Kate Sanders, Jaime Spacco, Marzieh Ahmadzadeh, Tony Clear, Stephen H. Edwards, Mikey Goldweber, Chris Johnson, Raymond Lister, Robert McCartney, and Elizabeth Patitsas: "The Canterbury QuestionBank: Building a Repository of Multiple-Choice CS1 and CS2 Questions". In 2013 Conference on Innovation and Technology in Computer Science Education (ITiCSE'13), 2013, doi:10.1145/2543882.2543885. Describe el desarrollo de un banco de preguntas compartido para la introducción a la informática y patrones para las preguntas de opción múltiple que surgieron de las entradas.

Scan1989

David A. Scanlan: "Structured Flowcharts Outperform Pseudocode: An Experimental Comparison". IEEE Software, 6(5), 9 1989, doi:10.1109/52.35587. Informa que los/las estudiantes comprenden los diagramas de flujo mejor que el pseudocódigo si ambos están igualmente bien estructurados.

Scho1984

Donald A. Schön: The Reflective Practitioner: How Professionals Think In Action. Basic Books, 1984, 0465068782. Una mirada innovadora a cómo profesionales en diferentes campos realmente resuelven problemas.

Schw2013

Viviane Schwarz: Welcome to Your Awesome Robot. Flying Eye Books, 2013, 978-1909263000. Una maravillosa guía ilustrada para construir trajes de robot de cartón portátiles. No solo para niños/as.

Scot1987

James C. Scott: Weapons of the Weak: Everyday Forms of Peasant Resistance. Yale University Press, 1987, 978-0300036411. Describe las técnicas de evasión y resistencia que utilizan las personas débiles para resistir a las personas fuertes.

Scot1998

James C. Scott: Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed. Yale University Press, 1998, 0300078153. Sostiene que las grandes organizaciones siempre prefieren la uniformidad a la productividad.

Sent2018

Sue Sentance, Erik Barendsen, and Carsten Schulte (eds.): Computer Science Education: Perspectives on Teaching and Learning in School. Bloomsbury Press, 2018, 135005710X. Una colección de artículos de relevamientos académicos sobre la enseñanza de la informática.

Sent2019

Sue Sentance, Jane Waite, and Maria Kallia: "Teachers' Experiences of using PRIMM to Teach Programming in School". In 2019 Technical Symposium on Computer Science Education (SIGCSE'19), 2019, doi:10.1145/3287324.3287477. Describe el patrón de lecciones PRIMM y su efectividad.

Sepp2015

Otto Seppälä, Petri Ihantola, Essi Isohanni, Juha Sorva, and Arto Vihavainen: "Do We Know How Difficult the Rainfall Problem Is?". In 2015 Koli Calling Conference on Computing Education Research (Koli'15), 2015, doi:10.1145/2828959.2828963. Un metaestudio del problema de la lluvia.

Shap2007

Jenessa R. Shapiro and Steven L. Neuberg: "From Stereotype Threat to Stereotype Threats: Implications of a Multi-Threat Framework for Causes, Moderators, Mediators, Consequences, and Interventions". Personality and Social Psychology Review, 11(2), 5 2007, doi:10.1177/1088868306294790. Explora las formas en que se ha utilizado el término ``amenaza estereotipada''.

Shel2017

Duane F. Shell, Leen-Kiat Soh, Abraham E. Flanigan, Markeya S. Peteranetz, and Elizabeth Ingraham: "Improving Students' Learning and Achievement in CS Classrooms Through Computational Creativity Exercises that Integrate Computational and Creative Thinking". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017718. Informa que hacer que los/las estudiantes trabajen en grupos pequeños en ejercicios de creatividad computacional mejora los resultados del aprendizaje.

Shol2019

Dan Sholler, Igor Steinmacher, Denae Ford, Mara Averick, Mike Hoye, and Greg Wilson: "Ten Simple Rules for Helping Newcomers Become Contributors to Open Source Projects". https://github.com/gvwilson/10-newcomers/, 2019. Prácticas basadas en evidencia para ayudar a las personas recién llegadas a ser productivas en proyectos abiertos.

Simo2013

Simon: "Soloway's Rainfall Problem has Become Harder". In 2013 Conference on Learning and Teaching in Computing and Engineering, 3 2013, doi:10.1109/latice.2013.44. Sostiene que el problema de la lluvia es más difícil para las personas principiantes de lo que solía ser porque no están acostumbrados a manejar el teclado, por lo que la comparación directa con los resultados anteriores puede ser injusta.

Sing2012

Vandana Singh: "Newcomer integration and learning in technical support communities for open source software". In 2012 ACM International Conference on Supporting Group Work - GROUP'12, 2012, doi:10.1145/2389176.2389186. Un estudio inicial sobre incorporación de personas a proyectos de código abierto.

Sirk2012

Teemu Sirkiä and Juha Sorva: "Exploring Programming Misconceptions: An Analysis of Student Mistakes in Visual Program Simulation Exercises". In 2012 Koli Calling Conference on Computing Education Research (Koli'12), 2012, doi:10.1145/2401796.2401799. Analiza los datos del uso de una herramienta de visualización de ejecución por parte de los/las estudiantes y clasifica los errores comunes.

Sisk2018

Victoria F. Sisk, Alexander P. Burgoyne, Jingze Sun, Jennifer L. Butler, and Brooke N. Macnamara: "To What Extent and Under Which Circumstances Are Growth Mind-Sets Important to Academic Achievement? Two Meta-Analyses". Psychological Science, 3 2018, doi:10.1177/0956797617739704. Reporta metanálisis de la relación entre la mentalidad y el rendimiento académico, y la efectividad de las intervenciones de la mentalidad en el rendimiento académico, y encuentra que los efectos generales son débiles para ambos, pero algunos resultados apoyan principios específicos de la teoría.

Skud2014

Ben Skudder and Andrew Luxton-Reilly: "Worked Examples in Computer Science". In 2014 Australasian Computing Education Conference, (ACE'14), 2014. Un resumen de la investigación sobre ejemplos prácticos aplicados a la educación informática.

Smar2018

Benjamin L. Smarr and Aaron E. Schirmer: "3.4 Million Real-World Learning Management System Logins Reveal the Majority of Students Experience Social Jet Lag Correlated with Decreased Performance". Scientific Reports, 8(1), 3 2018, doi:10.1038/s41598-018-23044-8. Reporta que a los/las estudiantes que tienen que trabajar fuera de su ciclo natural de reloj biológico les va peor.

Smit2009

Michelle K. Smith, William B. Wood, Wendy K. Adams, Carl E. Wieman, Jennifer K. Knight, N. Guild, and T. T. Su: "Why Peer Discussion Improves Student Performance on In-class Concept Questions". Science, 323(5910), 1 2009, doi:10.1126/science.1165919. Informa que la comprensión de los/las estudiantes aumenta durante la discusión en la instrucción entre compañeros/as, incluso cuando ninguno de los/las estudiantes del grupo sabe inicialmente la respuesta correcta.

Solo1984

Elliot Soloway and Kate Ehrlich: "Empirical Studies of Programming Knowledge". IEEE Transactions on Software Engineering, SE-10(5), 9 1984, doi:10.1109/tse.1984.5010283. Propone que las personas expertas tengan planes de programación y reglas de discurso de programación.

Solo1986

Elliot Soloway: "Learning to Program = Learning to Construct Mechanisms and Explanations". Communications of the ACM, 29(9), 9 1986, doi:10.1145/6592.6594. Analiza la programación en términos de elegir metas apropiadas y construir planes para lograrlas, e introduce el problema de la lluvia.

Sond2012

Harald Søndergaard and Raoul A. Mulder: "Collaborative Learning Through Formative Peer Review: Pedagogy, Programs and Potential". Computer Science Education, 22(4), 12 2012, doi:10.1080/08993408.2012.728041. Examina la literatura sobre la evaluación entre pares, distingue la calificación y la revisión como formas separadas, y resume las características que un buen sistema de revisión entre pares debe tener.

Sorv2013

Juha Sorva: "Notional Machines and Introductory Programming Education". ACM Transactions on Computing Education, 13(2), 6 2013, doi:10.1145/2483710.2483713. Revisa la literatura sobre conceptos erróneos de programación y sostiene que los/las instructores/as deberían abordar las máquinas teóricas como un objetivo de aprendizaje explícito.

Sorv2014

Juha Sorva and Otto Seppälä: "Research-based Design of the First Weeks of CS1". In 2014 Koli Calling Conference on Computing Education Research (Koli'14), 2014, doi:10.1145/2674683.2674690. Propone tres marcos cognitivamente plausibles para el diseño de un primer curso de informática.

Sorv2018

Juha Sorva: "Misconceptions and the Beginner Programmer". In Computer Science Education: Perspectives on Teaching and Learning in School, Bloomsbury Press, 2018. Resume lo que sabemos sobre lo que las personas novatas entienden mal sobre la informática.

Spal2014

Dan Spalding: How to Teach Adults: Plan Your Class, Teach Your Students, Change the World. Jossey-Bass, 2014, 1118841360. Una breve guía para enseñar a personas adultas que son estudiantes free-range informada por el activismo social del autor.

Spoh1985

James C. Spohrer, Elliot Soloway, and Edgar Pope: "A Goal/Plan Analysis of Buggy Pascal Programs". Human-Computer Interaction, 1(2), 6 1985, doi:10.1207/s15327051hci0102_4. Uno de los primeros análisis cognitivamente plausibles de cómo las personas programan, que propone un modelo de meta/plan.

Srid2016

Sumukh Sridhara, Brian Hou, Jeffrey Lu, and John DeNero: "Fuzz Testing Projects in Massive Courses". In 2016 Conference on Learning @ Scale (L@S'16), 2016, doi:10.1145/2876034.2876050. Informa que el código de los/las estudiantes de pruebas fuzz detecta errores que se pasan por alto en el conjunto de pruebas escritas a mano y explica cómo compartir pruebas y resultados de forma segura.

Stam2013

Eliane Stampfer and Kenneth R. Koedinger: "When Seeing Isn't Believing: Influences of Prior Conceptions and Misconceptions". In 2013 Annual Meeting of the Cognitive Science Society (CogSci'13), 2013. Explora por qué dar más información a los/las niños/as cuando están aprendiendo sobre fracciones puede reducir su rendimiento.

Stam2014

Eliane Stampfer Wiese and Kenneth R. Koedinger: "Investigating Scaffolds for Sense Making in Fraction Addition and Comparison". In 2014 Annual Conference of the Cognitive Science Society (CogSci'14), 2014. Analiza cómo estructurar el aprendizaje de fracciones.

Star2014

Philip Stark and Richard Freishtat: "An Evaluation of Course Evaluations". ScienceOpen Research, 9 2014, doi:10.14293/s2199-1006.1.sor-edu.aofrqa.v1. Otra demostración más de que las evaluaciones de la enseñanza no se correlacionan con los resultados del aprendizaje y que con frecuencia son estadísticamente sospechosas.

Stas1998

John Stasko, John Domingue, Mark H. Brown, and Blaine A. Price (eds.): Software Visualization: Programming as a Multimedia Experience. MIT Press, 1998, 0262193957. Un estudio de las técnicas y los resultados de visualización de programas y algoritmos.

Stee2011

Claude M. Steele: Whistling Vivaldi: How Stereotypes Affect Us and What We Can Do. W. W. Norton & Company, 2011, 0393339726. Explica y explora las amenazas estereotipadas y las estrategias para abordarlas.

Stef2013

Andreas Stefik and Susanna Siebert: "An Empirical Investigation into Programming Language Syntax". ACM Transactions on Computing Education, 13(4), 11 2013, doi:10.1145/2534973. Informa que los lenguajes con llaves son tan difíciles de aprender como un lenguaje con sintaxis diseñada al azar, pero otros son más fáciles.

Stef2017

Andreas Stefik, Patrick Daleiden, Diana Franklin, Stefan Hanenberg, Antti-Juhani Kaijanaho, Walter Tichy, and Brett A. Becker: "Programming Languages and Learning". https://quorumlanguage.com/evidence.html, 2017. Resume lo que realmente sabemos sobre el diseño de lenguajes de programación y por qué creemos que es cierto.

Steg2014

Martijn Stegeman, Erik Barendsen, and Sjaak Smetsers: "Towards an Empirically Validated Model for Assessment of Code Quality". In 2014 Koli Calling Conference on Computing Education Research (Koli'14), 2014, doi:10.1145/2674683.2674702. Presenta una rúbrica de calidad de código para cursos de programación para principiantes.

Steg2016a

Martijn Stegeman, Erik Barendsen, and Sjaak Smetsers: "Designing a Rubric for Feedback on Code Quality in Programming Courses". In 2016 Koli Calling Conference on Computing Education Research (Koli'16), 2016, doi:10.1145/2999541.2999555. Describe varias iteraciones de una rúbrica de calidad de código para cursos de programación para principiantes.

Steg2016b

Martijn Stegeman, Erik Barendsen, and Sjaak Smetsers: "Rubric for Feedback on Code Quality in Programming Courses". http://stgm.nl/quality, 2016. Presenta una rúbrica de calidad de código de programación para principiantes.

Stei2013

Igor Steinmacher, Igor Wiese, Ana Paula Chaves, and Marco Aurelio Gérosa: "Why do newcomers abandon open source software projects?". In 2013 International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE'13), 5 2013, doi:10.1109/chase.2013.6614728. Explora por qué los/las nuevos/as integrantes de proyectos de código abierto \emphno se quedan.

Stei2016

Igor Steinmacher, Tayana Uchoa Conte, Christoph Treude, and Marco Aurélio Gerosa: "Overcoming open source project entry barriers with a portal for newcomers". In 2016 International Conference on Software Engineering (ICSE'16), 2016, doi:10.1145/2884781.2884806. Informa la efectividad de un portal diseñado específicamente para ayudar a las personas recién llegadas.

Stei2018

Igor Steinmacher, Gustavo Pinto, Igor Scaliante Wiese, and Marco Aurélio Gerosa: "Almost There: A Study on Quasi-Contributors in Open-Source Software Projects". In 2018 International Conference on Software Engineering (ICSE'18), 2018, doi:10.1145/3180155.3180208. Analiza por qué los/las desarrolladores/as externos/as no logran que sus contribuciones sean aceptadas en proyectos de código abierto.

Stoc2018

Jean Stockard, Timothy W. Wood, Cristy Coughlin, and Caitlin Rasplica Khoury: "The Effectiveness of Direct Instruction Curricula: A Meta-analysis of a Half Century of Research". Review of Educational Research, 1 2018, doi:10.3102/0034654317751919. Un metaanálisis que encuentra un beneficio positivo significativo para la instrucción directa.

Sung2012

Eunmo Sung and Richard E. Mayer: "When Graphics Improve Liking but not Learning from Online Lessons". Computers in Human Behavior, 28(5), 9 2012, doi:10.1016/j.chb.2012.03.026. Informa que los/las estudiantes que reciben cualquier tipo de gráfico dan calificaciones de satisfacción significativamente más altas que quienes no, pero solo aquellos/as estudiantes que obtienen gráficos instructivos se desempeñan mejor que los grupos que no obtienen gráficos, gráficos atractivos o gráficos decorativos.

Sved2016

Maria Svedin and Olle Bälter: "Gender Neutrality Improved Completion Rate for All". Computer Science Education, 26(2-3), 7 2016, doi:10.1080/08993408.2016.1231469. Informa que rediseñar un curso en línea para que sea neutral en cuanto al género mejora la probabilidad de finalización en general, pero la disminuye para los/las estudiantes con un enfoque superficial del aprendizaje.

Tedr2008

Matti Tedre and Erkki Sutinen: "Three Traditions of Computing: What Educators Should Know". Computer Science Education, 18(3), 9 2008, doi:10.1080/08993400802332332. Resume la historia y puntos de vista de tres tradiciones en informática: matemática, científica e ingeniería.

Tew2011

Allison Elliott Tew and Mark Guzdial: "The FCS1: A Language Independent Assessment of CS1 Knowledge". In 2011 Technical Symposium on Computer Science Education (SIGCSE'11), 2011, doi:10.1145/1953163.1953200. Describe el desarrollo y la validación de un instrumento de evaluación independiente del lenguaje para el conocimiento de CS1.

Thay2017

Kyle Thayer and Amy J. Ko: "Barriers Faced by Coding Bootcamp Students". In 2017 International Computing Education Research Conference (ICER'17), 2017, doi:10.1145/3105726.3106176. Los informes indican que los campamentos de entrenamiento en programación a veces son útiles, pero la calidad es variada y persisten barreras formales e informales al empleo.

Ubel2017

Robert Ubell: "How the Pioneers of the MOOC got It Wrong". http://spectrum.ieee.org/tech-talk/at-work/education/how-the-pioneers-of-the-mooc-got-it-wrong, 2017. Una breve exploración de por qué los cursos abiertos masivos en línea (MOOCs) no han estado a la altura de las expectativas iniciales.

Urba2014

David R. Urbach, Anand Govindarajan, Refik Saskin, Andrew S. Wilton, and Nancy N. Baxter: "Introduction of Surgical Safety Checklists in Ontario, Canada". New England Journal of Medicine, 370(11), 3 2014, doi:10.1056/nejmsa1308261. Informa un estudio que muestra que la introducción de listas de verificación quirúrgica no tuvo un efecto significativo sobre los resultados quirúrgicos.

Utti2013

Ian Utting, Juha Sorva, Tadeusz Wilusz, Allison Elliott Tew, Michael McCracken, Lynda Thomas, Dennis Bouvier, Roger Frye, James Paterson, Michael E. Caspersen, and Yifat Ben-David Kolikant: "A Fresh Look at Novice Programmers' Performance and Their Teachers' Expectations". In 2013 Conference on Innovation and Technology in Computer Science Education (ITiCSE'13), 2013, doi:10.1145/2543882.2543884. Replica un estudio anterior que muestra lo poco que aprenden los/las estudiantes en su primer curso de programación.

Uttl2017

Bob Uttl, Carmela A. White, and Daniela Wong Gonzalez: "Meta-analysis of Faculty's Teaching Effectiveness: Student Evaluation of Teaching Ratings and Student Learning are not Related". Studies in Educational Evaluation, 54, 9 2017, doi:10.1016/j.stueduc.2016.08.007. Resume los estudios que muestran que la forma en que los/las estudiantes califican un curso y cuánto realmente aprenden no están relacionados.

Varm2015

Roli Varma and Deepak Kapur: "Decoding Femininity in Computer Science in India". Communications of the ACM, 58(5), 4 2015, doi:10.1145/2663339. Informa sobre la participación femenina en informática en India.

Vell2017

Mickey Vellukunnel, Philip Buffum, Kristy Elizabeth Boyer, Jeffrey Forbes, Sarah Heckman, and Ketan Mayer-Patel: "Deconstructing the Discussion Forum: Student Questions and Computer Science Learning". In 2017 Technical Symposium on Computer Science Education (SIGCSE'17), 2017, doi:10.1145/3017680.3017745. Encontró que los/las estudiantes hacen principalmente preguntas constructivistas y logísticas en foros, y que las primeras se correlacionan con las calificaciones.

Viha2014

Arto Vihavainen, Jonne Airaksinen, and Christopher Watson: "A Systematic Review of Approaches for Teaching Introductory Programming and Their Influence on Success". In 2014 International Computing Education Research Conference (ICER'14), 2014, doi:10.1145/2632320.2632349. Consolida los estudios de los cambios de enseñanza de nivel CS1 y encuentra que la computación de medios es la más efectiva, mientras que la introducción de un tema de juego es la menos efectiva.

Wall2009

Thorbjorn Walle and Jo Erskine Hannay: "Personality and the Nature of Collaboration in Pair Programming". In 2009 International Symposium on Empirical Software Engineering and Measurement (ESER'09), 10 2009, doi:10.1109/esem.2009.5315996. Reporta que la comunicación es más intensa entre compañeros/as con diferentes niveles de un rasgo de personalidad dado.

Wang2018

April Y. Wang, Ryan Mitts, Philip J. Guo, and Parmit K. Chilana: "Mismatch of Expectations: How Modern Learning Resources Fail Conversational Programmers". In 2018 Conference on Human Factors in Computing Systems (CHI'18), 2018, doi:10.1145/3173574.3174085. Informa que los recursos de aprendizaje realmente no ayudan a los/las programadores/as conversacionales (aquellos/as que aprenden a codificar para participar en discusiones técnicas).

Ward2015

James Ward: Adventures in Stationery: A Journey Through Your Pencil Case. Profile Books, 2015, 1846686164. Una mirada maravillosa a los artículos cotidianos que estarían en el cajón de su escritorio si alguien no se hubiera marchado con ellos.

Wats2014

Christopher Watson and Frederick W. B. Li: "Failure Rates in Introductory Programming Revisited". In 2014 Conference on Innovation and Technology in Computer Science Education (ITiCSE'14), 2014, doi:10.1145/2591708.2591749. Una versión más amplia de un estudio inicial que encontró que en promedio un tercio de los/las estudiantes reprobó CS1.

Watt2014

Audrey Watters: The Monsters of Education Technology. CreateSpace, 2014, 1505225051. Una colección de ensayos sobre la historia de la tecnología educativa y las exageradas afirmaciones que se hacen repetidamente a su favor.

Wein2018a

Yana Weinstein, Christopher R. Madan, and Megan A. Sumeracki: "Teaching the Science of Learning". Cognitive Research: Principles and Implications, 3(1), 1 2018, doi:10.1186/s41235-017-0087-y. Una revisión tutorial de seis prácticas de aprendizaje basadas en evidencia.

Wein2018b

Yana Weinstein, Megan Sumeracki, and Oliver Caviglioli: Understanding How We Learn: A Visual Guide. Routledge, 2018, 978-1138561724. Un breve resumen gráfico de estrategias de aprendizaje eficaces.

Wein2017

David Weintrop and Uri Wilensky: "Comparing Block-Based and Text-Based Programming in High School Computer Science Classrooms". ACM Transactions on Computing Education, 18(1), 10 2017, doi:10.1145/3089799. Informa que los/las estudiantes aprenden más rápido y mejor con bloques que con texto.

Weng2015

Etienne Wenger-Trayner and Beverly Wenger-Trayner: "Communities of Practice: A Brief Introduction". http://wenger-trayner.com/intro-to-cops/, 2015. Un breve resumen de lo que son y no son las comunidades de práctica.

Wibu2016

Karin Wiburg, Julia Parra, Gaspard Mucundanyi, Jennifer Green, and Nate Shaver (eds.): The Little Book of Learning Theories. CreateSpace, 2016, 1537091808. Presenta breves resúmenes de varias teorías del aprendizaje.

Wigg2005

Grant Wiggins and Jay McTighe: Understanding by Design. Association for Supervision & Curriculum Development (ASCD), 2005, 1416600353. Una presentación extensa del diseño instruccional de atrás para adelante.

Wilc2018

Chris Wilcox and Albert Lionelle: "Quantifying the Benefits of Prior Programming Experience in an Introductory Computer Science Course". In 2018 Technical Symposium on Computer Science Education (SIGCSE'18), 2018, doi:10.1145/3159450.3159480. Informa que los/las estudiantes con experiencia previa superan a los/las estudiantes sin CS1, pero no hay una diferencia significativa en el desempeño al final de CS2; también encuentra que las estudiantes mujeres con exposición previa superan a sus compañeros varones en todas las áreas, pero tienen menos confianza en sus habilidades.

Wile2002

David Wiley: "The Reusability Paradox". http://opencontent.org/docs/paradox.html, 2002. Resume la tensión entre que los objetos de aprendizaje sean efectivos y reutilizables.

Wilk2011

Richard Wilkinson and Kate Pickett: The Spirit Level: Why Greater Equality Makes Societies Stronger. Bloomsbury Press, 2011, 1608193411. Presenta evidencia de que la desigualdad perjudica a todos/as, tanto económicamente como de otro modo.

Will2010

Daniel T. Willingham: Why Don't Students Like School?: A Cognitive Scientist Answers Questions about How the Mind Works and What It Means for the Classroom. Jossey-Bass, 2010, 047059196X. Un científico cognitivo observa cómo funciona la mente en el aula.

Wils2007

Karen Wilson and James H. Korn: "Attention During Lectures: Beyond Ten Minutes". Teaching of Psychology, 34(2), 6 2007, doi:10.1080/00986280701291291. Encuentra poca evidencia que apoye la afirmación de que los/las estudiantes solo tienen un período de atención de 10 a 15 minutos (aunque hay mucha variación individual).

Wils2016

Greg Wilson: "Software Carpentry: Lessons Learned". F1000Research, 1 2016, doi:10.12688/f1000research.3-62.v2. Historia y análisis de Software Carpentry.

Wlod2017

Raymond J. Wlodkowski and Margery B. Ginsberg: Enhancing Adult Motivation to Learn: A Comprehensive Guide for Teaching All Adults. Jossey-Bass, 2017, 1119077990. La referencia estándar para comprender la motivación de las personas adultas.

Xie2019

Benjamin Xie, Dastyni Loksa, Greg L. Nelson, Matthew J. Davidson, Dongsheng Dong, Harrison Kwik, Alex Hui Tan, Leanne Hwa, Min Li, and Amy J. Ko: "A theory of instruction for introductory programming skills". Computer Science Education, 29(2-3), 1 2019, doi:10.1080/08993408.2019.1565235. Presenta una teoría de cuatro partes para enseñar a pesonas novatas basada en lectura versus escritura y código versus plantillas.

Yada2016

Aman Yadav, Sarah Gretter, Susanne Hambrusch, and Phil Sands: "Expanding Computer Science Education in Schools: Understanding Teacher Experiences and Challenges". Computer Science Education, 26(4), 12 2016, doi:10.1080/08993408.2016.1257418. Resume los comentarios de maestros/as de Jardín a 12 años sobre lo que necesitan a modo de preparación y apoyo.

Yang2015

Yu-Fen Yang and Yuan-Yu Lin: "Online Collaborative Note-Taking Strategies to Foster EFL Beginners' Literacy Development". System, 52, 8 2015, doi:10.1016/j.system.2015.05.006. Informa que los/las estudiantes que toman notas de forma colaborativa al aprender inglés como lengua extranjera obtienen mejores resultados que los que no lo hacen.

---

1. Nota de la editora: el autor inventó el término "free-range" por analogía con la crianza de pollos y vacas de campo: estudiantes que son libres de deambular, estirar las piernas, etc. que aprenden fuera de un aula institucional con un plan de estudios y tareas obligatorias. El autor también se refiere a las/los estudiantes que se sientan en escritorios y aulas como "battery-farmed" (nuevamente por analogía con la crianza a animales de granja)↩︎

2. En inglés↩︎

3. Todos en inglés↩︎

4. Sigla de HyperText Markup Language en inglés↩︎

5. Sigla de Cascading Style Sheets en inglés↩︎

6. Definitivamente nuestro cerebro no trabaja de esta manera, pero es una metáfora útil.↩︎

7. Parafraseando a Lady Windermere, obra de Oscar Wilde, las personas a menudo no saben lo que piensan hasta que se escuchan a sí mismas decirlo↩︎

8. Mi agradecimiento a Warren Code por presentarme este ejemplo.↩︎

9. Un modelo más completo también incluiría el sentido del tacto, del olfato y del gusto, pero por ahora los ignoraremos.↩︎

10. Nombrado así debido a uno de sus creadores.↩︎

11. Por mucho tiempo creí que la variable que contenía el valor que una función iba a devolver tenía que llamarse resultado, porque mi docente siempre usaba ese nombre en los ejemplos.↩︎

12. Los afiches se encuentran en español, busca el botón posters in other languages en la web↩︎

13. Por un tiempo, me preocupé tanto por la afinación que perdí completamente mi sentido del tiempo↩︎

14. Una colega me dijo una vez que la unidad básica de enseñanza es la vejiga. Cuando le contesté que yo nunca había pensado en eso, dijo: “Obviamente nunca has estado embarazado”↩︎

15. “¡Y Linux!”, grita alguien desde el fondo del salón.↩︎

16. Inspirado en un verso de María Elena Walsh, del libro Zoo Loco.↩︎

17. Esta práctica se conoce como hardcodear↩︎

18. Las personas que prefieren lo último a menudo están solo interesadas en discutir…↩︎

19. Este es uno de los momentos en que vale la pena tener vínculos con el gobierno local u otras organizaciones afines.↩︎

20. Así como la prevalencia de una mentalidad cerrada entre los/las docentes cuando se trata de enseñanza, es decir, la creencia de que algunas personas son “solo mejores enseñando”↩︎

21. En el link encuentras el texto completo en castellano. El fragmento que sigue es una traducción propia del original en inglés.↩︎

22. Yo ciertamente lo hice cuando me hicieron vivir esto…↩︎