Il mio errore più grande dopo la laurea CS (e cosa ho imparato)

Background di partenza

C'è un tipo di sicurezza infondata che si genera alla fine di un percorso di studi lungo e impegnativo. Non è arroganza - è qualcosa di più sottile: la convinzione che avere completato il percorso significhi avere acquisito quello che serve per fare il lavoro. Nel mio caso, dopo la laurea in Informatica, quella convinzione era presente in modo implicito. Non la pensavo in modo consapevole - non mi dicevo "so già tutto". Ma c'era un senso di completezza che influenzava il modo in cui mi avvicinavo al primo lavoro da developer.

L'errore più grande che ho fatto non è un singolo episodio - è un modo di stare nel lavoro che si è manifestato in molti episodi nel corso dei primi anni. Si potrebbe riassumere così: ho confuso la conoscenza accademica con la competenza professionale. Non sono la stessa cosa. La conoscenza accademica è la base - è necessaria, è utile, è permanente. La competenza professionale si costruisce sopra quella base attraverso anni di lavoro reale, di errori, di feedback, di iterazione. Non si trasferisce automaticamente da una all'altra.

Perché questo è rilevante per questa serie - per chi viene da background non-CS? Perché molti di voi arrivano al primo lavoro tech con una serie di aspettative non esplicite su come sarà, su cosa sarete chiamati a fare, su quanto velocemente acquisireste le competenze mancanti. Alcune di quelle aspettative sono realistiche. Altre no. E le aspettative non realistiche sono quelle che fanno male - non perché il lavoro sia difficile, ma perché la distanza tra l'aspettativa e la realtà produce frustrazione che viene spesso scambiata per evidenza di inadeguatezza personale. Non lo è.

Questo articolo racconta l'errore per quello che era: un disallineamento tra aspettative e realtà, non una mancanza di capacità. E racconta le lezioni che ne ho tratto - lezioni che, sono convinto, si applicano a chiunque inizi a lavorare come developer, indipendentemente dal punto di partenza.

Un punto che voglio essere esplicito nel chiarire: quando dico "il mio errore più grande", non sto dicendo che il primo anno di lavoro è stato un disastro. Non lo è stato. Il lavoro era decente, i risultati erano accettabili, i colleghi non si sono accorti di gran parte delle difficoltà che stavo attraversando internamente. Ma "accettabile" non è il livello che voglio avere. E la distanza tra "accettabile" e "buono" era, in quel momento, causata principalmente dall'errore che ho descritto. Riconoscerlo in retrospettiva è l'unico modo per non ripeterlo - e per non lasciare che si ripeta in chi è all'inizio.

Una nota sul titolo: "errore più grande" implica che ho fatto anche altri errori. Certo. Ma questo è quello che ha avuto il maggior impatto sulla qualità del lavoro nel periodo che segue la formazione - e quello che ho osservato più frequentemente anche in chi viene da background diversi dal mio. Gli altri errori li racconto, in forma più astratta, nelle sezioni "Difficoltà tipiche" e "Cosa mi ha funzionato" di ciascuno dei prossimi articoli sui background specifici.

Difficoltà tipiche

Prima di entrare nell'errore specifico, vale la pena identificare le difficoltà tipiche del periodo post-formazione - quella fase in cui si passa dallo studio al lavoro reale. Sono difficoltà quasi universali, che ho osservato in persone con i background più diversi.

La distanza tra "sapere" e "fare in produzione"

La difficoltà più pervasiva del primo anno di lavoro da developer è la distanza tra sapere come fare qualcosa in teoria e riuscire a farlo in un sistema reale, con vincoli reali, in tempi reali, con altri sviluppatori che dipendono dal tuo lavoro. Il codice che si scrive nei tutorial e nei corsi è codice isolato: non ha utenti reali, non ha dati sporchi e imprevedibili, non ha dipendenze da sistemi di terze parti che possono fallire, non ha requisiti che cambiano nel mezzo dell'implementazione.

Il codice in produzione è tutto questo contemporaneamente. E la transizione da un mondo all'altro richiede un aggiustamento che non si fa leggendo libri - si fa sbagliando, correggendo, e sbagliando di nuovo in modi diversi. Questo è normale. Il problema è quando si interpreta questa difficoltà di transizione come conferma di inadeguatezza personale invece che come parte inevitabile del processo.

Il feedback asincrono e indiretto

Durante la formazione, il feedback è quasi sempre immediato e diretto: il test passa o non passa, il codice compila o non compila, il docente ti dice se hai capito o no. Nel lavoro reale, il feedback su come stai lavorando è spesso ritardato, implicito, e poco strutturato. Potresti non scoprire per settimane che un approccio che stavi usando non era quello giusto. Potresti non ricevere mai feedback diretto su alcune aree del tuo lavoro.

Questa asincronia del feedback è difficile da gestire, specialmente all'inizio. Il rischio è di andare avanti con approcci sbagliati più a lungo del necessario - perché nessuno te lo ha detto, non perché fossero accettabili. Il contromisura è imparare a cercare feedback proattivamente: chiedere code review, cercare mentorship, partecipare ai retrospettivi del team, fare domande specifiche invece di aspettare valutazioni generali.

La cultura implicita del team

Ogni team di sviluppo ha una cultura implicita: convenzioni non scritte su come si scrive codice, su come si comunicano i problemi, su cosa è accettabile e cosa non lo è, su come si gestiscono i disaccordi tecnici. Questa cultura non viene documentata da nessuna parte - si acquisisce attraverso l'osservazione e spesso attraverso errori. Chi entra in un nuovo team da background non-CS deve fare un doppio lavoro di decodifica: capire le competenze tecniche del ruolo e capire la cultura del team. Entrambi richiedono tempo.

Il perfezionismo come blocco

Una difficoltà specifica dei developer con background accademico forte - sia CS che non-CS - è il perfezionismo. L'accademia premia la completezza, la precisione, la ricerca della soluzione ottimale. Il lavoro reale richiede spesso la soluzione abbastanza buona consegnata in tempo, non la soluzione ottimale consegnata in ritardo. Questo shift non è ovvio e non è immediato. Il perfezionismo che era una virtù nello studio diventa spesso un ostacolo nella consegna.

C'è una versione utile del perfezionismo - quella che porta a scrivere codice leggibile, a testare i casi limite, a documentare le assunzioni. E c'è una versione dannosa - quella che porta a non consegnare mai perché c'è sempre qualcosa da migliorare. La distinzione pratica è questa: se il tuo perfezionismo produce qualcosa che altri possono usare, è funzionale. Se produce stallo, è disfunzionale. La linea tra le due non è sempre ovvia, ma il feedback del team e i ritmi della consegna sono indicatori utili.

L'overengineering come forma di insicurezza

Un errore correlato al perfezionismo è l'overengineering: costruire soluzioni più complesse del necessario perché "potrebbe servire in futuro" o "è la soluzione più elegante". L'overengineering è spesso una forma mascherata di insicurezza: se la soluzione è sufficientemente complessa, è difficile criticarla, perché la complessità viene scambiata per competenza.

La realtà è l'opposto. Ben Halpern su DEV.to descrive bene questo paradosso: i developer senior tendono a scrivere codice più semplice, non più complesso. La semplicità è il risultato di capire il problema abbastanza bene da non avere bisogno di vincoli artificiali di complessità. L'overengineering, al contrario, è il risultato di non capire abbastanza il problema da trovare la soluzione più semplice che funziona.

Per chi è all'inizio: quando ti viene voglia di aggiungere un'astrazione, un design pattern, o una generalizzazione "per il futuro", fatti questa domanda: c'è un requisito concreto e attuale che giustifica questa complessità? Se la risposta è no, non aggiungerla. Il refactoring futuro, quando il requisito arriverà, è sempre più facile da fare su codice semplice che su codice già sovra-astratto.

Cosa ha funzionato (Federico)

L'errore che ho descritto non si risolve con un singolo insight - si risolve con un cambiamento nel modo di stare nel lavoro. Queste sono le pratiche che hanno contribuito a questo cambiamento.

1. Trattare il primo anno come un anno di apprendimento

La prima cosa che ho cambiato - e che avrei voluto cambiare prima - è il modo in cui pensavo al primo anno di lavoro. Non come "anno in cui dimostro quello che so", ma come "anno in cui imparo quello che non so ancora e che non si impara altrove". Questo shift di prospettiva ha cambiato il rapporto con gli errori: non erano fallimenti da nascondere, ma segnali su dove concentrare l'apprendimento.

The Pragmatic Programmer di Hunt e Thomas (ISBN 978-0135957059) descrive bene questa mentalità con il concetto di "knowledge portfolio": il developer professionale investe sistematicamente nell'acquisizione di nuove competenze, come un investitore diversifica il portafoglio. L'investimento non si esaurisce con la formazione iniziale - è una pratica continua per tutta la carriera.

2. Chiedere code review sistematicamente

Una delle pratiche con il ROI più alto che ho adottato è stato chiedere code review sistematicamente - non solo quando era obbligatorio per il processo, ma proattivamente, anche su parti di codice che avevo già scritto. La code review è uno dei meccanismi più efficaci per ricevere feedback calibrato sulla qualità del proprio codice, per imparare pattern e convenzioni del team, e per esporre il proprio ragionamento tecnico a una verifica esterna.

Il costo psicologico di chiedere code review è reale, specialmente all'inizio: esponi il tuo codice a un giudizio che potrebbe rivelare errori o approcci sbagliati. Ma è esattamente questo il punto. La code review accelera l'apprendimento in modo molto più efficiente dello studio solitario, perché il feedback è specifico, contestualizzato, e immediato rispetto al codice che hai appena scritto.

3. Scrivere commit messages leggibili

Una delle prime cose concrete che ho imparato e che ha cambiato il modo in cui altri sviluppatori percepivano il mio lavoro è stata scrivere commit messages leggibili. Questo sembra un dettaglio tecnico secondario - non lo è. Un commit message chiaro racconta la storia di un cambiamento: cosa è cambiato, perché è cambiato, e cosa non è cambiato. È documentazione in tempo reale che altri sviluppatori usano per capire la storia del codice.

Il formato più semplice che raccomando: una prima riga che descrive il cambiamento in modo imperativo e specifico ("Add validation for email format in registration form"), seguita da una riga vuota e da una descrizione del motivo se non è ovvio ("Existing code accepted addresses without @ sign causing downstream failures in email service"). Non un paragrafo ogni volta - solo le informazioni necessarie per capire il commit senza leggere il codice.

4. Imparare a dire "non so, verifico e ti rispondo"

Un'altra pratica che ha cambiato la mia relazione con il lavoro è imparare a dire "non so, verifico e ti rispondo" invece di improvvisare una risposta plausibile per non apparire impreparato. Nei team tech, l'improvvisazione su domande tecniche ha costi reali: produce decisioni basate su informazioni non verificate, crea false aspettative, e quando viene scoperta danneggia la credibilità molto più di un "non so ma verifico" detto in modo diretto.

Ho impiegato del tempo a imparare questo. La pressione implicita a sembrare competenti - specialmente all'inizio, quando si percepisce che gli altri si aspettano molto - porta a rispondere con sicurezza anche quando quella sicurezza non è fondata. Il primo passo per uscire da questo pattern è riconoscerlo. Il secondo è fare pratica del discomfort di dire "non so" - che è molto più breve di quanto sembra, e molto meno dannoso di quanto si teme.

5. Costruire un sistema di note tecniche personale

Una pratica che ha avuto un impatto duraturo è tenere un sistema di note tecniche personale - non pubblico, non un blog, non documentazione formale. Un file di testo (o un sistema come Obsidian) dove annoto: problemi che ho risolto e come, pattern che ho imparato, errori che ho fatto e cosa ho cambiato, risorse che ho trovato utili. Questo sistema ha due funzioni. La prima è la memoria aumentata: quando incontro di nuovo lo stesso problema dopo mesi, ho già la soluzione annotata. La seconda è la riflessione: rileggere le note del mese scorso mostra il progresso in modo concreto e combatte l'impostor syndrome in modo diretto.

6. Calibrare la velocità di consegna

Un'altra cosa che ho imparato nel tempo è calibrare la velocità di consegna: capire qual è il ritmo sostenibile nel lungo periodo per produrre lavoro di qualità accettabile, e comunicare in modo proattivo quando qualcosa richiede più tempo del previsto. Nei primi anni tendevo a sottostimare i tempi - per ottimismo, per paura di sembrare lento, perché non avevo ancora un modello accurato di quanto tempo richiedono le cose. Il risultato erano consegne tardive che avrebbero potuto essere evitate con una stima più onesta dall'inizio.

La stima accurata dei tempi è una competenza che si sviluppa con l'esperienza, ma si può accelerare con un metodo: tenere traccia del tempo che ci vuole per fare le cose (non solo il tempo totale - il tempo effettivo di lavoro concentrato), e usare quel dato storico per calibrare le stime future. È sorprendente quanto sia diverso il tempo percepito dal tempo effettivo, e quanto questa distanza produca sottostime sistematiche.

Framework cognitivo

Due framework che mi hanno aiutato a capire l'errore descritto in modo più utile, trasformandolo da fonte di imbarazzo a fonte di dati.

Il ciclo di Dreyfus di acquisizione competenze

Il modello Dreyfus di acquisizione delle competenze descrive cinque livelli: principiante, principiante avanzato, competente, proficiente, esperto. Ogni livello ha caratteristiche specifiche nel modo in cui si affronta un problema. Il principiante segue regole rigide perché non ha il contesto per giudicare quale regola applicare quando. Il competente può gestire problemi nuovi usando principi, non solo regole. L'esperto agisce in modo intuitivo, senza dover applicare regole esplicitamente.

L'errore che ho descritto - confondere la conoscenza accademica con la competenza professionale - è essenzialmente un disallineamento nel modello Dreyfus: credevo di essere a un livello più avanzato di quello in cui ero. Applicare questo framework ha cambiato il modo in cui mi ponevo di fronte alle difficoltà: non "sono incompetente perché non risolvo questo problema come un esperto", ma "sono a questo livello specifico, e il passo successivo è questo".

Errori come sistema di apprendimento (Hunt e Thomas)

Hunt e Thomas in The Pragmatic Programmer (ISBN 978-0135957059) descrivono il developer professionista come qualcuno che tratta gli errori come dati, non come giudizi. Un errore dice qualcosa di specifico su dove c'è un gap tra il modello mentale e la realtà del sistema. Quel gap è informazione preziosa - molto più preziosa di una risposta giusta ottenuta senza capire perché era giusta.

La pratica concreta che ho derivato da questo framework: dopo ogni errore significativo - un bug in produzione, una code review difficile, un approccio che non ha funzionato - mi fermo e scrivo tre cose: cos'è successo, perché è successo (non a livello tecnico superficiale, ma al livello del modello mentale che era sbagliato), e cosa cambio di conseguenza. Questo trasforma l'errore da evento da dimenticare rapidamente in un investimento nel sistema di apprendimento.

Il concetto di "bugged code as learning opportunity"

Un framework meno formalizzato ma molto pratico: trattare ogni bug significativo come un'opportunità di imparare qualcosa sul sistema che non sapevi ancora. I bug non sono incidenti - sono la realtà del sistema che ti dice qualcosa che il tuo modello mentale non aveva previsto. I bug più frustranti sono quelli che rivelano assunzioni fondamentali che erano sbagliate - e che avrebbero portato problemi simili anche in futuro se non fossero stati incontrati prima.

Ho imparato a fare una distinzione tra bug "stupidi" (errori di digitazione, riferimenti a variabili sbagliate, off-by-one) e bug "rivelatori" (quelli che mostrano un gap nella comprensione del sistema). I bug stupidi non insegnano molto - capitano a tutti e si risolvono con attenzione. I bug rivelatori sono quelli da investigare in profondità, perché il pattern che hanno rivelato probabilmente si ripresenterà in forme diverse se non si capisce la radice.

Tenere una lista dei bug rivelatori incontrati nel tempo - con una breve descrizione del gap che hanno mostrato - è un'altra forma del sistema di note tecniche personale che ho descritto sopra. È anche uno dei documenti più utili da rivedere prima di un colloquio tecnico: mostra come il proprio modello mentale del sistema è cambiato nel tempo.

Letture e risorse

Queste sono le risorse che consiglio specificamente per navigare la transizione dalla formazione al lavoro professionale - un momento in cui la sindrome dell'impostore è spesso più intensa e in cui gli errori hanno conseguenze più visibili.

Libri fondamentali

• Andrew Hunt e David Thomas, The Pragmatic Programmer (ISBN 978-0135957059) - Il libro sul mestiere del developer professionale. Il capitolo "Your Knowledge Portfolio" è direttamente applicabile alle difficoltà del primo anno. Lo rileggo ogni anno - ogni volta trovo qualcosa di nuovo perché ho più contesto per capirlo.
• Robert C. Martin, Clean Code (ISBN 978-0132350884) - Il libro sulla scrittura di codice leggibile. Non un libro su algoritmi o architetture - un libro su come scrivere codice che altri developer possono capire, modificare, e mantenere. Rilevante dal primo giorno di lavoro.

Risorse online

• Ben Halpern, "Why Senior Devs Write Dumb Code" (DEV.to) - Un articolo breve e denso su uno dei paradossi del mestiere: i developer più esperti scrivono codice più semplice, non più complesso. La complessità non è un segnale di competenza.
• Joel Spolsky, "The Absolute Minimum Every Developer Must Know About Unicode" - Un esempio del tipo di conoscenza fondamentale che i developer acquisiscono nel lavoro reale, non nei corsi. Joel on Software è un archivio di saggezza pratica sul mestiere del developer.

Il CV template che ho preparato include tre esempi concreti di percorsi non convenzionali - con le sezioni che funzionano meglio per chi ha un background non lineare. Puoi scaricarlo gratuitamente qui sopra.

Prossimo passo nella serie

Il prossimo articolo - il quinto della serie - si chiama Networking introverso via email (non è LinkedIn). Non è un articolo sulla creazione di connessioni professionali in senso generico. È un articolo specifico su come costruire relazioni professionali meaningful partendo da email dirette, senza fingere entusiasmo per eventi di networking, senza LinkedIn personal branding performativo. Per molte persone con background non-CS che vengono da settori dove le relazioni professionali funzionano diversamente, questo è un tema molto concreto.

Puoi trovare tutti gli articoli della serie nella cornerstone della serie.

Vedi anche: Cosa farei oggi se ricominciassi da zero come developer - il terzo articolo della serie, che è il complemento operativo di questo: questo racconta l'errore, quello racconta il piano alternativo.

Cosa ho imparato scrivendo questo

Questo articolo è stato il più difficile dei quattro che ho scritto finora. Non tecnicamente - ma emotivamente. Scrivere di un errore che hai fatto in modo onesto, senza minimizzarlo e senza esagerarlo, richiede una calibrazione precisa. La tentazione è di andare in una di due direzioni: o il mea culpa esagerato ("ho fatto un errore gravissimo che ha avuto conseguenze terribili") o la minimizzazione ("alla fine non è stato poi così grave"). Entrambe le direzioni distorcono il racconto.

Ho cercato di stare nel mezzo: l'errore è stato reale, ha avuto conseguenze reali sulla qualità del lavoro che facevo nei primi anni, e quelle conseguenze sono state recuperabili nel tempo attraverso le pratiche che ho descritto. Non è una storia di trionfo - è una storia di aggiustamento progressivo. Che è, penso, il tipo di storia più onesto e più utile.

Una cosa che ho eliminato dalla prima bozza: una sezione sugli errori specifici che ho fatto in progetti specifici. L'ho tolta perché violava il vincolo D-07 - i progetti specifici in cui ho lavorato sono legati al mio contesto lavorativo attuale, e citarli avrebbe introdotto riferimenti che non voglio fare. Ma questo mi ha costretto a un esercizio utile: astrarli. Invece di "nel progetto X ho fatto l'errore Y", ho scritto "questo tipo di errore produce questo tipo di conseguenza". L'astrazione perde il colore narrativo ma guadagna in applicabilità: funziona per qualsiasi context, non solo il mio.

C'è qualcosa che ho capito nel processo di scrittura che vale la pena nominare: l'errore che ho descritto non è specifico di chi ha una laurea CS. Si fa dopo qualsiasi formazione intensa - bootcamp, master, lungo studio autodidatta. Il pattern è lo stesso: la formazione crea un senso di completezza che l'inizio del lavoro reale demolisce. La differenza tra chi recupera in fretta e chi fatica è la disposizione verso gli errori. Chi li tratta come dati avanza. Chi li tratta come verdetti ristagna.

Se hai fatto un errore simile - se hai confuso la conoscenza acquisita con la competenza professionale - e hai trovato un modo per uscirne, mi piacerebbe saperlo. Le storie di aggiustamento sono quelle che trovo più utili, perché mostrano che il percorso non è lineare e che questo va bene. Scrivimi a federico@federicocalo.dev.

Ti rispondo. Sempre.