Far scrivere codice ai partecipanti senza installare nulla

Il quarto d ora perso all'inizio di ogni lezione

In una giornata di corso, installare un ambiente di sviluppo costa raramente meno di venti minuti. E costa soprattutto attenzione: mentre aiuti tre persone, le altre aspettano, e il gruppo si disperde prima ancora di aver scritto una riga.

Il problema si ripete a ogni sessione, e peggiora in tre situazioni molto comuni:

• Le postazioni bloccate. In un ente di formazione o in azienda, il partecipante non è amministratore della propria macchina. Nessuna installazione è possibile senza passare dall'informatica.
• L'hardware eterogeneo. Tre versioni di Windows, due Mac, un portatile con Linux: la stessa procedura non funziona mai su tutti.
• I corsi brevi. Su mezza giornata, venti minuti di installazione sono quasi un decimo del tempo totale.

Un editor che vive nel browser elimina questa fase: il partecipante apre un link, o inquadra un codice, e scrive.

Cosa gira in un browser, e cosa non ci gira

Bisogna essere chiari sul perimetro, perché è lì che nascono le delusioni. Un browser esegue molto bene le basi di un linguaggio, e per niente quello che riguarda il sistema.

Quello che funziona copre l'essenziale di un corso introduttivo: output, input da tastiera, condizioni, cicli, funzioni, liste e dizionari, gestione degli errori, e le prime nozioni di oggetti. In pratica, tutto il programma dei primi tre o quattro giorni di un corso Python.

Quello che non funziona si riassume in ciò che esce dalla sandbox: le interfacce grafiche, la lettura e la scrittura di file, le chiamate di rete, e le librerie esterne da installare. Un programma che disegna una finestra o che legge un file CSV ha bisogno di un ambiente installato.

Questo limite non è un difetto dello strumento: è quello che garantisce che il programma di un partecipante non tocchi nient'altro che la propria pagina.

Mostrare, poi lasciar fare

Una lezione di codice riuscita alterna due tempi, e il secondo arriva prima di quanto si pensi. Finché il formatore digita da solo, il gruppo si sfila: i partecipanti ricopiano senza pensare, o aspettano la fine per cominciare.

La disposizione che funziona meglio dà le due cose insieme: ognuno ha il proprio editor e lavora dentro, vedendo il tuo accanto, in diretta. Tu scrivi un esempio, compare da loro; si ispirano, adattano, sbagliano, ricominciano — senza dover scegliere fra guardare e fare.

Tre abitudini rendono questo dispositivo più efficace:

• Scrivi l'esempio davanti a loro, compresi i tuoi errori di battitura. Vedere un formatore correggere un errore di indentazione vale più di un codice perfetto apparso d'un colpo.
• Lascia che nascondano il tuo schermo quando vogliono concentrarsi. Lo scopo non è che guardino te, è che scrivano.
• Riprendi il comando nei momenti chiave. Un pulsante che rimette tutti in sola lettura vale più che chiedere tre volte silenzio.

Il ciclo infinito, e le altre trappole del principiante

Il primo while scritto male arriva sempre, spesso nel primo quarto d'ora. Su una postazione normale blocca la macchina, il partecipante si spaventa, e tu perdi il filo della lezione per tre minuti.

Un ambiente pensato per l'apprendimento interrompe questi programmi da solo, dopo qualche secondo, con un messaggio che spiega cosa è successo. Dillo ai tuoi partecipanti dall'inizio: sapere che non possono rompere niente li rende molto più audaci, e l'audacia è esattamente quello che si cerca a questo stadio.

Le altre trappole classiche si trattano più con la didattica che con lo strumento:

• Il messaggio di errore che non si legge. Prenditi il tempo di leggere un errore a voce alta, per intero, la prima volta. Il riflesso si prende in fretta.
• La confusione fra stampare e restituire. Merita un esercizio tutto suo, presto nella progressione.
• Il copia e incolla senza capire. È l'argomento più forte per dare a ciascuno il proprio editor: si copia meno facilmente quando bisogna far girare il proprio programma.

Recuperare il lavoro di ciascuno

Una lezione di codice non produce niente di durevole se il lavoro sparisce alla chiusura della scheda. Ed è proprio quello che succede con la maggior parte delle sandbox online, dove il codice vive nel browser e in nessun altro posto.

Due usi giustificano da soli il recupero dei file. Primo, la correzione differita: rileggere con calma quello che ciascuno ha prodotto dice molto di più sugli apprendimenti del gruppo di un giro per l'aula. Secondo, la continuità: riprendere la settimana dopo dove il partecipante si era fermato, invece di ricominciare tutto.

In concreto, ogni partecipante deve poter scaricare il proprio file con l'estensione giusta, e il formatore recuperare l'insieme del gruppo in una volta. È un dettaglio d'uso che cambia il rapporto con il lavoro prodotto: quello che si porta via conta.

Quello che questo approccio non sostituisce

Un editor online è uno strumento di lezione, non un ambiente di lavoro. Sarebbe disonesto far credere che basti a formare uno sviluppatore.

Appena il corso avanza, i tuoi partecipanti devono imparare a installare un ambiente, a usare un terminale, a gestire le dipendenze e un sistema di controllo di versione. Queste competenze fanno parte del mestiere, e rinviarle troppo rende la transizione brusca.

Il posto giusto dell'editor online sta dunque all'inizio e nei momenti collettivi: le prime lezioni, le dimostrazioni, gli esercizi brevi, i gruppi su postazioni bloccate. Il resto del tempo, l'installazione diventa essa stessa un oggetto di apprendimento — ma in un momento scelto, non subito un lunedì mattina alle 9.15.