Non ho iniziato a parlare di Hacker-Style Learning per aggiungere un’altra sigla al catalogo delle metodologie didattiche. Cercavo un nome per un modo di insegnare nato dall’incontro tra la mia formazione informatica, gli anni di lavoro come ingegnere e l’esperienza quotidiana in classe.
L’informatica mi ha insegnato che una soluzione non verificata è soltanto un’ipotesi. Si costruisce una prima versione, la si mette alla prova, si scopre dove non regge e la si migliora. Quasi mai la prima soluzione è quella giusta, ma è spesso necessaria per capire quale potrebbe esserlo.
È qui che entrano in gioco gli hacker. Uso la parola “hacker” nel suo significato originario: una persona curiosa, che esplora i sistemi per comprenderli a fondo, usa con ingegno ciò che ha a disposizione e condivide quello che scopre. Un hacker non si accontenta di risposte preconfezionate e non si affeziona troppo alle proprie soluzioni, le mette alla prova.
Ho cercato di portare questo atteggiamento nell’apprendimento e nell’insegnamento. Il ciclo dell’Hacker-Style Learning, in fondo, è semplice:
domanda → ipotesi → artefatto → prova → feedback → nuova versione
Si parte da una domanda che valga la pena affrontare. Si formula una prima risposta e la si trasforma in qualcosa di osservabile. La si sottopone a test, domande, controesempi o al giudizio altrui. Poi si usa ciò che è emerso per produrre una versione migliore e riflettere sulle scelte compiute.
Con “artefatto” intendo qualsiasi cosa renda visibile il lavoro svolto: un programma, un testo, una presentazione, una mappa concettuale, un esperimento, una soluzione commentata o una spiegazione. Non deve essere necessariamente digitale, grande o spettacolare. Deve però poter essere mostrato, discusso e migliorato.
Non basta, infatti, “fare”. Si può fare molto senza capire quasi nulla. L’Hacker-Style Learning non sostituisce lo studio, le spiegazioni o gli esercizi con una successione di attività accattivanti. Usa invece la teoria precedentemente spiegata per comprendere un problema, correggere una debolezza o costruire una soluzione più solida.
Fare serve a capire; capire serve a fare meglio.
Per questo il passaggio decisivo è quasi sempre quello dalla prima alla seconda versione. La prima mostra il punto di partenza. La seconda rende visibile ciò che è stato appreso dopo un errore, un test, una domanda o un feedback. Un lavoro importante, quindi, non dovrebbe mai finire alla versione 1.
Anche l’errore va preso sul serio. La fretta, il copia e incolla da “amico chat” e l’assenza di controllo producono prevalentemente rumore. Un tentativo ragionato che fallisce, invece, genera informazione: mostra dove la comprensione è fragile e quale parte del lavoro deve essere ripensata.
La valutazione è forse il punto più delicato. Credo che debba poggiare su qualcosa di più solido dell’impressione finale. Non valuto soltanto il prodotto: considero anche le prove raccolte, le revisioni, le scelte compiute e la capacità di spiegare limiti ed errori. Non basta un elaborato con le relative correzioni. Il lavoro aumenta, sia per il docente sia per gli studenti, ma la valutazione restituisce un quadro più attendibile della capacità di utilizzare concretamente le conoscenze apprese.
Questo non significa abbassare gli standard, ma renderli più concreti. Un lavoro deve reggere alle domande, ai controesempi e alla prova dei fatti. Non basta dire di avere capito, di avere lavorato molto o di avere realizzato una bella presentazione: occorre mostrare che cosa è cambiato e perché.
Progetti come SweeterBytes hanno reso particolarmente visibile questo modo di lavorare, ma non sono l’Hacker-Style Learning. Lo stesso ciclo può svolgersi nella correzione ragionata di un esercizio, nella revisione di un testo o in una breve attività durante una lezione. Non servono sempre grandi progetti: servono domande sensate, qualcosa da mettere alla prova e la possibilità di migliorarlo.
Non considero quindi l’Hacker-Style Learning un metodo chiuso, né una ricetta da applicare sempre. È una sintesi ancora provvisoria del mio modo di intendere l’apprendimento. Deve continuare a cambiare insieme alla mia esperienza e agli studenti che incontro. Se diventasse un insieme di prescrizioni da difendere a ogni costo, sarebbe ben poco “hacker”.