Hacer que sus alumnos escriban código sin instalar nada

El cuarto de hora perdido al principio de cada sesión

En una jornada de formación, instalar un entorno de desarrollo rara vez cuesta menos de veinte minutos. Sobre todo cuesta atención: mientras ayuda a tres personas, las demás esperan, y el grupo se dispersa antes de haber escrito una sola línea.

El problema se repite en cada sesión y se agrava en tres situaciones muy habituales:

• Equipos bloqueados. En un centro de formación o en una empresa, el alumno no es administrador de su máquina. Ninguna instalación es posible sin pasar por un servicio informático.
• Material heterogéneo. Tres versiones de Windows, dos Mac, un portátil con Linux: el mismo procedimiento nunca funciona en todas partes.
• Formaciones cortas. En media jornada, veinte minutos de instalación representan casi una décima parte del tiempo total.

Un editor que vive en el navegador elimina ese paso: el alumno abre un enlace, o escanea un código, y escribe.

Qué se ejecuta en un navegador y qué no

Conviene ser claro con el alcance, porque ahí nacen las decepciones. Un navegador ejecuta muy bien las bases de un lenguaje, y nada de lo que toca el sistema.

Lo que funciona cubre lo esencial de una iniciación: salida por pantalla, entrada de teclado, condiciones, bucles, funciones, listas y diccionarios, gestión de errores y las primeras nociones de objetos. En la práctica, todo el programa de los tres o cuatro primeros días de un curso de Python.

Lo que no funciona se reduce a lo que sale del entorno aislado: interfaces gráficas, lectura y escritura de archivos, llamadas de red y bibliotecas externas que habría que instalar. Un programa que dibuja una ventana o lee un CSV necesita un entorno instalado.

Ese límite no es un defecto de la herramienta: es lo que garantiza que el programa de un alumno no toque nada más que su propia página.

Mostrar y luego dejar hacer

Una buena sesión de código alterna dos tiempos, y el segundo llega antes de lo que se cree. Mientras el formador teclea solo, el grupo se desengancha: los alumnos copian sin pensar, o esperan al final para empezar.

La disposición que mejor funciona ofrece ambos a la vez: cada uno dispone de su propio editor y trabaja en él, viendo el suyo al lado, en directo. Usted escribe un ejemplo, aparece en sus pantallas; ellos se inspiran, lo adaptan, se equivocan, vuelven a empezar — sin tener que elegir entre mirar y hacer.

Tres hábitos hacen el dispositivo más eficaz:

• Escriba el ejemplo delante de ellos, erratas incluidas. Ver a un formador corregir un error de indentación vale más que un código perfecto aparecido de golpe.
• Déjeles ocultar su pantalla cuando quieran concentrarse. El objetivo no es que le miren, es que escriban.
• Recupere la atención en los momentos clave. Un botón que devuelve a todos a solo lectura vale más que pedir silencio tres veces.

El bucle sin fin y las demás trampas del principiante

El primer while mal escrito llega siempre, a menudo en el primer cuarto de hora. En un equipo normal bloquea la máquina, el alumno se agobia y usted pierde el hilo de la sesión durante tres minutos.

Un entorno pensado para el aprendizaje interrumpe esos programas por sí solo al cabo de unos segundos, con un mensaje que explica qué ha pasado. Dígaselo a sus alumnos desde el principio: saber que no pueden romper nada los vuelve claramente más atrevidos, y el atrevimiento es justo lo que se busca en esta etapa.

Las demás trampas clásicas son más pedagógicas que técnicas:

• El mensaje de error que nadie lee. Tómese el tiempo de leer un error en voz alta, entero, la primera vez. El reflejo se adquiere rápido.
• Confundir mostrar con devolver. Merece un ejercicio propio, pronto en la progresión.
• Copiar y pegar sin comprender. Es el argumento más fuerte para dar a cada uno su propio editor: se copia menos cuando hay que ejecutar el propio programa.

Recuperar el trabajo de cada uno

Una sesión de código no produce nada duradero si el trabajo desaparece al cerrar la pestaña. Y eso es lo que ocurre con la mayoría de entornos en línea, donde el código vive en el navegador y en ningún otro sitio.

Dos usos justifican por sí solos recuperar los archivos. Primero, la corrección diferida: releer con calma lo que cada uno ha producido dice más sobre lo aprendido por el grupo que una ronda de preguntas. Segundo, la continuidad: retomar la semana siguiente donde el alumno se quedó, en vez de empezar de cero.

En la práctica, cada participante debe poder descargar su archivo con la extensión correcta, y el formador recuperar todo el grupo de una vez. Es un detalle de uso que cambia la relación con el trabajo producido: lo que uno se lleva, cuenta.

Lo que este enfoque no sustituye

Un editor en línea es una herramienta de sesión, no un entorno de trabajo. Sería deshonesto dejar creer que basta para formar a una persona desarrolladora.

A medida que la formación avanza, sus alumnos deben aprender a instalar un entorno, a usar un terminal, a gestionar dependencias y un control de versiones. Esas competencias forman parte del oficio, y aplazarlas demasiado hace la transición brutal.

El lugar adecuado del editor en línea está, por tanto, al principio y en los momentos colectivos: las primeras sesiones, las demostraciones, los ejercicios cortos, los grupos con equipos bloqueados. El resto del tiempo, la instalación se convierte en objeto de aprendizaje — en un momento elegido, no sufrido un lunes a las 9:15.