Confessioni di un laureato in informatica senza basi solide
Ai tempi dell’università mi credevo piuttosto bravo. Eppure non avevo la minima idea di quanto fossero importanti i fondamenti di informatica: pensavo solo a portare a casa buoni voti.
A modo mio seguivo con impegno i corsi di indirizzo, e avevo persino vinto premi in gare di programmazione dell’ateneo e in concorsi di capstone design (progetti di gruppo di fine percorso). Quando i miei compagni di corso si scervellavano su un errore nel codice, io stavo lì accanto a dispensare consigli non richiesti, sentendomi superiore. Ma oggi lo confesso: quello che realizzavo allora era roba da bambini.
Collegare un vero database (DB) mi sembrava troppo difficile, così salvavo i dati in un file del Blocco note (.txt), separati da virgole (,). E al posto di un Raspberry Pi, che richiede un controllo a livello di sistema operativo, ripiegavo alla buona su un Arduino, che funziona con poche righe di codice. I professori lodavano risultati che sembravano funzionare solo in apparenza, e io scambiavo tutto questo per la mia vera competenza.
Colloqui superati a memoria: lì è cominciata la tragedia
Ma appena sono stato gettato nel mercato del lavoro, quella sicurezza infondata è andata in frantumi. Una bocciatura dopo l’altra, già alla selezione dei curriculum. Il titolo di vincitore di gare non bastava a nascondere quanto fossero fragili i miei fondamenti di informatica.
Più l’ansia mi assaliva, più mi fissavo sull’accumulare un sapere di facciata. La comprensione passava in secondo piano: imparavo a memoria, come una macchina, le risposte modello per superare i colloqui. Il mio libro di testo erano le «100 domande più probabili ai colloqui» raccattate dai blog tecnici.
Alla domanda del selezionatore, «Qual è la differenza tra TCP e UDP?», rispondevo come un distributore automatico: «TCP è orientato alla connessione e garantisce l’affidabilità, ma è lento; UDP è senza connessione ed è veloce, ma meno affidabile».
In realtà non sapevo affatto cosa fosse un pacchetto, né come avvenisse davvero il 3-way handshake. Eppure, ironia della sorte, proprio grazie a quella memoria meccanica sono riuscito a ingannare i selezionatori, a strappare punteggi niente male e a farmi assumere. Pensavo di essere stato fortunato. Non sapevo che era l’inizio di una tragedia: il karma accumulato in quattro anni mi sarebbe piombato addosso tutto in una volta.
Sopravvivere da full stack in un piccolo team
Sono finito in un piccolo team. Lì non esisteva nessuna comoda distinzione tra «frontend» e «backend».
Fin dal primo giorno mi sono ritrovato davanti a uno tsunami di tecnologie. Pensavo che mi bastasse essere bravo in uno solo tra Java e JavaScript. La realtà, invece, era lo schermo nero di un terminale SSH su Linux, container Docker dalla natura misteriosa, pipeline CI/CD su GitLab, e poi Spring Boot, Vue.js e perfino Redis… Tutte le tecnologie che da studente avevo rimandato con un «lo farò più avanti» o liquidato con un «questo non serve saperlo» mi attaccavano da ogni parte.
Le nozioni che recitavo a memoria ai colloqui non servivano a nulla nel lavoro vero. Anzi, a essere precisi, non sapevo «applicarle». Per capire perché il container Docker che avevo avviato continuava a morire (OOM) o perché Redis si mangiava la memoria, mi servivano davvero proprio quei fondamenti di informatica che avevo imparato a memoria per i colloqui.
Un castello costruito sulla sabbia
Alla fine ero diventato uno «sviluppatore copia-incolla», che copiava e incollava codice a destra e a manca (Ctrl+C, V). In qualche modo le funzionalità giravano, ma non sapevo perché.
- CORS Error: perché il mio browser rifiuta la risposta del server? (non sapevo nulla degli header HTTP)
- OOM (Out Of Memory): perché un server che andava benissimo all’improvviso muore? (non sapevo nulla di memory leak e GC)
- Connection Refused: in locale funziona, ma perché appena faccio il deploy smette di funzionare? (non sapevo nulla di port forwarding e firewall)
Senza conoscere i principi nascosti dietro le comodità offerte dai framework, quando qualcosa si rompeva non ero in grado di risolverlo. Stavo costruendo un castello pericolante fatto di framework appariscenti, su un terreno in cui i fondamenti di informatica erano fragili.
Re: Booting, di nuovo al punto di partenza
Così ho deciso di ripartire dall’inizio. Più che mettere insieme subito un altro progetto appariscente per il portfolio, sentivo più urgente risolvere una domanda essenziale: «Ma come fa, in concreto, un computer a capire ed eseguire il mio codice?».
Questo blog è il diario di un ripasso accanito: quello di un laureato che in mano ha solo il diploma e che ricostruisce da zero i propri fondamenti di informatica. Non mi limiterò a elencare comandi Linux o a spiegare come installare Docker. Voglio invece raccontare il percorso con cui mi pongo domande come queste e ne cerco le risposte.
- Language & OS: che cosa succede da quando il codice Java viene compilato a quando arriva alla CPU?
- Network: quando premo Invio nella barra degli indirizzi, che percorso seguono i pacchetti nel loro viaggio?
- Virtualization: che differenza c’è tra il mio portatile e i computer della sala server, e perché serve la virtualizzazione?
- DevOps: come faccio a fare il deploy del codice che scrivo in modo sicuro e automatico?
Oltre localhost
L’obiettivo finale è costruire e gestire con le mie mani Linux, Docker, CI/CD e perfino ambienti cloud. Spero che seguirai il mio percorso: lasciare la serra sicura di localhost e diventare un ingegnere capace di sopravvivere anche nella natura selvaggia dei server veri.
A chi, come me in passato, dice «l’ho studiato all’università, ma non me lo ricordo», spero che questo diario possa fare da piccolo segnavia, di quelli che fanno battere una mano sulla fronte ed esclamare: «Ah, ecco cosa intendeva il professore!».
