performance.en.qmd

# Teaching as a Performance Art {#sec-performance}

::: callout-note
## Segunda edición

You are reading the second edition in progress of Teaching Tech Together. This chapter is undergoing major restructuring and may be confusing or incomplete. Please visit <https://teachtogether.tech> to see the current version.
:::

In *Darwin Among the Machines*, [George Dyson]{i="Dyson, George"} wrote, “In the game of life and evolution there are three players at the table: human beings, nature, and machines. I am firmly on the side of nature. But nature, I suspect, is on the side of the machines…” There are similarly now four players in the game of education: textbooks and other read-only materials, live lectures, and automated online lessons and *Generative AI* or GenAI. You may give your learners both written lessons and some combination of recorded video and self-paced exercises, but if you are going to teach in a synchronous way you must offer something different from (and hopefully better than) any of the previews options. This chapter therefore focuses on how to teach programming by actually doing it and other tecnological tool by using them.

## The Participatory Live Coding and Demostration Framework {#sec-performance-live-coding}

The methods we are going to present are known as *participatory live coding* and *participatory live demonstration*.

Participatory live coding bring programming to life in our classroom. It is a technique in which the person teaching writes and explains the code in front of the class while their students follow along, writing and executing the same code as they go (@Nederbragt2020).

Participatory live demonstration has the same principle as participatory live coding, but applies to situations where _you do not code_, but the teacher demonstrates how to use a software tool, while the students follow along, trying to replicate the same steps.

This approach is an improvement over teaching programming by showing static code, or doing a live demonstration where the audience passively watches, or where our students are relied upon to read a textbook (@Nederbragt2020). We can model the programming and debugging process on the fly with concrete examples.

By showing how to code a solution, explaining our thought processes, making mistakes, and showing what to do when things go wrong we demonstrate the processes and methods of an expert, which students can then apply (). 


Estas tecnicas encarnan el enfoque "yo lo hago, nosotros lo hacemos, tú lo haces" de la transferencia de conocimientos, que se utiliza tanto en entornos educativos formales e informales para enseñar desde técnicas de laboratorio hasta la redacción de solicitudes de fondos (@Nederbragt2020). Tambien se pueden considerar una implementación de la *práctica guiada*, la cual consiste en que quien enseña va presentando y resolviendo ejemplos de la habilidad o concepto que se está enseñando, junto con los estudiantes, paso a paso, mientras comprueba que ejecutan cada paso correctamente. (@hollingsworth2009).
This is a form of *cognitive apprenticeship*, where students learn by observing, doing, and reflecting on authentic tasks within a domain. They gradually acquire procedural and conceptual knowledge through modeling, coaching, and scaffolding (@Collins1988).


What are the two main pedagogical techniques that support participatory live coding
Cognitive apprenticeships
involve learning by observing, doing, and reflecting on authentic tasks within a domain. Students gradually acquire procedural and conceptual knowledge through modeling, coaching, and scaffolding.

Active learning
is a student-centered paradigm in which students should not only passively listen, but also read, write, discuss, engage in solving problems and actively think and reflect throughout this process.

How we apply them with participatory live coding?
Modelling involves an expert, the teacher in our case, showing learners how to carry out a task while externalize their internal processes and activities.

In live coding, the teacher develops a program (from scratch) in front of a class, while highlighting their choices, decisions, mistakes, and debugging strategies. The class follows along. Mistakes should be part of the live coding because allow us to show hoe to debug, a very useful skills and also shows that programmers don’t get it right from the start, often have to review and fix their work and programs are not written from beginning to end.

Coaching happened when learners solve a challenge that is slightly too difficult for them supported through feedback and further modelling from the teacher and class-mates.

Live coding is a great example of a coaching strategy, and is a way of guiding learners through a task they, while can propose different solutions and made predictions that can be tested and get instant feedback.

Finally, students can obtain scaffolding during live coding in how the teacher break down a problem or an error, highlight sub-goals, together with the use of tools to coding and debug. Planed error for the live coding session allow us to scaffold students in solving the most common mistakes that begginers make.

The active learning aspect is directly related to the component of programming together with the teacher, making predictions about the program before it is run, propose different solution to a program and testing them by coding in the moment, discussing, and reflecting on the result obtained with the teacher and classmates.

Participatory Live Coding is an active learning technique that shows a more realistic programming process in your classroom providing good debugging and development practices and the chance for our student of learning by doing in collaboration with their classmate and the teacher guidance.




::: callout-note
## Programacion en vivo

No hay acuerdo en lo que la comunidad de investigacion considera _programacion en vivo._ En la revision de literatura realizada por @Selvaraj2021 encontraron las siguientes definiciones:

1. Escribir codigo en vivo en una computadora enfrente de estudiantes durante una clase.

2. Disenar e implementar un proyecto de programacion en frente de una clase durante una leccion.

Con las siguientes caracteristicas:

1. Se debe usar un archivo en blanco, sin esqueleto de codigo.

4. La pantalla de alguien que programa (docente o estudiante) se proyecta a toda la clase.

5. La persona que programa en vivo debe pensar en vos alta durante la programacion en vivo.

6. Ocurre en clases sincronicas o asincronicas. En esta ultima se graba la sesion de programacion en vivo para que sus estudiantes la vean a su conveniencia.

En ninguna de estas definiciones y caracteristicas se menciona que tus estudiantes tienen que programar junto contigo cuando estas ensenando con programacion en vivo.  Esa es la principal diferencia con la tenica a la que nos referiremos en este capitulo: la programacion participatoria en vivo, donde tanto docentes como estudiantes escriben el codigo en un archivo en blanco en el mismo momento de forma sincronica.
:::

## Programacion participativa en vivo {#sec-performance-live}

> La enseñanza es teatro, no cine.<br/> --- [Neal Davis]{i="Davis, Neal"}

Esta es una estrategia eficaz para enseñar a programar (@Rubi2013,@Haar2017,@Raj2018), ya que:

- Permite que les estudiantes vean el proceso de pensamiento de quien enseña y sus técnicas de resolución de problemas en tiempo real mientras programan, facilitando la [transferencia de conocimiento]{i="transferencia de conocimiento"}: las personas aprenden más de lo que enseñamos conscientemente al observar *cómo* hacemos las cosas. 

- Posibilita una [enseñanza activa]{g="active-teaching"} al permitir a los y las docentes seguir los intereses, las preguntas y los comentarios de sus estudiantes.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.

- Posibilita un [aprendizaje activo]{g="active learning"} al involucrar a tus estudiantes, lo que les ayuda a convertirse en practicantes activos en lugar de observadores pasivos del proceso de programación. Sus preguntas pueden responderse inmediatamente y los conceptos erróneos pueden corregirse programandolos. Los ejercicios permiten practicar en el momento el uso del material incluyendo diferentes alternativas.

-   Disminuye la velocidad de la persona que está enseñando: si tiene que escribir el programa a medida que avanza su velocidad es mucho menor a la que tendría usando diapositivas o un codigo pre-armado. Esto dismunuye la carga cognitiva de la memoria a corto plazo y le da mas tiempo a tus estudiantes para poder realizar las actividades y realizar preguntas antes de pasar al siguiente concepto.  

-   Permite enseña cómo diagnosticar y corregir errores. Resolver errores es una tarea crucial de la programacion.  La programacion en vivo nos permite cometer errores cuando programos (ya sean deliverados o no) permitiendonos explicar como es el proceso de resolucion. Ademas, les muestra a tus estudiantes que los errores son parte del proceso y que incluso quien ensena los puede cometer, dandoles lugar para que cometan errores y nos puedan hablar sobre ello. 

- Demuestra el orden en que se deben escribir los programas. Cuando @Ihan2011 observaron cómo las personas resuelven [problemas de Parson]{i="problema de Parsons"}, 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 sub-metas 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 eso mejore las cosas (@Spoh1985).

Como toda tecnica de ensenanza, hablar mientras se escribe código en frente de un público requiere práctica. La mayoría de las personas indican que el nivel de dificultad rápidamente se vuelve igual que hablar con una presentación de diapositivas. Las secciones que siguen ofrecen consejos sobre cómo mejorar la manera de ensenar con programacion participativa en vivo.

### Que te vean y te escuchen 

A medida que tus estudiantes van codificando, deben ver y oír lo que estás haciendo con claridad. 

#### En persona

Si eres físicamente capaz de pararte durante un par de horas, debes hacerlo mientras enseñas. Esto te permitira que te muevas, por ejemplo para 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. 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. 

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.

Es conveniente tener una mesa elevada, un escritorio de pie, o un atril para tu computadora portátil para que tengas una posicion mas comoda al escribir.

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, ademas de ayudarte a cuidar tu vos puede marcar una gran diferencia para las personas que tienen discapacidad auditiva.

#### En linea

En un entorno en línea, esto puede requerir más recursos en términos de tecnología e infraestructura, como una conexión estable a Internet, una pantalla panorámica o una segunda pantalla para ti y tus estudiantes.

##### Antes de empezar la programacion en vivo

Explica a tus estudiantes cómo acomodar su pantalla. En caso de que sólo tengan una demuéstrales cómo pueden dividir la pantalla en dos vertical u horizontalmente. Si tienen dos pantallas, muestra cómo dividir las ventanas, una con las pantallas del docente y la otra con su entorno de programación. Puedes tener algunas imágenes o vídeos para mostrar cómo conseguirlo.

Si estás enseñando cursos largos (más de tres clases), podes hacer una demostración la primera clase y después hacerlo de vez en cuando como recordatorio. También podes compartir estos videos o imágenes asi tus estudiantes pueden chequear como ordenar sus pantallas.

##### Durante la programacion en vivo

* comparte tu pantalla y pregunta antes de empezar a programar si tus estudiantes ven tu pantalla correctamente y si el tamaño de la fuente es adecuado. Cambialo si te lo solicitan.

* Agranda tu puntero del mouse y considera usar un puntero resaltado ( algo como esto).

* Usa un software que muestre en pantalla las teclas que presionas, como Screenkey. Si te olvidas de decir un atajo de teclado en voz alta, el programa lo mostrará en la pantalla para tus estudiantes.

* El fondo blanco es mejor para las clases sincrónicas. El tema nocturno es mejor para los vídeos grabados porque hay estudiantes que los ven de noche y utilizan dispositivos pequeños.

* Si puedes, comparte tu código no solo por medio de tu pantalla mientras lo escribes. Existen soluciones para transmitir en directo tu progrmacion en vivo a paginas web estaticas donde tus estudiantes pueden acceder a tu codigo. 


::: {.callout-tip}
## Después de la programacion participatoria en vivo

Debemos considerar la posibilidad de que algunos estudiantes se hayan quedado atrás, no puedan resolver un ejercicio o lo hagan de forma poco eficiente. 

Por eso es importante compartir el código generado en vivo después de la clase. Puedes copiarlo y pegarlo en el chat de la plataforma, copiarlo y pegarlo en los apuntes compartidos o subirlo a la página web del curso o al campus virtual. También puedes compartir una carpeta en un servicio de almacenamiento en la nube. 

Disponer del código final ayudará a tus estudiantes a validar su código y a ponerse al día si no pueden copiar o escribir alguna parte del mismo.
:::
 
### Ve despacio y no enseñes sola/o. 

Cuando se realiza codificación participativa en vivo, es necesario enseñar y programar a un ritmo que permita a tus estudiantes seguir el proceso sin quedarse atrás. 

Empieza con un script o notebook en blanco para asegurarte de que les explicas todo lo que necesitan para que el código funcione. Explica el objetivo del código que vas a desarrollar y escríbelo en la notebook o como comentario en el script. Nos ayuda a centrarnos en lo que queremos y en el razonamiento que hay detrás de codificar para ese objetivo. *No* copies y pegues código: hacer eso prácticamente garantiza que irás mucho más rápido que tus estudiantes. 

Narra lo que escribes, las combinaciones de teclas y atajos de teclado, especialmente cuando tengas que utilizar signos de puntuación complicados (“corchetes”, “paréntesis”, etc.). Cuando una IDE autocompleta cosas, es útil señalarlo las primeras veces (y decir cómo se usa o activa esa característica) ya que puede ser la primera vez que algunos estudiantes lo vean.

No utilices muchos atajos de teclado, sobre todo al principio. Si utilizas un atajo de teclado, dilo en voz alta la primera vez que lo hagas. Explica una alternativa al atajo (por ejemplo, el uso de menús). Puedes recordar a tus estudiantes qué atajos utilizas de vez en cuando (en caso de que no utilices un programa que muestre las teclas que pulsaste en pantalla).

Explica cada paso que has dado. Di en voz alta lo que estás haciendo mientras lo haces para cada comando o cada palabra de código que escribes y cada elemento de menú o botón que pulsas. A continuación, señala el comando y su resultado en la pantalla y repítelo para que tus estudiantes puedan comprobar lo que han hecho.

Si la salida de 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 (o en el chat si estas en linea).

Menciona el número de línea del código al que te refieres.

#### En linea 

Los consejos anteriores son validos para clases en persona y en linea. Hay algunas consideraciones extra para los entornos en línea:

* es esencial que tus estudiantes puedan cambiar de ventana (la demostración del docente y su propia codificación) o de pantalla si tienen más de una.

* Tu ayudante o co-docente debe prestar atención al chat, ayudando a localizar y resolver los problemas de tus estudiantes, copiando enlaces o trozos de código si es necesario, y avisándote cuando haya que aclarar, volver a explicar o mostrar algo una vez más.

* Si estás enseñando sin ayuda, informa a tus estudiantes cuándo estarás prestando atención al chat para ayudarles. Deja claro cómo pueden participar y hacer preguntas (utilizando el chat, utilizando una expresión no verbal, notas compartidas, activando su microfono, etc.) y cómo responderás tú.

* Utiliza el chat o el documento de las notas compartidas para copiar y pegar el código o los errores de tus estudiantes. Ten cuidado con los sistemas de chat traicioneros que pueden cambiar el formato de tu código. 

### Duplica el entorno de tus estudiantes. 

Si tus estudiantes tienen que trabajar en un entorno distinto al tuyo, tienen que hacer un esfuerzo mental que no contribuye al aprendizaje. La ciencia del aprendizaje llama a esto “carga cognitiva externa”. Intenta crear un entorno lo más parecido posible al que tienen tus estudiantes. Si son principiantes, es muy probable que tengan la configuración por defecto de la IDE o software que vayas a utilizar.

Una solución basada en la nube es la mejor alternativa para asegurarte de que tú y tus estudiantes tienen la misma configuración. Algunas de estas herramientas te permiten incluir todo el software, paquetes y datos que necesitas evitando problemas de instalación y la consiguiente frustración.  Dentro de los problemas que tienen esta soluciones está el costo y el ancho de banda necesario para usarlas durante las clases.

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 tu(s) pantalla(s) sabiamente. 

### En persona

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. 

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.

::: {.callout-tip}
### Las herramientas de accesibilidad ayudan a todas las personas

Las herramientas como \[Mouseposé\]\[mousepose\] (para Mac) y \[PointerFocus\]\[pointerfocus\] (para Windows) resaltan la posición del cursor del mouse en la pantalla, y las herramientas de grabación de pantalla como \[Camtasia\]\[camtasia\] y aplicaciones independientes como \[KeyCastr\]\[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 (@sec-classroom-notetaking). 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.


#### On line

Ya hemos mencionado que necesitas mostrar a tus estudiantes cómo acomodar su pantalla para verte mejor. Al utilizar programacion en vivo, también debes acomodar tu(s) pantalla(s) para enseñar.

La mejor solución es utilizar dos dispositivos o pantallas al enseñar: una para compartir con tus estudiantes y otra para ver sus notas y vídeos, las notas de la lección y la ventana de chat.

Si no tienes dos pantallas, comparte con tus estudiantes sólo las ventanas o paneles que quieras que vean. Puedes tener las notas de la lección impresas en papel o en una ventana no compartida.

Amplía el panel de la pantalla que necesitas mostrar. Por ejemplo, si necesitas mostrar el código amplía las ventanas de script. Si necesitas mostrar un resultado, amplía el panel de la consola, o de gráficos, etc.

Una de las ventajas de la enseñanza en línea es que cuando la gente se encuentra con problemas, puede compartir la pantalla y resolver el problema trabajando en conjunto. Si tu estudiante se siente cómodo/a, permitirle compartir su pantalla para resolver problemas con toda la clase; esta es una excelente experiencia de aprendizaje. También pueden compartir su pantalla para demostrar algo que han hecho.

### Evita las distracciones. 

Desactiva las notificaciones en los dispositivos que estés utilizando y en tu teléfono. Ver las notificaciones parpadear en la pantalla te distrae a ti y a tus estudiantes. Abre sólo el software, las aplicaciones y las páginas web que vayas a utilizar durante la clase. Cierra cualquier otra aplicación, incluidos el correo electrónico y las redes sociales. Ten en cuenta qué imagen de escritorio y salvapantallas utilizas porque acabarás compartiéndolos con la clase y en el vídeo si grabas la lección. De nuevo, tener una cuenta especifica para ensenar puede ayudarte a cumplir este punto de forma mas sencilla.

Es importante que tu ayudante o co-docente trabaje para resolver las dudas y problemas que puedan tener tus estudiantes durante la clase, de modo que las interrupciones sean ordenadas y sirvan a la lección en lugar de cortar su fluidez. Acuérdate también de dar instrucciones sobre cómo participar, cómo hacer preguntas y qué herramientas utilizar antes de empezar la demostración en vivo (ver consejo número 1).

Por último, pide a tus estudiantes que reduzcan el número de distracciones en sus dispositivos, como notificaciones, correos electrónicos y otras pestañas del navegador que puedan tener abiertas mientras tiene lugar la clase. No puedes controlar lo que hacen, pero hacer una petición amistosa puede ayudarles a cerrar estos distractores.

### Sigue el material de la lección. 

#### En persona

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.

::: {.callout-tip}
### Enseñanza directa

La [enseñanza directa]{g="direct-instruction"} 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.
::: 

#### Online 

Es importante que te ajustes bastante al plan de la lección y que practiques la técnica de codificación en vivo, sobre todo si es la primera vez que impartes la lección. Añade notas a tus impresiones del material de la clase, o tenlas fácilmente disponibles en la segunda pantalla o dispositivo (tableta o portátil), si utilizas uno.

Una vez que el material te sea familiar, puedes y debes empezar a improvisar basándote en los antecedentes de tus estudiantes, sus preguntas en clase y lo que te parezca más interesante.

Si surge una pregunta o un “¿qué pasaría si…?”, pero no quieres interrumpir el flujo de la lección, o sabes que te llevará más tiempo del que tienes, o necesitas algo de tiempo para ordenarte, pide a tus estudiantes que las agreguen en un documento compartido en línea o pide a tu co-docente o ayudante que las registre. Luego, puedes pensar en ellas mientras tus estudiantes hacen los ejercicios y responderlas después que terminen, o a la clase siguiente.


### Convierte a tus estudiantes en co-docentes 

#### Online

Durante la codificación participativa en vivo, las/os estudiantes programan activamente junto con el docente. Esto puede ser un reto en la enseñanza en línea y más aún con principiantes.

Una herramienta valiosa para disminuir esta dificultad es utilizar las salas de reuniones que ofrecen Zoom o Meet (incluso en su versión gratuita). La enseñanza entre pares es la práctica docente escalable más eficaz que conocemos. Podemos utilizarla para reforzar la lección que dimos usando programación en vivo.

Las salas de reuniones de Zoom hacen que esto sea relativamente fácil de ejecutar en línea: se tarda entre 15 y 30 segundos en meter a todo el grupo en las salas. En una clase de cuarenta personas, uno o dos tendrán dificultades al principio, pero ayuda a mantener a tus estudiantes motivados y atentos.

Yo utilizo esta dinámica con los principiantes cuando hago live coding:

Hago entre 10 y 20 minutos de live coding.
Los envío a la salas en grupos de 3 o 4 estudiantes (los grupos más grandes crean subgrupos, o bien alguien no participa) para resolver un ejercicio.
El ejercicio es el mismo o muy similar al que intentamos hacer durante mi programación en vivo.
Antes de ir a la sala, doy las instrucciones: cuánto tiempo tienen para resolver el ejercicio (entre 10 y 20 minutos), como se den organizar: un estudiante comparte una pantalla, y programan juntos para resolverlo.
Tomo el tiempo (ahora la herramienta de videoconferencia lo hace por mí), y cuando se acaba el tiempo, vuelven a la sala común, y hablamos de cómo ha ido, qué problemas y preguntas tienen. Repasamos estos detalles. Es un buen momento para dejarles compartir la pantalla para ver sus problemas o soluciones, sobre todo si han resuelto el ejercicio de forma diferente.
Esta estrategia les permite reforzar el aprendizaje porque programan durante mi live coding y luego una vez más en grupo.

Puedes utilizar diferentes tipos de ejercicios para el trabajo en grupos, como rellenar los espacios en blanco, problemas de Parson y tutoriales interactivos que ofrezcan diferentes tipos de andamiaje.

### Obten información en tiempo real y proporciona ayuda inmediata. 

#### En persona

### 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,]{i="instrucción por pares"} que discutiremos en la @sec-classroom-peer. Además de mantener su atención en la actividad, les permite practicar cómo razonar sobre el comportamiento del código.

#### Online

Al programar en vivo en línea puede resultar difícil saber si tus estudiantes están siguiendo el proceso o si están teniendo dificultades para programar que aún no se hemos solucionado.

Una forma de comprobarlo es ofrecer a tus estudiantes una manera diferente de indicarnos su estado. Cuando enseñamos en persona, utilizamos notas adhesivas de colores. Algunas opciones para enseñar en línea son:

El feedback no verbal en plataformas de videoconferencia aparece como la primera opción para sustituir a las notas adhesivas de colores. Si utilizamos Zoom, se puede pedir a una persona que marque con una marca verde si ha terminado o con una marca roja en caso de que esté atascada. Al igual que con las notas adhesivas, estas marcas no se quitan solas, por lo que es necesario pedir a la persona que las quite si ya ha resuelto el problema o que pase a otro ejercicio.

Crea una tabla en el documento colaborativo (utilizando HackMD o google docs) con los nombres de todos los participantes. Pídeles que pongan un check verde o una cruz roja para comprobar si van por buen camino. Puedes comprobar si alguien no ha rellenado algo.

En zoom, las otras reacciones con emojis son útiles para un estado general rápido porque también nos muestran el número de cada emoji en la lista de participantes. Pero estos emojis se limpian al cabo de un rato, por lo que puedes perderte alguna información. Con el mismo propósito, también podemos pedirles que escriban en el chat cuando terminen una tarea. Aunque puede ser mucha información junta en grupos de más de 20 personas y complicado determinar quién no contestó.

Se pueden utilizar otras herramientas, como encuestas o un canal paralelo de Slack, pero agregar más herramientas a la clase sincrónica, sobre todo si es una herramienta nueva, es una carga cognitiva que debemos considerar.

Algunos temas permiten agregar en el código un elemento de aleatoriedad que va a dar resultados diferentes en diferentes máquinas o entornos y podes preguntarle a tus estudiantes si sus resultados son iguales a los tuyos. Cuando enseño gráficos de redes, el algoritmo es no determinístico por o que el gráfico que obtienen mis estudiantes suele ser diferente al mio, muchas veces no necesito preguntar, el chat se inunda con mensajes avisando que sus gráficos son distintos. De esta forma sabrás que te siguen.

Una vez más, enseñar con otras personas es una buena estrategia para este consejo. El papel principal de tus co-docentes es garantizar que tus estudiantes no se queden atrás debido, por ejemplo, a problemas técnicos. A veces es una buena idea crear una sala para resolver problemas técnicos donde tu estudiante y co-docentes puedan ir y resolver el problema. Tus ayudantes deben prestar atención a los documentos compartidos, los emojis o el canal de Slack, que indican que un/a estudiante está pidiendo ayuda.

### Usa ilustraciones, aún mejor dibujalas en tiempo real. 

#### En persona

### 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 (@sec-architecture-brain) y te permite improvisar.


#### Online
Los diagramas y mapas conceptuales pueden ayudar a tus estudiantes a comprender las etapas de la lección y a organizar el material. Generar los diagramas junto con tus estudiantes a medida que avanzas en el material puede funcionar muy bien. Hay varias herramientas para hacerlo en línea (Miro, Jamboard, Whiteboard.fi, draw.io y excalidraw, entre otras). Puedes usarlo con el ratón o con una tableta (yo uso la Wacom One, que es estupenda).

Puedes construir diagramas, haciéndolos cada vez más complejos en paralelo con el material que enseñas. Presentar información complementaria utilizando representaciones visuales y verbales ayuda a aprender (conocido como “codificación dual”).

Por ejemplo, yo solía dibujar un mapa conceptual del código de control de flujo con mis alumnos para hablar de los conceptos esenciales antes de hacer la codificación en vivo. También dibujo un mapa del orden de ejecución de una sentencia SQL para explicar el resultado de una consulta o por qué debemos utilizar una función y no otra después de hacer el live coding.

Algunas herramientas permiten escribir y dibujar sobre la pantalla compartida. Esto puede ser útil para marcar parte del código y anotar el valor de una variable mientras ejecutas un fragmento de código o los pasos y el orden de ejecución de una sentencia.


### Acepta tus errores. 

#### On line
Aunque te sepas bien la lección y la sigas, es muy probable que cometas errores mientras demuestras cómo programar en vivo. Cometer errores suele ser el mayor temor de los/as docentes que utilizan esta técnica. Está bien que ocurra (ya que es lo que pasa en la vida real cuando programamos), y puede ser una excelente oportunidad para aprender a depurar. Esta forma de afrontar los errores se denomina “encuadre positivo del error”, y es beneficiosa para el aprendizaje.

Cuando se produzca un error, detente, léelo en voz alta y explica cómo has determinado lo que ha ocurrido. Marca qué parte del texto del error te da una pista que te ayuda a diagnosticarlo y resolverlo. A continuación, vuelve al código y muestra qué elemento o elementos del código arrojan el error. Es útil aclarar qué hace cada parte del código creando nuevos ejemplos que muestren por qué se produce un error en una situación y no en otra. También puedes involucrar a los estudiantes en la resolución de problemas preguntándoles qué creen que ha fallado y cómo solucionarlo.

Si tiene tiempo, utilice el error para hacer una “búsqueda en vivo”. En esta lección, enseñas cómo buscar un error en Internet, afinar esa búsqueda, leer los resultados y determinar cuál es el que más se acerca a tu problema. Aquí puedes enseñar cómo leer la ayuda y las preguntas y respuestas de Stack Overflow.

También, como se mencionó en puntos anteriores, si un/a estudiante tiene un error, puedes pedirle que comparta su pantalla, y toda la clase trabaja en conjunto para resolverlo usando estas estrategias.

Una vez que hayas dado una clase varias veces, es poco probable que cometas algo más que errores básicos de tipeo (que pueden seguir siendo informativos). Puedes intentar recordar errores pasados y cometerlos deliberadamente, pero eso puede parecer forzado. Un método alternativo es el twitch coding: pedir a los alumnos que te digan uno por uno qué tienes que escribir a continuación. Es casi seguro que te meterás en algún lío.


#### En persona
### Aprovecha tus errores

> Los errores de tipeo son la pedagogía.<br/> --- [Emily Jane McTavish]{i="McTavish, Emily Jane"}

La regla más importante de la programación en vivo es [aprovechar tus errores]{i="errores (importancia de aprovecharlos)"}. 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 (@sec-pck-debug). 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.

::: {.callout-tip}
### 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]{g="twitch-coding"}: 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.
:::

### 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 (@sec-classroom-blank). Hacer esto también reducirá su carga cognitiva, dado que centrarán su atención donde tú quieras.

## Estudiar la lección {#sec-performance-jugyokenkyu}

Hemos visto que ofrecer oportunidades para practicar y dar devoluciones constructivas a nuestros estudiantes son componentes esenciales del proceso de aprendizaje. Podemos aplicar estos mismos principios para aprender a enseñar.  

Sin embargo, mucha gente asume que los/as buenas docentes nacen, no se hacen.  Esta es una asuncion erronea. Las personas que ensenan pueden mejorar su habilidad docente con el tiempo a través de la práctica y mejoran más cuando reciben comentarios sobre como ensenaron de parte de otros docentes. Como explica @Gree2014, en japonés este enfoque se llama [*jugyokenkyu*]{g="jugyokenkyu"}, que significa "estudiar la lección".

> Para graduarse como especialistas en educación de Japón, las personas aspirantes no solo tenían que ver como trabajaba el o la docente que le asignaban, sino que ademas tenían que reemplazarlo efectivamente, primero observando en su aula y luego ensenando una clase.  Después, todas las personas involcuradas ---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.

Obervar en detalle un trabajo para mejorarlo es común en áreas tan diversas como la \[fabricación\]\[deming-edwards\] y la música. Un interprete de música profesional, por ejemplo, analizará media docena de grabaciones de la pieza que quiere tocar antes de interpretarlas. También recibirán comentarios de sus colegas 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 e hispana. 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. 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]{g="demonstration-lesson" i="lección 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 {#sec-performance-feedback}

Observar a alguien te ayuda, y darle una devolución ayuda a esa persona, pero puede ser difícil recibirlas, especialmente cuando son negativas (@fig-performance-feedback-feelings).

![Sentimientos sobre la retroalimentación (copyright © Deathbulge 2013)](diagrams/deathbulge-jerk.jpg){#fig-performance-feedback-feelings fig-alt = ""} 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]{i="retroalimentación!obtener"}:

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]{i="retroalimentación!dar"} 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<sup> Por un tiempo, me preocupé tanto por la afinación que perdí completamente mi sentido del tiempo </sup>.

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 (@fig-performance-rubric).

![Rúbrica de enseñanza](diagrams/2x2-rubric.svg){#fig-performance-rubric}

::: {.callout-tip}
### Rúbricas e inventario de preguntas

La @sec-checklists-teacheval 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.

::: {.callout-tip}
### Clases de estudio

Las escuelas de arquitectura a menudo incluyen [clases de estudio]{i="clase 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? {#sec-performance-practice}

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]{i="co-enseñanza;enseñanza!de a pares"} (@sec-classroom-together): 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 (@sec-motivation).

::: {.callout-tip}
### 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 {#sec-performance-exercises}

### Dar devolución sobre una mala enseñanza (toda la clase/20') {.exercise}

En grupo, miren \[este video de mala enseñanza\]\[video-bad-teaching\] (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') {.exercise}

Usa el proceso descripto en la @sec-performance-practice para enseñar en grupos de tres personas y recolectar las devoluciones.

### Lo malo y lo bueno (toda la clase/20') {.exercise}

Mira los videos de \[programación en vivo mal desarrollada\]\[live-coding-done-badly-es\] y \[bien desarrollada\]\[live-coding-done-well-es\] 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') {.exercise}

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') {.exercise}

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') {.exercise}

El sitio \[CS Teaching Tips\]\[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

![Conceptos: Retroalimentación](diagrams/conceptmap-feedback.svg)