Impara ad imparare - L'arte di cercare risposte nella programmazione

Impara ad imparare - L'arte di cercare risposte nella programmazione

Marco Bellezza Di Marco Bellezza


programmazione imparare apprendimento learning

"I programmatori sono semplicemente più bravi a cercare cose su Google." 
"L'uso dei motori di ricerca è la competenza più importante di un programmatore esperto." 
"Sono uno sviluppatore o solo un bravo Googlatore?" 
"È normale che io sia sempre su Google?" 

Queste sono solo alcune delle frasi sul tema che ho trovato cercando (invero non su Google, ma su Bing - sì, c'è qualcuno che usa Bing) qualcosa come "programmer googling stuff". 

Ora, la mia ricerca era abbastanza mirata, ma la quantità di meme e di post che si possono recuperare sull'argomento è abbastanza importante; il mondo sembra essere pieno di programmatori che si chiedono se la loro competenza in effetti non consista semplicemente nella capacità di fare ricerche molto mirate e di selezionare le giuste risposte alle loro domande. 

Io stesso e tutti i programmatori che conosco, siamo tutti abbastanza concordi su affermazioni del tipo: 

  • Tu non sai mai fare il prossimo software che farai, finché non l'avrai fatto. 
  • Non ho mai fatto un progetto in cui non ci fosse qualcosa da imparare. 
  • Programmare è risolvere problemi, e noi veniamo pagati per affrontare problemi che non sono ancora stati risolti. 

Ogni progetto richiede studio

Questa è una verità inderogabile, almeno per due categorie di programmatori: quelli molto inesperti e quelli molto esperti; è probabile che nel mezzo ci sia qualcuno che scrive codice facendosi poche o nessuna domanda. Ebbene, costoro sbagliano

Fare software non è esattamente come intagliare il legno. Non ci sono reali abilità manuali da acquisire e poi applicare, se non forse quelle di essere abbastanza veloci nel digitare e dimestichevoli nel fare i copia e incolla, ricaricare una pagina web, riavviare un PC. 
Il nostro strumento di lavoro è il computer, quindi sicuramente, da un punto di vista manuale, quello va saputo usare; ma non è certo nell'uso di un sistema operativo, di una tastiera o di un browser web che risiedono le principali competenze che distinguono un vero programmatore dall'IT guy che sta nello scantinato e riceve i ticket di quelli del commerciale perché "mi si è bloccata l'utenza del CRM, è la terza volta questa settimana". 

Massimo rispetto per l'IT guy, colonna portante della digitalizzazione. 

Quelle che un programmatore plasma dall'inizio alla fine di un progetto sono regole e informazioni. Che si faccia parte di un'azienda "di prodotto", oppure di una software house che sviluppa software ad hoc per i committenti più disparati, in ogni caso bisogna andare a conoscere le regole e le informazioni proprie del dominio in cui il nostro software dovrà andare ad operare. 

Questa è già di per sé una cosa abbastanza difficile da far comprendere ai novizi; figuriamoci ficcarla in testa a eventuali clienti e/o tutte quelle figure aziendali non tecniche che hanno il potere di dirci cosa dobbiamo fare o di questionare su ciò che riteniamo di dover fare per produrre ciò che dobbiamo produrre. 

(Non) come a scuola 

Personalmente amo insegnare. Ho dato ripetizioni per una lunga parte della mia vita, ho avuto allievi di chitarra e di recente nei ritagli di tempo faccio da tutor a qualche amico che si sta avvicinando al coding. Ecco una cosa in cui quest'ultima disciplina differisce particolarmente dalle altre: nonostante io programmi da diversi anni, mi trovo continuamente a spiegare come fare a recuperare informazioni, prima di fornirle ai miei allievi. 

I motivi sono principalmente due: uno storico e uno metodologico

Perché i programmatori stanno tutto il tempo sul web: Motivo storico 

Gli informatici, che il web lo hanno inventato, sono stati i primi a pensare di utilizzarlo per condividere conoscenza; non è affatto scontato e non è così in tutte le scienze. Riporto subito un esempio, poi proseguiamo: 

Il problema di Hiromi: Un teorema dimostrato su 4chan 

Qualche tempo fa una una persona anonima, dimostrando per la prima volta un teorema (all'epoca irrisolto) su 4chan, ha sollevato un putiferio presso il mondo dei matematici: questa comunità non è affatto abituata a ricevere contributi in modo ufficioso, da persone anonime, su piattaforme in cui viene generalmente pubblicata la peggio spazzatura (con tanto affetto ai frequentatori di 4chan). Sono letteralmente andati tutti in crisi: non si sapeva a chi attribuire la dimostrazione, non c'era un paper autorevole che l'avesse proposta per primo, le altre riviste erano in imbarazzo a riportare "un anonimo su 4chan" come autore della dimostrazione. Un aneddoto che ha dell'assurdo, ma vale la pena studiarselo, per capire in quali meccanismi si possa impelagare il mondo accademico; Vice e Bufale.net hanno trattato la vicenda, per chi volesse approfondire. 

Dunque, mentre per il mondo scientifico classico eventi come questo costituiscono un'anomalia, nel mondo della programmazione l'idea che un problema venga risolto da una persona qualunque, assolutamente non autorevole, magari anonima, non è poi così assurda; soprattutto dal momento in cui l'open-source è stato riconosciuto come un patrimonio umano anche dai colossi che un tempo lo osteggiarono aspramente. 

Perché i programmatori stanno tutto il tempo sul web: Motivo metodologico 

In altre discipline storicamente molto radicate, è prevista una sorta di cursus honorum che qualifica un essere umano a persona in grado di contribuire allo sviluppo di tali discipline. Poiché la programmazione si fa usando linguaggi che chiunque può studiarsi, imparare a programmare è un po' come imparare nuove lingue parlate: una cosa che può essere tranquillamente fatta anche con percorsi non accademici. D'altra parte, dato che tutte le informazioni sono disponibili su internet per i motivi storici già citati, risulta molto più efficace per un programmatore imparare a scegliere bene i termini della ricerca, piuttosto che conoscere la pagina del capitolo del libro che tratta l'argomento in modo esaustivo e autorevole. 

Con ciò non voglio dire che non esistano in questo campo libri autorevoli o cose del genere. 
Il punto è questo: a scuola si imparano le risposte a domande che qualcuno si è posto prima di noi; e non dobbiamo illuderci: anche se vogliamo imparare a programmare, qualcosa dobbiamo farci spiegare alla maniera classica. MA, una volta mossi i primi passi, dobbiamo procedere con la consapevolezza che la nostra vita professionale non sarà fatta di verifiche o esami o compitini, ma di nuove domande che ci vengono poste, e che al momento in cui vengono poste non hanno ancora una risposta. Immaginate una scuola fatta esclusivamente di professori/committenti che pongono problemi irrisolti ai loro studenti, che dovranno a quel punto fare lunghe ricerche e poi esporre le proprie conclusioni ai compagni di classe. In pratica, questo è il motivo per cui il software si sviluppa, mentre le scrivanie (per esempio) si fabbricano. 

Da Socrate a Dunning-Kruger 

"Io so perché so di non sapere." 
Socrate 

"L'ignoranza genera fiducia più spesso della conoscenza" 
Charles Darwin 

"...coloro che hanno certezze sono stupidi, mentre quelli con immaginazione e comprensione sono pieni di dubbi e di indecisioni" 
Bertrand Russel 

"Il saggio sa di essere stupido, è lo stupido invece che crede di essere saggio" 
Shakespeare 

"Quanto più uno è ignorante, tanto più è audace e pronto a scrivere" 
Spinoza 

Devo aggiungere altro? Quelle sopra citate sono solo alcune delle intuizioni di moltissimi pensatori della storia su questo argomento. Come se non bastassero le riflessioni di queste lucidissime menti, la conferma scientifica di questo principio è arrivata nel 1999 da due socio-psicologi, David Dunning e Justin Kruger. La conclusione dei loro studi è inequivocabile: la mente umana è innatamente affetta da un cosiddetto bias cognitivo, cioè una delle tantissime distorsioni della percezione da cui siamo inevitabilmente affetti, che ci porta a sopravvalutare le nostre competenze quando siamo ignoranti, per poi ridimensionarle man mano che ne acquisiamo. 

Questo avviene semplicemente perché aumentando le nostre competenze guadagniamo visibilità sulla vastità della materia che stiamo trattando, rendendoci via via conto che non basterà una vita a padroneggiarla in toto. Ne consegue che la consapevolezza dei nostri limiti è un metro migliore delle nostre competenze, rispetto alla nostra valutazione circa le competenze stesse. 

Le competenze viste come risorse

Dalla scuola assorbiamo implicitamente l'idea che le competenze siano quello che ci resta interiorizzato dopo un percorso di studio assiduo di una disciplina. Ebbene man mano che si diventa esperti ci si staglia davanti agli occhi l'evidenza che non potremo mai interiorizzare tutto ciò che ci serve per fare il nostro mestiere. Ecco quindi che nasce una meta competenza, cioè la nostra capacità di recuperare competenze come fossero risorse, materie prime che spenderemo nell'ambito del nostro prossimo progetto. 

Il motore della ricerca

No, non sto parlando dei motori di ricerca, ma di ciò che ci spinge a ricercare competenze, una volta che abbiamo imparato a trattarle come delle risorse che possiamo rimediare alla bisogna e (cosa altrettanto importante) dismettere se diventano inutili. 
Personalmente nel corso del tempo, tra studi ed esperienza diretta, ho individuato tre categorie di drive che si attivano quando abbiamo bisogno di nuove competenze: 

  • I compiti 
  • I dubbi 
  • La curiosità

Task driven learning: imparo perché il compito lo richiede 

Questo è senza dubbio il caso più frequente quando si lavora. Abbiamo un obiettivo, lo spacchettiamo in una serie di sottobiettivi, e individuiamo una serie di cose che ci servono per raggiungere tali sottobiettivi. Mettiamo caso che vogliamo realizzare un componente che mostri una serie di immagini una dopo l'altra. Tanto per cominciare, dobbiamo saper descrivere ciò che stiamo cercando di ottenere. Facendoci un giro su qualche sito di componentistica per UI apprendiamo che componenti di questo tipo sono chiamati caroselli. Bene, sappiamo cosa cercare. Ora dobbiamo semplicemente scegliere una libreria ben documentata che faccia la cosa, e poi adottarla. 

Il task driven learning si autoesaurisce nel momento in cui l'obiettivo viene raggiunto. Saranno la sensibilità e l'esperienza a dirci se quel componente che abbiamo appena imparato ad usare ci tornerà utile molte volte in futuro oppure no; la nostra memoria agirà di conseguenza. 

Question driven learning: imparo per eliminare un'incertezza 

Prima ho detto che alcuni programmatori di media esperienza tendono a fare poche ricerche. Di solito è perché sono in una fase in cui stanno iniziando ad avere delle certezze (e avere certezze è gratificante), ma non hanno ancora una buona visibilità sullo spettro delle possibilità che hanno davanti, oppure si accontentano di una tecnica che hanno appreso e cercano di impiegarla un po' dappertutto, anche laddove questa tecnica non è propriamente atta allo scopo o addirittura è totalmente inefficace. 

Un esempio: molti programmatori, anche discretamente capaci, ma non particolarmente ferrati sui metodi per operare sugli array in JavaScript, arrivano a padroneggiare molto bene il metodo map, finendo per usarlo anche dove sarebbe più opportuno usare un forEach, un reduce, etc... 

Non è nell'interesse di questo articolo, ma ci tengo a precisarlo: map serve ad ottenere un nuovo array dove ogni elemento corrisponde ad una trasformazione (mappatura) di un elemento dell'array originale; forEach serve semplicemente a scorrere un array eseguendo la medesima operazione per ogni elemento dello stesso; reduce serve invece a collassare (ridurre, per l'appunto) tutti gli elementi di un array in un unico valore finale che va accumulandosi elemento dopo elemento. È chiaro che il meccanismo iterativo è simile in tutti questi casi, ma lo scopo di ognuno di questi metodi è profondamente diverso e specifico

Un programmatore esperto si chiede sempre quale sia la strada più breve e diretta per arrivare dove vuole arrivare, anche se ne conosce già una, che però potrebbe essere inutilmente tortuosa. Non dobbiamo fare i McGiver con quelle due o tre cose che abbiamo imparato, cercando di campare di rendita a vita. Non fatelo, vi prego. I vostri colleghi vi odieranno e, alla fine, anche voi maledirete voi stessi, in una disperata sera di pioggia a dirotto. 

Ehm... 

Tornando al question driven learning: in questo caso l'apprendimento è motivato proprio dal fatto che ci si pone domande su quello che ci sta facendo. L'incertezza è una prova di perizia. L'oggetto della nostra indagine in questo caso saranno articoli in cui altre persone si sono poste il nostro stesso dubbio, quindi cercheremo qualcosa che assomigli il più possibile alla nostra domanda, oppure useremo il formato "opzione1 vs opzione2", che è abbastanza universale nel caso in cui si stiano comparando due approcci, due framework, due librerie, due qualsiasi opzioni alternative. 

Curiosity driven learning: imparo perché voglio comprendere la realtà 

In questo caso non c'è realmente un fine pratico. Ricordo un'intervista in cui Bill Gates descrisse la curiosità come l'impulso a stabilire se si è in grado o no di azzeccare una previsione, cioè se la propria lettura della realtà è lucida o affetta da distorsioni (cioè bias). Per completezza riporto anche una definizione dai Digimon, in cui Izzy (il ragazzino col portatile che di fatto realizza l'esistenza di Digiworld) fu identificato come una mente avida di sapere. L'avidità di sapere è una ricerca continua di consapevolezza fine a sé stessa, ma questo non significa che non abbia valore. 
A tutti gli effetti, senza curiosità, nella programmazione come in qualunque altra materia, possiamo anche scordarci qualsiasi cosa che assomigli all'eccellenza. Aurea mediocritas saltami addosso, insomma. 

Sentirete parlare di curiosity driven learning anche nell'ambito dell'apprendimento automatico (machine learning), applicando grossomodo la definizione di Bill Gates ad un metodo di apprendimento automatizzabile: il software fa una predizione e poi sta a guardare; dopodiché si autovaluta in base a quanto la sua predizione si discosta dalla realtà. 

Questo è un metodo semplicissimo che possiamo applicare anche sul lavoro: prima di fare qualcosa, iniziamo a fare stime su: 

  • Quanto ci metteremo 
  • Quanti/quali ostacoli incontreremo 
  • Quante/quali funzioni/classi/componenti ci serviranno 
  • Quale approccio funzionerà meglio 

Dopodiché, a lavoro finito, iniziamo a ricalibrare la nostra visione del mondo, potando tutte le nostre convinzioni sbagliate. 

Non è cosa da poco: la curiosità, pur non rispondendo ad esigenze concrete e mirate, è un potente acceleratore del nostro apprendimento e ci aiuta a non persistere nei nostri errori.

Impara a programmare in 3 mesi con il Corso di Coding Hackademy su Laravel PHP

Diventa Sviluppatore web in 3 mesi

Scopri il coding bootcamp Hackademy

Programma Completo