L'impostor syndrome non finisce mai (ed è normale)

Background di partenza

Ho scoperto che la sindrome dell'impostore non finisce mai in un momento molto preciso della mia carriera. Non all'inizio, quando avevo pochi mesi di esperienza e ogni sessione di code review mi sembrava un esame orale da cui potevo uscire smascherato. Era in un momento successivo, quando avevo già anni di lavoro in produzione, avevo già risolto problemi reali, avevo già contribuito a decisioni architetturali che avevano funzionato. Eppure, seduto in una riunione con persone più esperte di me su un dominio specifico, quella voce familiare era ancora lì: "Non sai abbastanza. Stai per fare una figura pessima. Prima o poi ti scoprono."

Quel momento è stato una rivelazione scomoda. Avevo implicitamente creduto che la sindrome dell'impostore fosse una fase passeggera - qualcosa che ti accompagna all'inizio, quando il gap tra quello che sai e quello che dovresti sapere è palpabile, e che poi scompare con il tempo e l'esperienza. Non è così. La ricerca psicologica lo dice chiaramente, l'esperienza vissuta lo conferma.

Ne parlo in questo primo articolo della serie per una ragione precisa: se sei arrivato allo sviluppo software da un percorso non convenzionale - giurisprudenza, economia, filosofia, matematica pura, letteratura - la tua relazione con la sindrome dell'impostore è probabilmente più intensa e più frequente di quella di un developer con background CS. Non perché tu sia meno capace. Ma perché hai un punto di confronto implicito che è già in svantaggio: "Gli altri hanno la laurea giusta. Io no." Questo pensiero, se non viene esaminato, diventa il terreno fertile in cui la sindrome cresce.

Quello che voglio fare in questo articolo è togliere di mezzo alcune illusioni - compresa quella per cui la sindrome finisce, prima o poi - e sostituirle con un framework più onesto e più utile: non come eliminare la sindrome dell'impostore, ma come conviverci in modo che non blocchi il tuo lavoro e la tua crescita.

Questo non è un articolo motivazionale. Non troverai qui la tecnica infallibile per "sconfiggere" l'impostor syndrome. Non esiste. Troverai invece una mappa del territorio, con alcune pratiche concrete che per me hanno fatto differenza.

Difficoltà tipiche

La sindrome dell'impostore per chi viene da background non-CS si manifesta in modi specifici e riconoscibili. Vale la pena nominarli per quello che sono, senza minimizzarli ma anche senza amplificarli.

Il confronto asimmetrico con chi ha la "laurea giusta"

Il meccanismo è questo: vedi un collega con laurea magistrale in informatica che capisce al volo un concetto di architettura distribuita, e pensi "lui lo sa già. Io devo ancora capirlo." Quello che non vedi è che anche lui, nel suo dominio di provenienza, ha bisogno di tempo per acquisire contesti che tu hai già - la capacità di analisi contrattuale, il pensiero critico filosofico, la modellazione economica. Il confronto è asimmetrico perché stai guardando la sua barra verticale consolidata e ignorando la tua barra orizzontale già costruita.

Pauline Clance e Suzanne Imes, nel paper del 1978 che ha definito il concetto di "imposter phenomenon" per la prima volta, hanno osservato questo meccanismo in persone ad alto rendimento: il focus selettivo sulle proprie lacune e l'incapacità di internalizzare i propri successi come genuini. Il risultato è una distorsione cognitiva sistematica che porta a sottovalutare costantemente la propria competenza reale.

Il vocabolario come barriera psicologica

Nei team tech esiste un gergo consolidato che i developer CS hanno assorbito durante gli anni di studio: "race condition", "debito tecnico", "refactoring", "contratto dell'API", "idempotenza". Se arrivi da un background diverso, queste parole le impari durante il lavoro, spesso a posteriori rispetto a quando vengono usate nelle conversazioni. Ogni volta che incontri un termine che non conosci e gli altri sembrano dare per scontato, scatta il pensiero: "Avrei dovuto saperlo."

Questo crea una forma di ansia da performance linguistica che va oltre il contenuto tecnico. Non è l'algoritmo che non sai implementare - è la sensazione di non parlare ancora fluentemente la lingua del posto. E questa sensazione, se non viene riconosciuta per quello che è, alimenta l'impostor syndrome in modo trasversale, indipendente dal contenuto tecnico reale.

Il "test della scrivania" inverso

In molti team tech esiste una variante implicita del "test della scrivania": quando qualcuno spiega qualcosa e tu non capisci, la tua prima reazione è dubitare di te stesso, non della spiegazione. Chi ha background CS tende ad avere più fiducia nel proprio ragionamento: se la spiegazione non è chiara, è la spiegazione il problema. Chi viene da background non-CS tende a invertire l'attribuzione: se non capisco, sono io il problema.

Questo ha una conseguenza pratica: fai meno domande, non perché le domande non ci siano, ma perché fare una domanda significa rivelare una lacuna, e rivelare una lacuna significa essere scoperti. Il risultato è che resti in uno stato di confusione più a lungo, e la confusione alimenta ulteriormente la sensazione di non essere al passo.

La buona notizia è che questo meccanismo è reversibile. L'abilità di fare domande precise e tempestive si allena come qualsiasi altra abilità professionale. E nei team sani - quelli in cui vale la pena lavorare - fare buone domande viene percepito come un tratto positivo, non come un segnale di debolezza. Il problema non è fare domande: è non saperle fare bene. Una domanda vaga ("non capisco come funziona il sistema") è meno utile di una domanda specifica ("non capisco perché questo endpoint torna 200 anche quando la validazione fallisce - ho letto il codice ma non vedo dove viene gestito questo caso"). La specificità della domanda segnala che hai già pensato al problema e che la tua lacuna è precisa, non generica.

I momenti di crisi apparente

Ci sono momenti specifici in cui la sindrome dell'impostore si intensifica in modo acuto: la prima code review difficile, il primo bug critico in produzione, il primo colloquio tecnico senior, la prima volta che sei invitato a fare una presentazione tecnica davanti a persone che percepisci come più competenti di te. Questi momenti non sono distribuiti uniformemente nel tempo - si concentrano nei momenti di transizione, quando il livello di responsabilità o di visibilità aumenta.

Per chi viene da background non-CS, questi momenti hanno una carica emotiva aggiuntiva: c'è sempre il rischio implicito di confermare il sospetto che il percorso non convenzionale fosse un problema. "Se sbaglio questa cosa, dimostra che non avevo le basi giuste." Il fallimento viene caricato di un significato identitario che va oltre il singolo episodio.

Quello che ho imparato nel tempo è che questi momenti di crisi apparente sono anche momenti di apprendimento accelerato - a patto di attraversarli invece di evitarli. Il bug critico in produzione che hai risolto a fatica ti insegna più di dieci tutorial teorici sullo stesso argomento. La code review difficile che ti ha costretto a riscrivere metà del tuo codice ti ha insegnato qualcosa che non avresti imparato in nessun altro modo. Il colloquio tecnico andato male è un feedback preciso su dove devi studiare di più. La sindrome dell'impostore tende a fare sì che questi momenti vengano archiviati come fallimenti. Il lavoro alternativo è archiviarli come dati.

La sindrome dell'impostore nei colloqui tecnici

Il colloquio tecnico è il contesto in cui la sindrome dell'impostore si manifesta in modo più acuto per chi viene da background non-CS. Non solo perché i colloqui tecnici sono stressanti per definizione, ma perché il formato - domande su algoritmi e strutture dati, problemi di coding su whiteboard o editor online - è ottimizzato per valutare esattamente le competenze che chi ha una formazione CS ha consolidato in anni di studio. Per chi viene da un percorso diverso, questo formato è oggettivamente svantaggioso, almeno nelle prime fasi.

La risposta a questa difficoltà non è pensare che il formato sia ingiusto (anche se in parte lo è) ma prepararsi in modo sistematico, come farebbe qualsiasi altro candidato che sa di avere lacune in un'area specifica. Ma per farlo, devi prima riconoscere che la difficoltà è reale e specifica, non una conferma della tua inadeguatezza generale.

Cosa ha funzionato (Federico)

Condivido alcune pratiche concrete che hanno fatto differenza per me. Non le propongo come ricetta universale - le persone sono diverse, i contesti sono diversi. Le propongo come punto di partenza, qualcosa da testare e adattare.

1. Separare il processo dall'identità

La prima pratica è cognitiva: imparare a distinguere tra "sto imparando qualcosa che ancora non so" e "non sono abbastanza bravo". La prima affermazione descrive uno stato del processo formativo - temporaneo, modificabile, normale. La seconda è un giudizio identitario - statico, totalizzante, e molto spesso falso.

La distinzione sembra ovvia finché non provi a applicarla in tempo reale, nel mezzo di una code review difficile o di un debug su un sistema che non capisci ancora. In quei momenti, la voce dell'impostore parla in giudizi identitari, non in descrizioni processuali. Il lavoro è notare quando succede e riformulare: "Non conosco ancora questo pattern" invece di "Non sono abbastanza tecnico/a".

Cal Newport in So Good They Can't Ignore You (ISBN 978-1455509126) descrive questo come il shift da "seguire la passione" a "costruire competenza": il focus si sposta dalla domanda "sono abbastanza bravo/a?" alla domanda "cosa devo imparare per fare meglio questo?" Il secondo tipo di domanda è azionabile. Il primo no.

2. Tenere un log di evidenze concrete

La sindrome dell'impostore prospera sulla vaghezza. Se ti chiedi "ho fatto progressi nell'ultimo anno?", la tua mente tenderà a selezionare le evidenze negative - i problemi che non hai risolto, le cose che non sai ancora - e a minimizzare quelle positive. Il contromisura è rendere il progresso concreto e visibile.

Ho iniziato a tenere un file di testo - non pubblico, solo per me - dove scrivo una volta alla settimana: un problema che ho risolto questa settimana, una cosa che ho imparato, una situazione in cui ho contribuito positivamente. Non per mostrarlo a qualcuno: per controbattere la tendenza della mente a selezionare solo le evidenze negative.

Dopo sei mesi, rileggere quel file è stato un'esperienza rivelante. Il progresso c'era, era documentato, era specifico. La sindrome dell'impostore lavora sull'astrazione e sulla vaghezza - "non so abbastanza" - ma non regge il confronto con dati concreti.

3. Usare la confusione come segnale di apprendimento

Una delle riframings più utili che ho fatto è stata imparare a leggere la confusione come un segnale positivo invece che negativo. La confusione significa che stai confrontandoti con qualcosa che ancora non padroneggi - il che è esattamente quello che dovresti fare se vuoi crescere.

I developer che non si confondono mai stanno lavorando su cose che sanno già fare. È confortante a breve termine, ma è stagnazione a lungo termine. La confusione produttiva - quella che si risolve con studio, esplorazione, e domande - è la materia prima dell'apprendimento. Imparare a distinguerla dalla confusione paralizzante (quella che si manifesta come blocco e incapacità di procedere) richiede pratica, ma è un'abilità sviluppabile.

4. Fare le domande, sistematicamente

Una delle cose che ho imparato a fare nel tempo è alzare la mano sistematicamente quando non capisco qualcosa, invece di aspettare di capirla da sola. Non in modo indiscriminato - ci sono domande che vale la pena fare dopo essersi sforzati di rispondere da soli. Ma quella tendenza a non fare domande per non rivelare lacune è precisamente il meccanismo che mantiene la sindrome dell'impostore in piedi.

Quello che ho scoperto è che fare buone domande - domande precise, su un punto specifico, dopo aver già provato a rispondere da soli - viene percepito nei team buoni come un segnale di competenza, non di ignoranza. I developer senior che rispetto di più fanno molte domande. Non perché non sappiano le risposte, ma perché sanno che fare le domande giuste è parte del mestiere.

5. Trovare un contesto di confronto realistico

La sindrome dell'impostore si alimenta spesso del confronto con persone che sono molti anni avanti nel percorso. Se ti confronti con un senior developer di 10 anni di esperienza quando ne hai 2, stai usando un metro di misura sbagliato. Non perché la crescita non sia possibile, ma perché il confronto non è informativo: misura la distanza attuale, non la traiettoria.

Il confronto più utile è con te stesso di 6 mesi fa. La domanda non è "so quello che sa lui?", ma "so più di quello che sapevo?" Se la risposta è sì - e nella grande maggioranza dei casi lo è - il segnale è che il processo funziona, anche se il risultato non è ancora quello che vorresti.

Framework cognitivo

Oltre alle pratiche concrete, ci sono due framework teorici che mi hanno aiutato a capire la sindrome dell'impostore in modo più utile - non solo come esperienza soggettiva, ma come meccanismo psicologico con una struttura precisa.

Career capital e competenza percepita (Newport)

Cal Newport in So Good They Can't Ignore You distingue tra competenza oggettiva - le skill reali che hai acquisito attraverso la pratica deliberata - e competenza percepita - la valutazione soggettiva che hai di te stesso. La sindrome dell'impostore è essenzialmente un disallineamento tra le due: la competenza oggettiva è più alta di quella percepita.

Il problema è che la competenza percepita è influenzata da fattori che non hanno nulla a che fare con la competenza oggettiva: il contesto di confronto scelto, la narrazione che ti racconti sul tuo percorso, la tendenza a internalizzare i fallimenti e a esternalizzare i successi ("il progetto è andato bene per fortuna", "il bug era complicato perché non avevo studiato abbastanza"). Newport suggerisce che la risposta non è "lavorare sull'autostima" in modo generico, ma costruire evidenze oggettive di competenza attraverso la pratica deliberata, e imparare a leggerle correttamente.

Fixed mindset vs growth mindset (Dweck)

Carol Dweck nel suo lavoro sul growth mindset descrive due modi opposti di interpretare le proprie capacità. Il fixed mindset vede le capacità come attributi fissi - "sei bravo/a in matematica" o "non sei portato/a per il codice" - e interpreta le difficoltà come evidenza di queste caratteristiche fisse. Il growth mindset vede le capacità come sviluppabili attraverso lo sforzo e la pratica, e interpreta le difficoltà come parte del processo di apprendimento.

La sindrome dell'impostore è intimamente legata al fixed mindset: "Se sbaglio questa cosa, significa che non sono abbastanza bravo/a" funziona solo se le capacità sono fisse. In un framework di growth mindset, sbagliare una cosa significa che c'è qualcosa da imparare, non che sei identificato da quel fallimento.

Per chi viene da background non-CS, il fixed mindset sul codice è particolarmente frequente: la narrativa "non ho la laurea CS quindi alcune cose non le capirò mai" è una versione estrema del fixed mindset applicata a un'intera categoria di competenze. Il dato empirico - decine di developer eccellenti con background non convenzionali documentabili - falsifica questa narrativa in modo diretto.

L'impostor phenomenon: la ricerca originale

Clance e Imes nel 1978 hanno osservato il fenomeno in donne ad alto rendimento accademico che, nonostante i successi oggettivi, continuavano a percepirsi come "impostori" sul punto di essere smascherati. Da allora, la ricerca ha esteso il fenomeno a popolazioni molto più ampie: è trasversale per genere, background, livello di istruzione, e settore professionale.

Un dato particolarmente rilevante per questo articolo: la sindrome dell'impostore tende a intensificarsi nei momenti di transizione e in nuovi contesti, non a diminuire con l'esperienza in assoluto. Ogni volta che entri in un nuovo team, prendi una nuova responsabilità, o ti confronti con un dominio tecnico nuovo, la sindrome si riattiva. Non è una patologia - è una risposta a un ambiente di incertezza. Il problema non è eliminarla, ma imparare a non lasciarsi bloccare da essa.

La ricerca di Gill Corkindale su HBR (2008) identifica alcune strategie che si correlano con la gestione efficace del fenomeno: parlarne con altri, tenere traccia dei successi reali, distinguere tra "fare una cosa perfettamente" e "fare una cosa bene abbastanza", e accettare che ci sono cose che non sai ancora senza interpretarle come evidenza di inadeguatezza.

Letture e risorse

La sindrome dell'impostore è un tema su cui esiste molta letteratura psicologica e molta letteratura motivazionale di bassa qualità. Ho cercato di separare le due categorie e di segnalare solo le risorse che trovo genuinamente utili e ancorate alla ricerca reale.

Libri fondamentali

• Cal Newport, So Good They Can't Ignore You (ISBN 978-1455509126) - Il framework del career capital come risposta alla sindrome dell'impostore. Newport argomenta che l'autostima professionale si costruisce attraverso la competenza reale, non attraverso l'auto-convincimento. Obbligatorio.
• Carol Dweck, Mindset: The New Psychology of Success (ISBN 978-0345472328) - La ricerca sul fixed vs growth mindset. Il capitolo sul mondo del lavoro è particolarmente applicabile al contesto del developer non-CS.
• Cal Newport, Deep Work (ISBN 978-1455586691) - La costruzione di competenza profonda come contromisura all'impostor syndrome. Newport mostra come la pratica deliberata produce evidenze concrete di crescita.

Risorse online gratuite

• Gill Corkindale, "Overcoming Imposter Syndrome" (HBR, 2008) - L'articolo più utile che conosco sulla sindrome dell'impostore in contesto professionale. Breve, pratico, non motivazionale.
• Clance e Imes (1978): "The Imposter Phenomenon in High Achieving Women" - Il paper originale. Vale la pena leggere l'abstract e le conclusioni anche se il corpo è accademico. Normalizza il fenomeno in modo potente.
• Madhuri Ramesh, "How I dealt with impostor syndrome as a self-taught developer" (DEV.to) - Una testimonianza diretta di una developer autodidatta. Riconoscibile e pratica.

Se stai costruendo la tua formazione in modo autonomo, la Guida studio 6 mesi che ho preparato include un framework settimanale progettato anche per gestire i momenti di stallo e di dubbio che inevitabilmente arrivano. Puoi scaricarla gratuitamente qui sopra.

Prossimo passo nella serie

Questo è il primo articolo cluster della serie. Parla di un tema trasversale che riguarda tutti i background, indipendentemente da dove vieni. Nelle prossime settimane, la serie si ramifica su temi più specifici.

Martedì prossimo esce il secondo articolo: Cosa avrei voluto sapere quando ho iniziato a programmare - un inventario onesto delle cose che ho imparato troppo tardi e che avrei voluto che qualcuno mi dicesse all'inizio. È ancora un articolo io-narratore, orientato ai temi universali piuttosto che ai background specifici.

Se vuoi ricevere ogni articolo direttamente nella tua casella email, puoi iscriverti alla newsletter qui sotto. Un numero ogni martedì. Nessuna sequenza automatizzata.

Torna alla cornerstone della serie per avere la visione completa dei 20 articoli in programma e della career matrix con i 12 percorsi.

Cosa ho imparato scrivendo questo

Scrivere un articolo sulla sindrome dell'impostore è un'esperienza particolare. Mentre scrivi, la voce dell'impostore commenta: "Chi sei tu per scrivere su questo?" È una meta-ironia che non sfugge.

Ma è anche, in un certo senso, la risposta a quella voce: scrivi comunque. Non perché sei certo di avere tutte le risposte - non ce le ho. Ma perché hai qualcosa di concreto da condividere, qualcosa che viene dall'esperienza diretta e dalla riflessione su quella esperienza. E la voce dell'impostore non è una ragione sufficiente per non farlo.

Una cosa che ho chiarito scrivendolo è la distinzione tra "gestire la sindrome dell'impostore" e "liberarsene". Ho eliminato diverse versioni di questo articolo che promettevano la seconda cosa - perché quella promessa è falsa, e le false promesse sono il tipo di contenuto che non voglio produrre. L'obiettivo onesto è la gestione: imparare a convivere con quella voce in modo che non detti le decisioni, non blocchi le azioni, non rovini il lavoro.

Un'altra cosa che ho chiarito è il tono. Avevo scritto alcune parti in modo troppo direttivo - "devi fare X", "non devi fare Y". Le ho riscritte in prima persona, perché quello che posso dire con certezza è quello che ha funzionato per me, non quello che funzionerà per tutti. Il contesto conta, le persone sono diverse, le situazioni variano. Quello che posso offrire è la mappa, non il percorso.

Ho fatto una scelta deliberata di non citare casi specifici di persone che conosco direttamente - colleghi, mentori, amici che hanno attraversato questa transizione. Non per mancanza di storie, ma perché il rispetto per la privacy di chi mi ha condiviso le proprie esperienze vale più del valore illustrativo di un aneddoto. Le storie che ho citato nell'articolo sono da fonti pubbliche, documentate, con persone che hanno scelto di raccontarle.

Un'ultima cosa che ho imparato: la sindrome dell'impostore non è uguale per tutti. Le sue manifestazioni dipendono dal contesto, dal background, dalla personalità, dal tipo di team in cui si lavora. Quello che ho descritto in questo articolo è la versione che ho osservato con più frequenza in developer con background non-CS nel mercato italiano. Ma ci sono varianti. Se la tua esperienza è diversa da quello che ho descritto - se riconosci il fenomeno ma non le specifiche modalità - probabilmente la tua versione è altrettanto valida e altrettanto gestibile. Il punto di partenza è sempre lo stesso: nominare quello che succede, senza giudicarlo.

Se riconosci qualcosa di quello che ho descritto - se la voce dell'impostore è parte della tua esperienza quotidiana - mi piacerebbe saperlo. Non per raccogliere testimonianze, ma per capire se i temi che sto affrontando nella serie rispondono a domande reali. Scrivimi a federico@federicocalo.dev.

Ti rispondo. Sempre.

Se stai iniziando ad usare strumenti come Claude Code per compensare il gap di formazione formale, ho raccolto in una serie dedicata il workflow agentico che uso quotidianamente sul portfolio: Claude Code Workflow: Superpowers + GSD framework. È il sistema che mi permette di gestire 19 fasi parallele senza un team di sviluppo dietro.