Coding. Secondo atto: i difetti dell’inizio

Lo scopo di un laboratorio di coding non è la realizzazione di prodotti ben congegnati: è indurre i ragazzi a risolvere i problemi in modo diverso e aiutarli ad acquisire determinate abitudini (ma anche a perderne altre).

Per ottenere questo è essenziale l’esempio. E mi spiego, appunto, con un esempio.
I primi tempi che gestivo il laboratorio di creazione videogiochi della mia scuola avevo l’abitudine di mostrare volonterosamente ai ragazzi che chiedevano spiegazioni su come ottenere un risultato, la soluzione, magari condita da spiegazioni. Nefasto vizio, che mi procurò stanchezza e mal di testa.

Avete mai provato a rispondere a cinque o sei domande contemporaneamente? Si, certo, in classe: e già così è stancante. Ma in un laboratorio, nel quale la domanda non riguarda lo sperimentato campo della grammatica o della storia, ma (faccio un esempio) “perché quando colpisco l’ultimo marziano mi esce fuori la scritta che non trova più la variabile nemici?” , la cosa è diversa e più faticosa: perché quando si fa coding, specialmente con i ragazzi, è difficile trovare due errori uguali. Ogni problema è un caso a sé, e risolverne a cinque per volta, vi assicuro, è faticoso. Alla fine del primo anno, ero completamente a terra.

Il secondo anno chiesi l’aiuto di una collega che, bravissima insegnante della sua disciplina, era del tutto digiuna di coding. Il suo compito era semplicemente quello di gestire il traffico delle richieste: svolgeva, come mi disse con spirito, la funzione della macchinetta eliminacode. Il suo aiuto mi dava sollievo, ma, soprattutto, il tempo di riflettere.
Mi accorsi così che, se rispondevo ad una domanda con un’altra domanda, nella maggior parte dei casi i ragazzi finivano per trovare la risposta da soli. Ovviamente la domanda fornita come risposta doveva invitare alla riflessione e indicare la strada per arrivare alla soluzione, ma era sempre un risparmio di tempo e di energie. Avevo inoltre la sensazione che giovasse ai ragazzi almeno quanto giovava a me.
Era il primo passo sulla strada che porta a perdere cattive abitudini. La prima, l’avevo persa io. Ora toccava a loro…

In realtà quello di fare un elenco delle cattive abitudini da eliminare è più che altro un espediente per ricordare le buone abitudini da suscitare o potenziare. E’ utile perché, nei fatti, non ci si trova di fronte a processi mentali in evidente via di sviluppo, ma, assai più spesso, a carenze di vario genere. L’elenco di questi difetti è abbastanza lungo e credo che lo percorrerò per intero.

Comincerei coi difetti iniziali, quelli che si manifestano all’inizio del corso o, episodicamente, quando si introduce un nuovo argomento o un diverso modo di operare.
Il primo è quello dei ragazzi che iniziano senza concentrazione, senza cogliere la struttura, peraltro molto semplice, del programma (nel mio caso era GameMaker, oggi si parla di Scratch, ma il livello di difficoltà non è molto diverso). Si tratta spesso di ragazzi che sembrano andare a caso, che non sono abituati ad avere pazienza: vogliono risultati subito. Talvolta sono anche entusiasti, ma si stancano presto.
Mentirei se affermassi che ho imparato a individuarli a colpo d’occhio, e anche se dicessi di aver trovato il rimedio valido per tutti. Di sicuro, non giova affiancarli a compagni più esperti, che di solito, messi accanto a un confusionario, tendono a fare tutto loro.
Meglio dar loro un compagno altrettanto impaziente e assegnare un compito che li costringa a esplorare il programma con metodo, per esempio quello di compilare una piccola guida per i compagni su un argomento limitato e di non difficile esplorazione (io usavo di solito “spiega ai compagni le icone che servono per muovere un oggetto sullo schermo” e, all’obiezione “ma loro lo sanno già!” rispondevo che la guida era per i compagni dell’anno successivo, “per farli faticare di meno”). Trucchetti, d’accordo. Però funzionavano.

Un secondo difetto è la mancanza di una adatta terminologia; difetto meno frequente, per la verità – a me in undici anni di laboratorio sarà capitato meno di una decina di volte, ma è anche possibile che qualcuno me ne sia sfuggito.
Chi difetta di terminologia fatica di più a ricordare e a comunicare i suoi progetti, si orizzonta di meno, conosce meno le opzioni del programma (nonostante l’interfaccia grafico, una buona memoria verbale e una buona capacità di associazione icona – nome della funzione supportata, sono sempre utili).
La soluzione migliore è quella preventiva: usare sempre gli stessi termini sia nella spiegazione iniziale che nell’attività produttiva; ripeterli spesso, specialmente all’inizio, a costo di essere noioso. Inutile dire che non è sufficiente, perché qualche pesciolino scappa sempre dalla rete. In questo caso l’affiancamento ad un compagno più esperto e di scilinguagnolo più sciolto può essere utilissimo.

Un ulteriore difetto, per quanto riguarda le fasi che potremmo definire di input, è la tendenza ad imparare in un solo modo. È un difetto che rischia di vanificare i presuppposti dell’attività laboratoriale, che si basa proprio su una serie differente di input, viaggianti anche su canali sensoriali differenti. Le prime nozioni, inevitabilmente teoriche, vengono fornite con una trasmissione simile alla lezione frontale (anche se arricchita da esempi e da esercitazioni); poi la discussione, il lavoro su un progetto di propria scelta, la realizzazione, la prova al computer, fanno il resto. La pratica, più o meno guidata o facilitata, è quella che da più informazioni.
Fra i ragazzi c’è chi tende a imparare più o meno mnemonicamente l’uso delle diverse icone sin dall’inizio (è meno difficile e più diffuso di quanto non si pensi, si tratta pur sempre di associare immagini schematiche a concetti semplici) e sembra poi non impegnarsi; c’è al contrario, chi non segue all’inizio, ma prende dagli altri le diverse tecniche, applicandole con maggiore o minore proprietà; che anche chi non prende esempio dal lavoro altrui, ma si accanisce provando e riprovando da solo finché non è riuscito (s’intende, se ci riesce!) ad ottenere ciò che voleva.
Si dirà che questo fa parte dei diversi stili di apprendimento quando non dei diversi tipi di intelligenza: d’accordo solo fino ad un certo punto, cioè finché questo atteggiamento si limita ad una tendenza: ma quando tale tendenza tende a prevalere e a diventare totalizzante, diviene chiaramente un difetto.

Rimedi buoni per tutti i casi, qui, come altrove, non ne ho trovati; in realtà si tratta pur sempre di supportare il momento debole facilitandolo con un’azione personale da decidere volta per volta. Per questo trovo utili i laboratori che non superano i dieci – dodici partecipanti e assai di meno quelli più affollati: perché solo i primi danno il tempo di porre rimedio con gradualità ed efficacia a certi difetti.

Scritto da: Paolo Freschi