Iniziazione al codice

Iniziare la relazione mentore-protetto#section1

Quando cercate la persona a cui fare da mentore, il vostro protetto, cercate “qualcuno che abbia da insegnarvi qualcosa ma ancora non lo sa“, come mi ha recentemente suggerito un mio amico che fa da mentore in RailsBridge.

Questa cosa per me ha due significati. Il primo è di rimanere aperti ad una serie di tipi di personalità. Cercate un possibile protetto che non sia simile a voi. Potreste cadere nella tentazione di confrontare i junior con il voi di tre anni fa e saltare alle conclusioni, ma la mentorship è una strada a due corsie, non è fare lezione. In effetti, non riguarda nemmeno il passaggio della vostra conoscenza ad un’altra persona. Riguarda raggiungere un accordo comune per migliorare entrambe in quello che fate. Imparerete di più a vicenda se avete modi diversi di pensare.

Il secondo è di scegliere qualcuno da cui volete imparare. Se il vostro protetto non è il tipo di persona con cui vi piacerebbe partecipare ad una battaglia di codice, non andrete da nessuna parte. La prima qualità da evitare è l’arroganza: una persona arrogante avrà un tasso di crescita più lento rispetto a chi accetta di buon cuore del feedback.

Dal momento che le dinamiche del team sono in costante mutazione, potreste non stabilire spesso delle relazioni mentore-protetto con persone del vostro team. Questo non significa che non troverete opportunità per fare da mentore. Cercate piccoli momenti per intervenire e dare aiuto: sarete visti come leader e cominceranno a materializzarsi più opportunità di mentoring.

La chiave è nell’agilità#section2

La chiave per essere un buon mentore è un concetto con cui avete già familiarità, dal momento che è cruciale per lo sviluppo di software di buona qualità e per apprendere nuove informazioni efficacemente. La chiave è l’agilità.

Ovviamente, “agile“ è diventato un termine con più significati e tende più a confondere le idee che a chiarirle. Dave Thomas, uno dei firmatari originali dell’Agile Manifesto, in un blog post del 2014 ha ammesso questa confusione, poi ci ha ricordato come fare tutto in maniera agile:

• Scopri dove sei
• Fai un piccolo passo verso il tuo obiettivo
• Aggiusta la tua comprensione basandoti sui tuoi obiettivi
• Ripeti

O, nei termini della Scrum Guide: “ispeziona e adegua”. L’ispezione e l’adeguamento sono due fondamentali dell’essere un buon mentore: se non vi prendete del tempo per controllare il vostro protetto e ascoltarne i problemi, dubbi e successi, allora non avrete una metrica per i risultati.

Utilizzare l’agile come mentore richiede sensibilità, creatività e solide capacità comunicative. Richiede anche la lungimiranza di capire a cosa aspira davvero il vostro protetto e il senno di poi per vedere dove è già arrivato il vostro protetto.

Per stabilire un framework per misurare il progresso del vostro protetto, considerate tre fasi attraversate sotto qualche forma da tutti i nuovi membri di un team. La prima fase è la totale mancanza di familiarità e una costante scoperta, la seconda è un periodo di transizione con una chiara traiettoria del progresso e la terza è una competenza auto-motivata. In tutte e tre queste fasi ricordatevi che l’agility rimane il vostro strumento più vitale.

Fase 1: un po’ di rispetto#section3

Il primissimo giorno, fate una chiacchierata con il vostro protetto, il cui obiettivo per voi è scoprire esattamente quale sia al momento il suo esatto livello e il tipo di esperienza che ha. Questa conversazione ha un doppio scopo: primo, stabilisce un discorso a due vie, una relazione comunicativa che sosterrà il vostro approccio agile alla mentorship. Secondo, vi darà una base per decidere cosa assegnare per prima cosa al vostro protetto. Cominciare con una conversazione diretta può prevenire un incredibile quantità di confusione e tempo perso.

In questa fase, è obbligatoria la programmazione in coppia. È di gran lunga il miglior metodo per informare di tutto un nuovo sviluppatore, specialmente se avete una code base estesa o poco chiara. Un recente articolo di Sarah Mei dice delle cose eccellenti su come appaiare efficacemente, ma il punto saliente è: non toccate (molto) la tastiera. Fate domande e rispondete alle domande con altre domande. Più sarete vicini al livello di esperienza del vostro protetto, più sarà difficile usare l’approccio di chi si siede e osserva, dal momento che spesso dovrete capire delle cose anche voi. Tuttavia, dovete resistere ogni volta che sentite l’urgenza di prendere il comando e risolvere il problema. Il vostro protetto imparerà molto più efficacemente con lo stile Socratico.

Tenete a mente, però, che non siete solo una guida tecnica. All’inizio, abbastanza sorprendentemente, l’apprendimento di esperienza tecnica non sarà probabilmente la prima cosa che ha in mente un junior developer. Dovranno affrontare delle questioni sociali e delle sfumature di processo che tutti gli altri danno già per scontate. Eliminate tutta la confusione riguardante le cose che girano attorno al lavoro così che il vostro protetto non abbia ostacoli nell’esplorazione del lavoro stesso.

Per quanto non vediate l’ora di far andare avanti le cose, assicuratevi anche di essere onesti riguardo ai vostri limiti. Considerate frasi come “Nemmeno io capisco questa cosa“, “Ho bisogno di una pausa“, “Non riesco ad aiutarti adesso, prova a chiedere a Oleg“. Tutte queste possono essere musica per le orecchie di un principiante. Più sarete onesti su quando e come gli altri possono aiutare, più le aspettative del vostro protetto saranno realistiche. E prospettive realistiche portano a buone decisioni.

Fase 2: sfida accettata#section4

Avendo stabilito una solida relazione comunicativa, il vostro protetto si sposterà rapidamente oltre la fase verde. Saprete che è nella Fase 2 quando riuscirà a capire facilmente cosa deve essere fatto su un ticket, anche se non sanno al 100% come farlo. Questo significa che comincia a sentirsi a suo agio ed è anche il momento in cui le cose si fanno davvero divertenti. È ora di aggiungere una sfida al mix.

Qualunque cosa facciate, non assegnate semplicemente al vostro protetto qualsiasi cosa si presenta. Al contrario, ispezionate, adattate e selezionate incarichi che si basano su quello che è già stato fatto prima dal vostro protetto.Se possibile, cercate di raccontare una storia con i compiti che gli assegnate. Qualcosa nel ticket successivo potrebbe elaborare o rafforzare un concetto da un ticket precedente. Oppure potreste raccontare la storia di una singola richiesta, dalla UI al database e ritorno.

Se dovete assegnare qualcosa al vostro protetto che sembra relativamente facile, usatela come opportunità per allenarlo ad osservare il codice con un occhio pessimista. Cosa succederebbe con un input null? Questo apre la strada ad alcuni attacchi? Avresti potuto fare il refactoring di un altro componente per rendere questo cambiamento più semplice? I tuoi test coprono tutto il nuovo codice? Anche se il vostro protetto decide che il codice è ineccepibile (e non lo è mai), eserciterà il suo muscolo della programmazione cercando di rispondere a queste domande.

Mentre ponete delle sfide al vostro protetto ogni volta che potete, non dimenticatevi di sfruttare ogni occasione per incoraggiarlo. Un task che sembra routine potrebbe sembrare un trionfo al vostro protetto, quindi, quando finiscono qualcosa, congratulatevi con lui e non sottostimate mai il potere di un semplice “Ben fatto!“.

Fase 3: il gioco dell’iniziazione#section5

Il fine ultimo consiste nel trasformare il vostro protetto in un membro produttivo che contribuisce alla pari al vostro team. Con il tempo e con la pratica, ci arriverà, ma perché aspettare? C’è un modo migliore e più veloce. Quando il vostro protetto è pronto, potete aiutare la transizione con un tool vecchio come l’umanità: l’iniziazione.

Non importa chi siete e da dove venite, avete sicuramente familiarità con la narrativa legata all’iniziazione. Joseph Campbell l’ha identificata come uno degli elementi più importanti della saga dell’eroe, il pattern sottostante condiviso dalle storie epiche di tutto il mondo, dall’antica mitologia ai pilastri della cultura pop come Star Wars e Fight Club, le storie di iniziazione hanno preso infite forme. Il framework, tuttavia, è sempre lo stesso: una straziante traversia che, se si sopravvive, dona all’iniziato un nuovo e più alto livello di consapevolezza.

L’iniziazione non è solo per gli eroi epici. È uno strumento potente di trasformazione in qualunque contesto. Quando sentite che il vostro protetto è pronto per fare un gran salto, assegnategli un task che sembra un po’ troppo complesso, un po’ troppo al di là della portata di quello che è stato fatto fino a quel momento e sufficientemente difficile per accelerarne la transizione a membro del team indipendente e alla pari.

Un’iniziazione efficace per un software developer dovrebbe avere tre qualità:

1. Non dovrebbe essere banale per qualcuno che ha qualche anno in più di esperienza.
2. Richiede comunicazione con le persone di livello senior. Idealmente, il protetto guadagnerà della conoscenza dei fattori che entrano in gioco in una decisione tecnica di alto livello. Rivedere un componente della UI, modificare la vostra architettura di deploy o creare a mano una nuova strategia di caching sono tutti ottimi candidati per questo tipo di esperienza.
3. Ha un valore dimostrabile, preferibilmente quantificabile. Potrebbe essere una nuova feature del front-end o potrebbe essere un grafico che mostra un decremento del tempo di caricamento della pagina, ma idealmente, il vostro protetto sarà in grado di indicare una rappresentazione visuale del cambiamento e dire “Io ne sono responsabile!“.

Spesso, le iniziazioni sono accidentali, una conseguenza naturale della crescente esperienza e responsabilità, ma se impostate una iniziazione cosciente per il vostro protetto, non c’è bisogno di dirgli che lo state facendo. In effetti, probabilmente, non dovreste. Mostrate al vostro protetto che credete in lui trattandolo come un ingegnere regolare.

Se l’iniziazione ha successo, il vostro protetto diventerà un membro alla pari, sebbene abbia ancora molto da imparare. Sarà in grado di guidare il suo progresso senza dover più essere condotto per mano e le sessioni in coppia saranno più collaborative che istruttive. Dopo questa transizione, potete fare un gran passo indietro, ma continuare a guidare e porre sfide quando necessario. Dopo tutto, come sostiene Robert Anton Wilson, una vera iniziazione non finisce mai.

Il mentoring fa bene all’intero team#section6

Quando mi sono unita per la prima volta al mio team, era l’unica junior developer. Ora, il nostro team è cresciuto ed è cambiato e quasi la metà di noi sono junior.

Sono stata testimone di quanto questo cambiamento abbia cambiato in meglio le nostre dinamiche. Gli ingegneri esperti fanno domande ai junior, motivandoli a rifinire la loro conoscenza e i junior, a loro volta, fanno domande. Invece di un paio di buoni comunicatori che si accollano il peso dell’addestramento per tutti, ognuno di noi è attivamente sempre coinvolto in questa condivisione di skill. Dove una volta gli individui venivano isolati, ora c’è uno spirito di collaborazione e divertimento. La volontà di imparare e di adattarsi è diventato un valore centrale dell’intero team.

Inoltre, ha migliorato in maniera sensibile la qualità del nostro codice. Sguardi nuovi sono l’ideale per identificare degli anti-pattern, dei problemi di stile e dei pezzi di codice confusi. Con un salutare mix di junior, abbiamo migliorato l’equilibrio tecnico e abbiamo creato nuove feature e il nuovo codice con cui facciamo merge è più semplice da mantenere. Senza il mentoring, questi miglioramenti non si sarebbero mai presentati.

I software engineer sono fortunati a lavorare in un settore in cui strumenti e processi per la collaborazione sono sia bene definiti sia popolari, ma, per parafrasare l’Agile Manifesto, sono le persone e le interazioni che effettivamente creando o disfano un prodotto. Il mentoring è un’interazione potente che, se fatto nel modo giusto, può elevare la qualità sia della vita sia del codice del vostro team e prepara la strada per un’organizzazione di successo.

Illustrazioni: {carlok}