Blog

Da un po' di anni si sente un gran parlare di coding insegnato a scuola e di programmazione intesa non più solo come una vocazione e una competenza professionali, ma come una basic skill  da apprendere per vivere nel prossimo futuro da persone pienamente alfabetizzate. 

Personalmente mi permetto di aggiungere che non solo la programmazione è una competenza non più opzionale, perché affrontata anche solo superficialmente ci aiuta a capire come funziona il software, un'entità sempre meno astratta che di fatto ormai determina il comportamento di qualsiasi dispositivo, persino di una lampadina (se abbiamo comprato delle lampadine intelligenti); in aggiunta a questo, la programmazione ha tutte le carte in regola per sostituire (o almeno affiancare) un'attività ben più classica e tradizionale, a cui tutti noi siamo abituati, ma che ultimamente abbiamo visto quasi completamente sparire dalla scena: l'enigmistica. 

Programmazione vs Enigmistica

Riflettiamo un po' su che cos'era l'enigmistica quando era ancora mainstream. Se penso a me stesso, da utente quasi esclusivamente estivo, il mio rapporto con questa materia era: 

Giornata al mare durante una vacanza in solitaria 

• Sveglia abbastanza presto;

• Arrivo in spiaggia quando ancora fa freschino;

• Abbiocco sulla sabbia;

• Cruciverba per la compagnia;

• Attività varie ed eventuali;

• Ancora cruciverba misto a sudoku, rebus e trova le differenze.

Fine. Non ci sono concretamente molte altre situazioni in cui avrei fatto ricorso all'enigmistica per ammazzare il tempo. 

Oggi con i nostri telefoni sempre a portata di mano, pronti a metterci in contatto con il mondo o a intrattenerci con centinaia di giochini (tra cui magari anche qualcosa che all'enigmistica ci si avvicina), è diventato più impegnativo anche solo recuperare la rivista giusta in edicola e rimediare anche una penna da tenere in borsa. 

Se ti riconosci nella mia ricostruzione, potresti prendere in considerazione di ritrovare nella programmazione quegli stessi elementi di stimolo mentale, analitico, nozionistico e creativo che personalmente trovavo nelle riviste dedicate a cruciverba e altri giochi. Mi sono divertito a cercare alcune similitudini tra le tante attività che ruotano intorno alla scrittura di un software e alcuni noti giochi enigmistici. 

Facciamoci insieme questo viaggione mentale. 

Algoritmi vs Sudoku

Quando programmiamo possiamo approcciare gli algoritmi come il sudoku: 

• abbiamo una struttura rigorosa nella quale possiamo muoverci;

• abbiamo in mente poche regole sempre uguali che devono essere rispettate per risolvere un problema;

• vanno evitati conflitti e sovrapposizioni;

• i nostri dati di partenza sono dei vincoli nel contesto.

Ovviamente, quando programmiamo abbiamo molta più libertà. Ma se escludiamo la forma e ci concentriamo sul flusso, otteniamo due esercizi molto simili; abbiamo un contesto iniziale e sappiamo esattamente qual è il criterio che ci porterà alla soluzione finale; noi dobbiamo scrivere tutto quello che c'è in mezzo, facendo in modo che alla fine tutte le regole risultino rispettate. 

In qualche modo, le nostre regole possono essere considerate come dei test per il nostro algoritmo: lo scriviamo e poi il risultato viene esaminato rispetto alla sua conformità con le regole del sudoku, o con quelle di ciò che dobbiamo programmare. Gli algoritmi sono un ottimo esercizio mentale, ci aiutano a tradurre in modo rigoroso i passaggi che risolvono un problema, sono ottimi per ingannare il tempo e abbiamo sicuramente molta libertà nell'inventarceli. Il punto è che non devono essere utili, in questa veste sono solo esercizi mentali. 

Esempi di algoritmo 

• In un insieme di numeri, individuare il massimo/minimo/medio/etc…;

• Stabilire se una sequenza è palindroma;

• Ordinare sequenze di numeri/stringhe/etc… in base ai più disparati criteri;

• Verificare che un dato sia conforme a una serie di requisiti;

• Eccetera eccetera.

Il tutto limitando l'uso della sintassi ai costrutti più semplici, altrimenti non vale. 

Certo, non possiamo sempre portarci dietro (magari in spiaggia, sotto il sole) un ambiente di sviluppo, ma per sviluppare un algoritmo può essere sufficiente disegnare un diagramma di flusso con carta e penna, oppure, cosa che a me piace molto, programmare utilizzando uno pseudolinguaggio. 

Che cos'è uno pseudolinguaggio (o pseudocodice) 

Uno pseudolinguaggio è esattamente ciò che sembra: un modo "verbale" per esprimere un flusso senza ricorrere a notazioni grafiche (parallelepipedi, rombi, etc…), ma semplicemente usando un linguaggio sintetico e rigoroso anche se non ufficiale e quindi libero dai vincoli sintattici specifici di un preciso linguaggio di programmazione. 

Progettazione vs Cruciverba 

La progettazione e pianificazione di un lavoro mi ricordano molto il completamento di un cruciverba: 

• abbiamo un contesto iniziale che presenta alcuni vincoli e nessuna informazione intrinseca su come essere completato;

• esternamente al nostro contesto abbiamo una moltitudine di informazioni che ci aiutano a completare il nostro lavoro;

• le informazioni non sono fornite direttamente, ma richiedono una conoscenza nozionistica per essere tradotte in una soluzione;

• non c'è alcun modo diretto di valutare la bontà delle informazioni utilizzate, ma il fatto che alla fine il quadro torni ci dà confidenza che sia tutto ok.

La similitudine che mi affascina di più è l'ultima. Quando progettiamo un lavoro, sappiamo benissimo che tutte le nostre previsioni sono stimate, parziali, soggette a errori e incertezze; ma risolvendo i conflitti tra le diverse entità del progetto ci si avvicina progressivamente a un piano convincente, nel senso che ogni attività risulta completare e confermare il quadro in cui si inseriscono le altre attività. 

Il bello dei compiti di questo tipo è che in qualche modo ci costringono a mettere da parte un atteggiamento mentale sequenziale (prima questo poi questo poi questo poi questo), in favore di un atteggiamento più esplorativo e basato sul tentativo (questo è così son sicuro, vediamo cosa ci sta vicino; qui ho un sacco di informazioni, questo dovrebbe rendere più facile capire cosa c'è nelle vicinanze). 

Altra cosa importante è che in questo tipo di attività, le nozioni sono all'esterno del problema; pertanto o le abbiamo già in mente, oppure dobbiamo andarle a cercare. Altrimenti il quadro non si completa. Quando progettiamo qualcosa, dobbiamo fare molta attenzione alle definizioni che non riusciamo ad usare per completare il quadro: sappiamo che prima o poi dovremo risolvere quei semplici indizi, concretizzandoli in informazioni spendibili, però sappiamo anche che possiamo proseguire con la pianificazione e magari usare le informazioni adiacenti per rendere più facile convalidare le nuove informazioni, quelle di cui non siamo sicuri. 

Debugging vs Rebus 

Arriva una segnalazione e dobbiamo risolvere un baco. Conosciamo abbastanza bene il codice e, se siamo fortunati, ci è stata fornita una precisa descrizione di come riprodurre la problematica. Così mettiamo insieme le informazioni in nostro possesso e iniziamo a esplorare diverse possibilità, sapendo che la soluzione dal problema non è (nella maggior parte dei casi) un qualcosa che creeremo implementando qualcosa di nuovo, ma un qualcosa che sarà immediatamente evidente una volta che avremo individuato con esattezza l'origine del problema. 

È un rebus! Si tratta di un'attività in cui la mente non deve cercare né produrre nuove informazioni, ma semplicemente trovare la giusta interpretazione per le informazioni già disponibili. Una volta chiara l'interpretazione, la soluzione emerge spontaneamente. 

Una nota interessante sul fronte delle interpretazioni: molto spesso il nostro pensiero va subito alle interpretazioni più comuni, più general purpose, mentre invece lo scopo di chi ha creato il rebus (o il codice bacato) era molto preciso, ed è proprio in quel disallineamento tra l'aspettativa più semplice e la precisa intenzione contestualizzata che risiede spesso la soluzione. 

Git vs Trova le differenze 

Qui non servirebbe scrivere niente. Dai, è palese: è la stessa cosa. Se ti piace il trova le differenze, puoi tranquillamente essere la persona giusta per risolvere tutti i conflitti di merge su Git. 

Che cos'è Git? Che cos'è conflitti di merge? 

Se sei corso a leggere qui, hai bisogno di una spiegazione, altrimenti non capirai la mia bellissima similitudine tra Git e trova le differenze. 

Git è uno strumento per versionare il software, cioè un programmino con cui è possibile tenere traccia di tutte le modifiche subite da un sorgente. Tali modifiche possono essere sequenziali (una dopo l'altra) oppure anche diramarsi in rami paralleli. Questo significa che tramite Git è possibile mantenere due diverse versioni concorrenti dello stesso software; se poi si decide di unire due versioni concorrenti (l'operazione si chiama merge), possono emergere dei conflitti, cioè modifiche al codice effettuate sui diversi rami di sviluppo, tra le quali Git non può sapere quali siano da tenere e quali da scartare. Tali conflitti vanno risolti da un essere umano. 

Per questo dico che se hai occhio nel guardare due cose molto simili e nel capire subito cosa cambia tra le due, probabilmente non farai fatica a capire quello che Git non è riuscito a capire. Anche perché Git non conosce il senso del progetto, e soprattutto non può chiedere aiuto ai colleghi che hanno lavorato sui due rami in conflitto. 

Squadra di sviluppo vs Cruciverba di gruppo (Avanzato) 

Classico pomeriggio in spiaggia, o fermi svaccati in una sudatissima radura in alta quota. Qualcuno propone cruciverba di gruppo. Lasciando che ciascuno stabilisca se questa sia una buona o una cattiva proposta, la realtà dei fatti è che molto spesso un team di sviluppo funziona un po' come un insieme di persone che fanno insieme un cruciverba. Il quadro lo si compone insieme, generalmente il ruolo del caposquadra (o team leader, come va di moda adesso) è quello di mantenere sempre chiaro il quadro della situazione, visualizzare gli obiettivi, tenere a mente gli ostacoli. Dopodiché ognuno contribuisce mettendo tutte le sue conoscenze al servizio dell'obiettivo. 

Le dinamiche sono pure le stesse: bisogna fare il possibile per mantenere l'ordine, pur sapendo che la stessa foga che è nemica di quell'ordine, è in realtà un requisito motivazionale imprescindibile per mantenere tutti concentrati e parallelamente impegnati verso l'obiettivo. Qui il ruolo mediatore del capo è fondamentale: questi deve ascoltare tutti, scrivere rapidamente, sintetizzare le proposte su come procedere, tentare di concludere un'intera area se possibile, in modo da poter concentrare il focus su un'area minore. 

Programmazione == Brain training 

Non solo quindi il coding, ma tutte le fasi dello sviluppo di un progetto software contribuiscono a un potente allentamento mentale; nelle diverse fasi avremo l'opportunità di mettere alla prova creatività, problem solving, rigore logico e matematico, conoscenza dei linguaggi, esperienza derivata dai progetti già compiuti. 

Un toccasana per il pensiero e la memoria, ma anche per la creatività e la curiosità. 
L'allenamento perfetto per una bellissima sinergia tra emisferi.