Blog

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

Queste sono solo alcune delle frasi sul tema in cui potresti imbatterti cercando qualcosa come "programmer googling stuff". 

Ora, la nostra 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 web developer 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. 

In realtà gli sviluppatori informatici sono tutti abbastanza concordi su affermazioni del tipo: 

• Tu non saprai mai fare il prossimo software che realizzare, 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 informatici: 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 da un amatore.

Quelle che uno sviluppatore web 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 farla assimilare ad eventuali clienti e/o a 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 

Parlando di coding, ecco una cosa in cui quest'ultima disciplina differisce particolarmente dalle altre: potrai programmare da diversi anni, ma, da docente, ti ritroverai continuamente a spiegare come fare a recuperare informazioni, prima di fornirle ai tuoi 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. Riportiamo subito un esempio, poi proseguiamo: 

Il problema di Hiromi: Un teorema dimostrato su 4chan 

Qualche tempo fa, 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 spazzatura. 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 studiarlo, 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 come persona in grado di contribuire allo sviluppo di tali discipline. Poiché la programmazione informatica si fa usando linguaggi di programmazione che chiunque può studiare, 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 vogliamo dire che non esistano in questo campo libri autorevoli o affini. 
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, ma di nuove domande che ci vengono poste e che, al momento in cui vengono poste, non hanno ancora una risposta. Immagina 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 

Non serve 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 stiamo 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 all'occorrenza e – cosa altrettanto importante – dismettere se diventano inutili. 
Esistono 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 sotto-obiettivi. 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 abbimo detto che alcuni developer 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. 

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. Ricordiamo un'intervista in cui Bill Gates descrisse la curiosità come l'impulso a stabilire se si è in grado o no di indovinare una previsione, cioè se la propria lettura della realtà è lucida o affetta da distorsioni (cioè bias).  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 informatica come in qualunque altra materia, possiamo anche scordarci qualsiasi cosa che assomigli all'eccellenza.

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.