Cosa serve per diventare mentore?
Posso fare da mentore per un linguaggio che sto ancora imparando?
Posso fare da mentore per più di un linguaggio?
Devo provare a fare da mentore per ogni soluzione in coda?
E se una soluzione è in coda da giorni, persino settimane?
E se non ho nulla da suggerire su una soluzione?
Devo fare da mentore per un esercizio che non ho mai risolto?
Devo fare da mentore per un esercizio che ho risolto, ma in un altro linguaggio?
Devo per forza fare da mentore per una soluzione dopo averla vista?
E se lo studente non capisce dopo che ho spiegato qualcosa più volte?
Come rispondo se lo studente si mette sulla difensiva per il mio suggerimento (o i miei suggerimenti)?
Lo studente deve avere l'ultima parola, anche se penso che si sbagli?
Come posso formulare al meglio un suggerimento?
Devo imporre convenzioni di formattazione, commenti e denominazione?
Cosa serve per diventare mentore?
Non devi essere un esperto di un linguaggio per farne da mentore.
Ti basta essere un po' meno principiante della persona a cui fai da mentore.
Se in una soluzione c'è qualcosa che secondo te si potrebbe fare in modo diverso, puoi suggerirlo.
Non deve per forza essere un modo migliore, basta un'alternativa idiomatica.
Così la scelta se usare o meno il suggerimento resta allo studente, ma almeno ha più opzioni tra cui scegliere.
Posso fare da mentore per un linguaggio che sto ancora imparando?
Idealmente, non si smette mai di imparare un linguaggio, nemmeno uno che già conosci.
Alcuni linguaggi pubblicano una versione aggiornata ogni poche settimane o mesi.
Non solo può esserci qualche nuova funzionalità del linguaggio da imparare, ma potrebbero esserci anche funzionalità esistenti che non conosci.
A volte uno studente potrebbe usare una funzionalità, e sarà la prima volta che la vedi.
Quindi il mentoring può essere un buon modo per imparare di più su un linguaggio.
Posso fare da mentore per più di un linguaggio?
Puoi fare da mentore per tutti i linguaggi con cui ti senti a tuo agio.
Va bene fare da mentore per più linguaggi in cui ti senti sicuro, oltre che per un linguaggio che stai ancora imparando.
Devo provare a fare da mentore per ogni soluzione in coda?
Se in quel momento non ti viene in mente nulla di sostanziale o costruttivo da dire su una soluzione, per lo studente potrebbe essere meglio se lasci la richiesta di mentoring a un altro mentore, anche se dovrà aspettare più a lungo una risposta.
E se una soluzione è in coda da giorni, persino settimane?
Se lo studente ha fatto una domanda specifica a cui non sai rispondere, potresti comunque volerla lasciare a qualcuno che possa rispondere alla sua domanda.
Altrimenti, la soluzione potrebbe riguardare un esercizio che è stato difficile per te, che potresti non aver risolto, oppure aver risolto ma con la sensazione di non averlo fatto bene.
In quel caso, potresti dare un'occhiata alla soluzione per vedere se c'è qualcosa che puoi imparare.
Se è così, puoi ringraziare lo studente per quello che hai imparato di preciso dalla sua soluzione.
Oppure potresti chiedere allo studente di spiegarti la sua soluzione.
È una specie di «mentoring al contrario», ma ad alcuni studenti fa piacere spiegare la propria soluzione se glielo si chiede con educazione e rispetto.
Potresti poi chiedere se ha considerato un altro approccio e perché ha scelto proprio quello.
Oppure potresti ancora non capire la soluzione nel complesso, ma vedere alcune cose che puoi affrontare.
Per esempio, potresti far notare di considerare l'uso di nomi significativi per i parametri della funzione, se ha usato solo n o m.
Se non ti senti a tuo agio a fare nessuna di queste cose, va bene lasciare la richiesta senza risposta.
Il mentoring è volontario.
Il fatto che tu faccia da mentore per un linguaggio non significa che devi farlo per ogni esercizio di quel linguaggio.
E se non ho nulla da suggerire su una soluzione?
Va bene dire cosa ti piace di una soluzione.
Anzi, dire cosa ti piace di preciso di una soluzione è un buon modo per iniziare qualsiasi scambio di mentoring.
Dopo averlo fatto, se non hai suggerimenti su modi alternativi di affrontare l'esercizio, va benissimo dire semplicemente allo studente: «Ben fatto!»
Se lo studente ha inviato più di un'iterazione, potresti riuscire a far notare in che modo l'iterazione più recente è un miglioramento.
Devo fare da mentore per un esercizio che non ho mai risolto?
A volte, guardare la soluzione di uno studente ti ispirerà a risolvere l'esercizio da solo, soprattutto se l'approccio usato nella soluzione fa sembrare l'esercizio più semplice di altri che avevi già considerato.
Dopo aver risolto l'esercizio, se la richiesta di mentoring che ti ha ispirato non è più disponibile, sarai almeno pronto per la prossima volta.
Devo fare da mentore per un esercizio che ho risolto, ma in un altro linguaggio?
Dato che ciò che è idiomatico in un linguaggio potrebbe non esserlo in un altro, probabilmente è meglio aver risolto l'esercizio nel linguaggio per cui fai da mentore.
Se le soluzioni nei due linguaggi sono molto simili, e conosci entrambi i linguaggi abbastanza bene da sapere cosa è idiomatico in ciascuno, non dovrebbe volerci molto per trasporre una soluzione da un linguaggio all'altro.
Se la richiesta di mentoring non è più disponibile dopo aver trasposto la soluzione, sarai almeno pronto per la prossima volta.
Devo per forza fare da mentore per una soluzione dopo averla vista?
Potresti guardare una soluzione e renderti conto che non vuoi farne da mentore per diversi motivi, tra cui:
- Lo studente potrebbe aver fatto una domanda a cui non sai rispondere.
- Il codice potrebbe essere così verboso e/o confuso che non sai da dove iniziare a commentarlo.
- Il codice potrebbe indicare che lo studente è un principiante assoluto, che avrà bisogno di molta guida di base per cui non hai né il tempo né la pazienza.
- Il commento dello studente potrebbe far capire che potrebbe essere spiacevole o faticoso interagire con lui.
Niente ti obbliga a cliccare il pulsante "Inizia il mentoring" se pensi che quella particolare richiesta di mentoring non faccia per te.
E se lo studente non capisce dopo che ho spiegato qualcosa più volte?
Ci saranno volte in cui uno studente sembrerà quasi ostinarsi a non capire le tue spiegazioni.
Se senti di aver esaurito tutti i modi che conosci per spiegare qualcosa, potresti decidere di concludere la discussione suggerendo allo studente di inviare di nuovo la sua richiesta di mentoring, così che possa essere gestita da un altro mentore che magari riuscirà meglio a spiegare i punti difficili.
Come rispondo se lo studente si mette sulla difensiva per il mio suggerimento (o i miei suggerimenti)?
A volte uno studente dirà che ha usato un approccio più laborioso del necessario per imparare di più su una funzionalità del linguaggio, anche se quella funzionalità non è la più adatta all'esercizio.
Dato che Exercism è una piattaforma per imparare e non un sito di programmazione competitiva, è una ragione giustificabile per non usare l'approccio più elegante o efficiente.
Potresti dare qualche suggerimento su come ha usato il suo approccio, se vedi che avrebbe potuto implementarlo in modo più idiomatico.
In ogni caso, puoi suggerire di inviare un'altra iterazione in base al feedback, oppure di concludere la discussione per liberare uno slot di mentoring.
Uno studente potrebbe seguire un paradigma di programmazione che non è il più adatto al linguaggio o all'esercizio.
Per esempio, potrebbe voler usare sempre il paradigma orientato agli oggetti e frammentare una soluzione relativamente semplice e lineare in una piccola esplosione di classi con un flusso di controllo labirintico attraverso molti metodi.
Nella misura in cui lo studente segue il paradigma in modo dogmatico, di solito è inutile cercare di convincerlo a usare un approccio diverso.
Puoi provarci, e potrebbe rispondere al tuo suggerimento, ma se lo studente si impunta, forse è meglio andare avanti.
Lo studente potrebbe rifiutare del tutto un suggerimento.
Per esempio, potresti suggerire di usare reduce invece di map e join, dato che reduce fa una sola iterazione invece di una per map e un'altra per join.
Ma lo studente potrebbe rifiutarlo, perché trova map e join più leggibili.
Va bene essere d'accordo con lo studente sul fatto che map e join possono essere più leggibili di reduce.
Puoi suggerire che potrebbe prendere più confidenza con reduce dopo un po' di tempo per abituarsi, e che non c'è nulla di sbagliato a usare map e join.
Va bene essere d'accordo con uno studente nella misura in cui ha ragione, ed è anche giusto provare a correggere qualsiasi idea sbagliata o esagerazione che potrebbe aver espresso.
Lo studente deve avere l'ultima parola, anche se penso che si sbagli?
Per esempio, potresti suggerire a uno studente di non usare numeri magici come 60 e 24 quando risolve l'esercizio Clock, ma di definirli come costanti con nomi significativi.
Lo studente potrebbe rispondere che, dato il contesto, è ovvio cosa rappresentano 60 e 24.
Hai fatto il tuo suggerimento e lo studente l'ha respinto.
Forse non c'è nulla da guadagnare, e magari solo della buona volontà da perdere, nel discuterne.
Per suggerire qualcosa come alternativa che non deve per forza essere migliore, potresti introdurla con «Un altro approccio potrebbe essere...».
Per esempio: «Un altro approccio potrebbe essere usare every con includes».
Se presenti una funzionalità del linguaggio che lo studente non ha usato nella soluzione (come every o includes), sarebbe utile linkare una documentazione che la spieghi.
Un altro modo per introdurre un suggerimento potrebbe essere «Forse potresti considerare...».
Per esempio: «Forse potresti considerare di usare la sintassi spread invece di split()».
Se sei convinto che lo studente debba usare un'alternativa, potresti togliere il «Forse» e iniziare con «Considera...».
Per esempio: «Considera di usare un argomento predefinito».
Per una serie di suggerimenti, potresti voler variare il modo in cui ciascuno viene introdotto.
Gli elenchi puntati sono un modo efficace per elencare ciò che ti piace di una soluzione.
Possono risultare meno amichevoli quando elencano suggerimenti.
Offrire i suggerimenti in modo informale e colloquiale può renderli meno difficili da considerare e accettare per lo studente.
Una parola che probabilmente è meglio non usare quando si offre un suggerimento è «dovresti».
Per esempio: «Dovresti usare un argomento predefinito».
Usare parole come «dovresti» o «devi» può risultare autoritario.
È probabile che i mentori non siano d'accordo su quando e con quanta forza affrontare questioni come la formattazione del codice, i commenti e le convenzioni di denominazione.
Da un lato, potresti voler far riflettere lo studente su queste cose fin da subito con esercizi come Two Fer, prima che inizi a sviluppare cattive abitudini.
Oppure potresti non voler intimidire un principiante con tutte queste considerazioni di opportunità.
Dall'altro lato, gli studenti che affrontano gli esercizi più avanzati potrebbero già conoscere le convenzioni, ma scegliere di ignorarle mentre si concentrano sul compito da svolgere.
Potrebbero infastidirsi per un'attenzione continua alle convenzioni, vista come pedanteria.
Se un linguaggio ha uno o più formatter o linter, può essere utile scegliere un esercizio in cui presentarli.
Altrimenti, se la violazione di una particolare convenzione è davvero grave, potresti volerla far notare ovunque si verifichi.
Dove i mentori potrebbero divergere è su cosa si possa considerare «davvero grave».
