Uno degli aspetti, al tempo stesso, più stimolante, gratificante, difficile e stressante del mestiere dell’informatico è l’impegno che serve per imparare, raffinare e studiare costantemente nuove tecnologie e a volte capita di doverlo fare velocemente.
Per quanto mi riguarda, studiare ed imparare nuove tecnologie è solo una parte del faticoso mondo della formazione personale; la cosa a cui devo dedicare buona parte dei miei sforzi è quella di riuscire a ricordare quello che studio.
Imprimere nella memoria i concetti salienti, gli snodi decisionali, i dettagli significativi di una tecnologia e riuscire a richiamarli ed usarli nel momento giusto, beh, quello per me è imparare. Il resto è nozionistica e serve poco “sul campo”.
Ma la mia memoria è decisamente una coperta corta.
Quindi? Ci vuole un piano!
Imparare ad imparare è stato uno dei primi skill su cui ho lavorato e fortunamente non l’ho presa alla leggera: non ho dato per scontato che solo perchè ho studiato molto in passato ed ho superato esami difficili, potessi imparare nuove tecnologie ogni volta che volessi. Perchè? Sempre per lo stesso motivo: è una coperta corta!
Diversi anni fa ho approfondito delle tecniche di apprendimento come quella descritta in 10 steps to learn anything quickly ed ho trovato degli spunti interessanti, ma come sempre, la vera ricetta è qualcosa che si forma dall’esperienza e si plasma intorno alla sensibilità e alle inclinazioni personali.
Qui vi racconto la mia ricetta, calata sull’ultima esperienza: imparare Angular Schematics.
NOTA: qui per me non è importante far capire cosa sono gli schematics (se ce la faccio ne scriverò articoli dedicati), ma far capire come ho approcciato lo studio su un caso reale. In particolare gli schematics sono un argomento abbastanza semplice e si presta bene allo scopo, ma, in ogni caso, l’approccio è quello che uso nello studio di tutto, da aspetti architetturali a nuovi linguaggi di programmazione.
Definisco il MIO scope
Questa è la parte più importante per me e se dovessi scegliere un solo “take away” da questo articolo sarebbe proprio questo. Cosa intendo? Una delle tentazioni che avevo quando cercavo di imparare nuove tecnologie era quella (utopica) di imparare tutto. E’ impossibile e non serve.
Ma non solo: quando parlo di scope, parlo soprattutto di definire un orizzonte temporale entro il quale chiudere la formazione. Studiare è un lavoro che non ha mai fine; bisogna fare pace con questa realtà ed è meglio definire un tempo limite da dedicarci. Senza poi essere particolarmente fiscali nel rispettare queste scadenze (imparare non è un processo lineare e gli imprevisti sono all’ordine del giorno), ma fissare un limite è importante; come lo è ottenere anche un “nulla di fatto” come possibile esito (magari si è sottovalutato l’argomento, magari il setup di un progetto di prova ha decine di imprevisti…).
Per angular schematics mi sono dato dai 3 ai 5 giorni di studio spalmati su due, massimo tre settimane; l’obiettivo era quello di creare reali schematics da usare nel progetto per semplificare il codice boilerplate dei flussi NGRX e la creazione di modali comuni.
Setaccio il materiale di studio
Per il materiale da studiare faccio un elenco iniziale nel quale metto (quasi sempre) in quest’ordine:
- riferimenti a documentazione ufficiale (se esiste)
- libri specifici sull’argomento
- corsi online
- repository Github che applicano quello che studio in codice di produzione
Cerco di stare lontano all’inizio da articoli su blog o (peggio) da Stack-overflow, ma in ogni caso, mi appunto i link più interessanti.
Poi, cerco in quest’elenco materiale specifico per il mio scope e mi focalizzo solo su quello che è più centrato. Il resto lo uso come “seconda scelta”, quando non mi è chiaro qualcosa o voglio approfondire ulteriormente.
Per gli schematics, ho acquistato 2 libri (Angular Schematics Cookbook e Angular Schematics). La documentazione ufficiale Angular, in questo caso, non è approfondita come per il resto, ma esiste il codice open source di Angular che usa la tecnologia per creare i propri schematics. I libri (e qualche articolo online) mi sono serviti per avere una base stabile “teorica”, importante per comprendere bene la sfera di applicabilità (e NON) e per fare il setup dei miei progetti di studio. i repo Github sono stati un affidabile sostegno nella fase implementativa e nei dettagli più complessi.
Definisco le MIE domande e lavoro per trovarne le risposte
Diretta conseguenza dell’aver definito un proprio obiettivo, arrivano le proprie domande a cui dar risposta. Cerco di dare enfasi alle domande che mi faccio e quando ha senso ne esploro le varianti; La cosa migliore è quella di usare la tecnologia e cercare di risolvere i propri problemi; il che è diverso dall’applicare codice “hello world” o tutorial didattici presenti in molti libri o articoli. Per sintetizzare: più che semplicemente fare si tratta di cercare di mettersi il più vicino possibile al fare esperienza e l’esperienza, si sa, è qualcosa di personale.
Questo è quello che permette ad una nozione di diventare conoscenza e “macchiare” un po’ più in profondità la coperta corta della memoria.
Alcune delle mie domande a cui ho dato risposta con gli Angular Schematics
- Come testo facilmente il codice degli schematics?
- Come gestisco logiche di sostituzione custom nei template EJS?
- Come modifico file esistenti per aggiungere altro codice?
- Come faccio in modo di preservare l’uso degli altri schematics (angular, ngrx)?
- Come semplifico il passaggio dei parametri agli schematics?
- Come riduco il “carico mnemonico per l’utente” di quello che alla fine è una task shell-based?
Documento le “lesson learned”
L’ho detto già che la mia memoria è corta? 
Quindi cerco di dargli una mano, lo faccio (quasi) esclusivamente per me, per poter ricordare facilmente quanto imparato anche dopo 6 mesi. La forma varia a seconda del contesto, documentazione classica, diagrammi, ma anche test specifici quando il contesto è tecnico.
L’importante è trattarsi come un estraneo ed in particolare non tralasciare la documentazione legata ai setup dell’ambiente o del progetto.
Per angular schematics ho appuntato le lesson learned in una presentazione, ma poteva essere un word o blocco note e mi sono appuntato:
- le API comuni o utili da ricordare (pensatevi tra 6 mesi a ricercare queste signatures). Quelle delle Rules, dei Tree in particolare
- i momenti “ah-ah” che trasformano le nozioni in conoscenza e danno un senso a quello che sto studiando
- i setup necessari: per questi ho sfruttato un progetto locale e una bella batteria di test a supporto
Cerco occasioni per insegnare quanto imparato
Passaggio importante (molto) è quello di cercare l’occasione di insegnare quanto si è imparato a qualcun’altro. Può essere qualunque cosa: una formazione tra colleghi, un seminario aziendale, un evento di community, un articolo di un blog personale, un progetto opensource, un documento word, qualunque cosa finalizzata a spiegare ciò che si è imparato.
Non è una forma di narcisismo informatico, quanto uno stratagemma veramente funzionale per “glassare” il mio percorso formativo. I due risultati principali che cerco di ottenere da questo ultimo passaggio sono:
- riassumere e incanalare il tortuoso percorso di apprendimento in una storia lineare che qualcun’altro riesca a capire. Serve per sedimentare e razionalizzare i concetti salienti appena appresi
- costringersi ad approfondire una parte di quegli aspetti che altrimenti avresti derubricato tra gli argomenti secondari tra cui quelli che “mi funziona, ma non so bene perchè” o “non è proprio quello che ho approfondito io (ma siamo lì vicini)”
Se possibile cerco di preferire il confronto con gli altri, che in genere sollevano altre domande (e quindi altre occasioni di approfondire).
Dopo aver messo a disposizione un progetto interno per permettere agli altri del mio team di usare gli schematics, abbiamo organizzato una delle nostre sessioni di academy interna per spiegare al resto del team i risultati ottenuti. Nel farlo sono stato “costretto” a definire un filo logico del percorso che ho fatto, legare tra loro i concetti che durante le prove si sono frammentati e biforcati e nel preparare la presentazione sono venute fuori altre domande a cui ho dato le mie risposte.
GHOST TRACK: l’importanza del contesto ambientale
Quanto è importante il ruolo della tua azienda nella tua formazione personale?
Ho avuto modo di lavorare in aziende di piccole, medie e grandi dimensioni e di osservare come lavorano molte altre aziende; ognuna interpreta la formazione aziendale a proprio modo: corsi obbligatori, facoltativi, pillole formative con speaker interni o esterni, corsi online, consulenze esterne, ecc. ecc.
Ma la formazione aziendale è cosa diversa dalla formazione personale; la formazione personale potrebbe non necessariamente avere un risvolto pratico nel breve periodo (potrebbe non averlo mai), ma è espressione della curiosità della persona, della sua voglia di superare i propri limiti, di esplorare, della sua intraprendenza.
Le aziende che hanno un reale interesse a mettere le “persone al centro” (quante volte l’avete sentita questa?) le metteranno nella condizione di esprimere questa intraprendenza e vivacità. Come? via…conoscete già la risposta: dando fiducia alle loro persone, lasciando sfruttare parte del proprio tempo “in ufficio” alla formazione personale, finanziando i corsi che vorrebbero fare, acquistando i libri che chiedono…anche se questo (ripeto) potrebbe non avere un risvolto diretto nel lavoro quotidiano.
Perchè?
Potremmo parlarne per ore, ma la risposta corta è “per valori e per calcolo”, perchè avendo i valori giusti sapranno che il valore di un’azienda è la somma del valore delle sue persone. E questo valore va alimentato e va messo nelle condizioni di crescere.
E si cresce solo imparando.
Comments