BINARI PER L'INSEGNAMENTO

I calcoli

Nei quattro mesi successivi ci siamo incontrati ogni due settimane e, passo dopo passo, abbiamo scoperto il fantastico mondo di Ruby et al. Il corso riguardava il linguaggio Ruby, Ruby on Rails, Javascript e alcuni strumenti popolari per applicazioni RoR come Devise, Pundit, Sidekiq o Carriewave.

Ogni studente aveva anche un mentore, che aveva il compito di motivare gli studenti e di controllare il loro lavoro tra un incontro e l'altro.

Il piano d'attacco

Come insegnante, sono arrivato preparato con 3 anni di esperienza con Ruby on Rails, 10 anni di esperienza con la programmazione in generale e alcune presentazioni con problemi ed esercizi da svolgere.

A parte un breve corso di gestione di Linux che avevo fatto in precedenza, non avevo alcuna esperienza di insegnamento. Per quanto riguarda gli studenti, sapevo solo che sarebbero stati dieci e che provenivano da ambienti molto diversi: per alcuni di loro si trattava del primo approccio alla programmazione, mentre altri avevano cercato di imparare C o Ruby da soli prima di iscriversi al corso.

Ho deciso di prendere due risoluzioni: sarò paziente e spiegherò tutto se necessario (niente "ne abbiamo già parlato"). Il primo proposito ha superato la prova del tempo, ma il secondo - ovviamente - no. Ho deciso di non fare alcuna preparazione particolare sulle cose che avrei insegnato - lavoro con Ruby/Rails ogni giorno e mi sento abbastanza sicuro delle mie competenze in quell'area. Al massimo ho letto le presentazioni che avevo.

La sfida

Una delle prime cose che mi sono state assolutamente chiare subito dopo l'inizio del corso è che non si può spiegare tutto. È una consapevolezza molto triste per chi, come me, ama scavare e scoprire come funzionano le cose, ma nel tempo limitato di un incontro si possono insegnare solo tante cose che possono essere ricordate dagli studenti. Si scopre che si può essere un ottimo programmatore Ruby senza sapere esattamente come vengono rappresentati gli array in memoria o come funziona Devise.

Le lezioni si svolgevano il sabato e la domenica dalle 9.00 alle 17.00. È importante rendersi conto che l'insegnamento è un lavoro piuttosto faticoso: oltre a spiegare il materiale, bisogna essere sempre pronti a rispondere a domande correlate (o meno) e a risolvere i vari problemi degli studenti.

Il caffè è il vostro amico, ma la cosa più importante è la già citata pazienza. Per le persone che non hanno mai fatto coding, i concetti che sono ovvi per i programmatori - come i cicli, i tipi o persino le variabili - devono essere appresi e non è un processo immediato. Se programmate da XX anni, considerate la matematica facile e potete elencare tutti i paradigmi di programmazione conosciuti nel bel mezzo di una notte, potrebbe essere difficile mettersi nei panni di una persona che non sa bene da che parte del segno di uguale va il nome della variabile. Ma è fondamentale farlo. Concetti di base come le variabili, i cicli o gli array diventano così naturali che è difficile capire come qualcuno non li capisca subito, ma sono più difficili di quanto sembrino a "noi programmatori".

Un'ulteriore difficoltà, soprattutto all'inizio del corso, è stata quella di spiegare questi concetti in modo che fossero ben compresi. A mio parere, non è possibile imparare Rails senza imparare Ruby - anche se so che alcuni potrebbero sostenere che non è così. È vero che Rails ha i suoi schemi e molte cose possono essere ricordate piuttosto che imparate all'inizio. Tuttavia, credo che per diventare uno sviluppatore Rails consapevole, sia indispensabile una discreta conoscenza di Ruby, OOP o SQL. Insegnare a programmare è molto diverso dall'insegnare Rails: mentre con Rails ci si può aspettare che molte cose vengano semplicemente accettate o credute (all'inizio nessuno ha bisogno di sapere come funzionano i callback - solo cosa possono fare), i concetti di programmazione dovrebbero essere spiegati in modo più dettagliato.

Impegnare la forza

Quindi, come si fa?

Con pazienza.

Probabilmente sembra che mi ripeta sempre, ma non potrò mai sottolineare abbastanza quanto sia importante la pazienza. Anche i miei studenti più motivati hanno commesso qualche errore di sintassi qua e là: fa parte del normale processo di apprendimento e l'insegnante non deve fare altro che mostrare qual è l'errore e come risolverlo. Col tempo, impareranno a correggerli da soli, ma ci vorrà ben più di uno o due errori.

Un'altra cosa da notare è che Ruby non è così facile come sembra. Se avete iniziato a imparare Ruby con una conoscenza di C/Java/Python, probabilmente tutto vi sembrerà così pulito e semplice. Provate però a pensarci e ve ne accorgerete:

1. Perché le parentesi? Dovrei usarle? Non dovrei?
2. Che cos'è sé cosa? A volte devo usarlo (es. attr_writer – self.variable = ...), a volte non lo faccio (lettore_attr – variabile) e a volte non ci riesco! (private def some_method – self.some_method lancerà un errore)
3. Blocchi. Scommetto che anche alcuni programmatori esperti (di diversi linguaggi) avrebbero bisogno di un attimo in più del previsto per comprendere #inject

Oltre alla semplice correzione degli errori, c'è il problema di trasferire la vostra comprensione delle cose ai vostri studenti. Per farlo, è necessaria una grande flessibilità. Ad alcuni studenti bastava che Array fosse un elenco ordinato di elementi. Altri avevano bisogno di un'analogia più visiva, come uno scaffale con posti numerati su cui mettere le cose. Mi sono ritrovata a spiegare le stesse cose più volte in modi diversi, un esercizio piuttosto impegnativo!

Ma, come ho detto prima, non si può spiegare tutto. Quando spiegavo le relazioni in Rails, era più che altro un "ecco come si fa, e permette di fare questo e quello. Se volete questo, è fantastico". Fortunatamente nessuno mi ha chiesto come funziona: non credo che gli sviluppatori junior debbano conoscere le riflessioni.

Posizionamento situazionale

A causa del formato del nostro corso (incontri ogni due fine settimana e lunghe pause) abbiamo dovuto garantire che i periodi tra questi fine settimana siano produttivi per i nostri studenti: senza la loro pratica in quel periodo il corso non funzionerebbe affatto.

Alcuni dei miei colleghi hanno accettato di fare da tutor agli studenti del corso. Il lavoro dei mentori consisteva nel verificare gli esercizi assegnati durante gli incontri del fine settimana e nell'aiutare a risolvere i problemi che si presentavano durante il completamento degli stessi. Gli studenti comunicavano con i mentori tramite Slack.

Ho fatto da tutor a due dei miei studenti. È stata una forma di insegnamento molto diversa e piena di insidie. Una cosa che ho capito un po' troppo tardi è che un buon programmatore deve essere indipendente: dovrebbe almeno cercare di risolvere i problemi da solo prima di chiedere aiuto. Ed essere sempre disponibile su Slack non solo mi portava via molto tempo, ma non ispirava nemmeno tale indipendenza.

Non fraintendetemi: molte delle domande che mi sono state poste come mentore erano valide e rispondere ad esse significava ampliare la conoscenza degli studenti. Tuttavia, è molto facile entrare in modalità "insegnante" e spiegare di nuovo tutti gli argomenti delle riunioni del fine settimana. Dal punto di vista odierno, credo che il ruolo di un mentore sia quello di fornire una panoramica, di fornire link utili e di porre alcune domande che possano aiutare a trovare la soluzione. Occasionalmente si possono dare spiegazioni, ma non dovrebbero essere la maggior parte.

L'uso dell'intelligenza

Ogni studente è diverso. Una delle difficoltà maggiori è stata quella di adattare il ritmo del corso per adattarlo al meglio a tutti gli studenti. A causa dei diversi background e del livello generale di facilità nell'accettare nuove idee tra gli studenti, è un compito quasi impossibile.

Il nostro calendario era di 9 incontri - 2 giorni per 8 ore, il che significava 144 ore per passare da 0 a Ruby-hero. Era fondamentale svolgere l'intero programma in questo lasso di tempo, il che di per sé imponeva un ritmo piuttosto veloce. I primi tre incontri erano tutti su Ruby, poi un incontro per SQL, poi RoR e un incontro per JS nel mezzo.

Come insegnante, ho sempre dovuto sapere chi più o meno ha capito parte del materiale che stavo presentando. A volte bastava chiedere se era stato capito, altre volte facevo dei piccoli test. Ad esempio, ho chiesto a tutti i miei studenti di inviarmi le loro definizioni dei concetti di Ruby, come ad esempio classe, sé, metodo, variabile ecc. su Slack. Se qualche questione era particolarmente poco chiara, tornavo indietro e cercavo di spiegarla di nuovo.

Illusione e realtà

In sintesi, l'insegnamento è stato un'impresa ancora più difficile di quanto pensassi. Può anche essere molto gratificante. Tuttavia, è un lavoro duro e i suoi effetti non dipendono solo dall'insegnante: lo sforzo dello studente è ancora più importante per il suo apprendimento. Questo rende l'insegnamento molto diverso dalla programmazione, in cui di solito si può essere proprietari di tutti i successi e gli insuccessi. È importante ricordare questa differenza.

Inoltre, vi costringe a riflettere su questioni a cui di solito non pensate: spiegare le cose vi permette di capirle meglio. In questo modo, l'insegnamento può anche rendere un programmatore migliore.