Non-CS Developer Track: percorso, autostima e consigli pratici

Background di partenza

Veniamo subito al sodo: ho una laurea in Informatica all'Università degli Studi di Bari Aldo Moro e un diploma in Sistemi Informativi Aziendali ottenuto all'Istituto Tecnico Commerciale di Maglie. Sulla carta, sono un percorso classico. Nella realtà vissuta, il percorso universitario di informatica non è stata la spinta propulsiva che immagini guardandolo da fuori. È stato un percorso lungo, con materie astratte che ho faticato a connettere al lavoro reale, con periodi di stallo che mi hanno messo in discussione più di una volta, e con quella costante sensazione di non essere abbastanza tecnico rispetto ai colleghi che sembravano muoversi nel codice come se fosse la loro lingua madre.

Quello che ho capito solo in retrospettiva è che quella fatica non era una mia mancanza. Era la distanza naturale tra la formazione teorica e il mestiere pratico dello sviluppatore. Una distanza che esiste per tutti, con o senza laurea CS. La differenza è che chi viene da informatica ha almeno la terminologia, i concetti base di algoritmica e strutture dati già processati. Ma il gap tra "sapere" e "fare" rimane grande per tutti, senza eccezioni.

Il mio primo anno lavorativo da developer junior è stato caratterizzato dalla stessa sindrome dell'impostore che sento descrivere ogni giorno da persone che vengono da giurisprudenza, economia, filosofia, lettere. "Non so abbastanza." "Gli altri capiscono al volo e io ho bisogno di rileggere tre volte." "Quando scopriranno che non so la metà delle cose che pensano?" Queste frasi le conosco da dentro. Le ho vissute io stesso, con una laurea CS in tasca.

Questo mi ha insegnato qualcosa di fondamentale: il background conta, ma non è il fattore determinante. Conta il metodo, l'abitudine allo studio, la capacità di resistere alla frustrazione e di imparare dagli errori senza smettere di muoversi. Questi sono pattern transferable da qualsiasi background. E su questi pattern ho costruito la serie che stai leggendo.

Scrivo questo articolo perché credo che ci sia un vuoto enorme nella conversazione italiana sul tema "diventare developer da background non-CS". Ci sono molte guide teoriche, molti "corsi online in 6 settimane", molti percorsi che promettono di trasformarti in uno sviluppatore in 90 giorni. Quello che manca è la prospettiva onesta di chi ha percorso la strada, con le difficoltà reali, i tempi reali, e le lezioni apprese nel mezzo.

Questa serie prova a colmare quel vuoto. Non è una promessa di scorciatoie. È una mappa del territorio.

Vale la pena essere chiari anche su cosa significa "background non-CS" in questo contesto. Non intendo solo chi ha una laurea umanistica. Intendo chiunque arrivi al mondo dello sviluppo software senza una formazione formale specifica in informatica o ingegneria del software: giuristi, economisti, filosofi, letterati, linguisti, matematici puri, designer, biologi, medici, insegnanti, artigiani, comunicatori. Ognuno di questi background porta con sé un insieme di competenze e di abitudini mentali che sono risorse, non ostacoli - a patto di sapere come valorizzarle.

Ho avuto la fortuna di parlare nel tempo con persone che hanno fatto questa transizione da ogni tipo di punto di partenza. Un giurista che oggi è lead backend developer in una startup fintech. Una filosofa che lavora come technical writer per una società di software tedesca. Un economista che ha costruito uno dei migliori portfolio di data engineering che ho visto su GitHub. Storie diverse, percorsi diversi, ma con pattern comuni che mi hanno convinto che ci sono cose che funzionano e cose che non funzionano - e che vale la pena raccontarle in modo sistematico.

Un'ultima nota prima di entrare nel vivo: questa serie è pensata per il mercato italiano ed europeo, ma con un occhio costante al mercato globale, in particolare quello statunitense dove i salari sono significativamente più alti e dove si trova la maggior parte delle offerte di lavoro remote per developer senior. Per ogni percorso di carriera ho incluso i salari medi in tre contesti: Italia, Europa (media UE), e USA - non per dirti dove devi andare, ma per darti la mappa completa e lasciarti decidere.

Difficoltà tipiche di chi viene da background non-CS

Prima di entrare nei percorsi specifici, vale la pena nominare le difficoltà che attraversano quasi tutti i background non-CS, indipendentemente dalla provenienza. Le ho ricavate sia dalla mia esperienza diretta sia da decine di storie che ho raccolto nel tempo, e da testimonianze pubbliche di persone che hanno fatto questa transizione documentandola online.

1. Mancanza della forma mentis algoritmica

Chi viene da giurisprudenza, filosofia, lettere o scienze politiche è abituato a ragionare in modo argomentativo: si parte da una premessa, si sviluppa una tesi, si costruisce un caso. Il ragionamento algoritmico è diverso: è decomposizione di un problema in passi discreti, ciascuno con input e output definiti, con gestione esplicita di tutti i casi limite. Non è migliore né peggiore, è diverso. E questa differenza può creare attrito nelle prime settimane di studio.

La buona notizia è che si acquisisce. Non serve un gene speciale. Serve esposizione ripetuta e pratica su problemi reali, non su esercizi accademici astratti.

2. Gap matematici specifici

Il livello di matematica richiesto dipende fortemente dal percorso scelto. Per Frontend Developer o Technical Writer, il gap è minimo: logica booleana, basi di algebra, pensiero computazionale. Per AI Engineer o ML Researcher, il gap è significativo e richiede un investimento formativo dedicato di mesi, non settimane. La cattiva notizia è che molte guide online minimizzano questo punto. La buona notizia è che Khan Academy esiste, è gratuita, e copre tutto quello che serve per la maggior parte dei percorsi pratici.

3. Sindrome dell'impostore strutturale

Nei team tech esiste una cultura implicita dove si dà per scontato un certo vocabolario: "fare un deploy", "rompere la build", "aprire una PR", "fixare un bug in produzione". Chi entra senza background CS si trova in un contesto dove ogni conversazione ha un layer di terminologia che gli è parzialmente opaca. Questo produce una forma persistente di insicurezza che non è irrazionale - è una risposta a un ambiente dove molte cose non hai ancora modo di capire del tutto. Col tempo passa. Ma nei primi mesi può essere estenuante.

Zubin Pratap, che ha abbandonato la carriera da avvocato per diventare ingegnere software in Google, ha descritto questa sensazione con grande precisione: non è stupidità, è gap temporaneo di contesto. Passa con l'esposizione.

4. Isolamento culturale nei team prevalentemente tech

I team di sviluppo software sono spesso omogenei per background formativo: la maggioranza ha una formazione tecnica o quantitativa. Chi arriva da scienze umane, dal diritto o dall'economia si trova spesso a essere l'unico con quel tipo di formazione nel team. Questo può portare a una forma sottile di isolamento culturale: le conversazioni off-topic tendono a essere su argomenti tech, i riferimenti condivisi sono spesso di quel mondo. Non è necessariamente un problema serio, ma merita di essere nominato come fonte di attrito.

5. Onboarding bootcamp spesso superficiale

I bootcamp di coding sono uno strumento utile ma imperfetto. Il loro vantaggio è la struttura: qualcuno ha già organizzato il curriculum in modo sequenziale, ti dà feedback regolare, e ti mette in un contesto dove si lavora tutti sullo stesso problema. Il loro limite è che in 12-16 settimane non puoi diventare uno sviluppatore senior. Puoi acquisire le basi sintattiche e costruire qualche progetto dimostrabile, ma il livello di comprensione profonda di strutture dati, algoritmi, database, e sistemi distribuiti che il mercato si aspetta da un developer mid-level richiede anni, non mesi.

La trappola frequente è uscire dal bootcamp credendo di essere "pronti", trovare la ricerca del lavoro molto più difficile del previsto, e interpretare quella difficoltà come un fallimento personale. Non è così. È una questione di aspettative mal calibrate dalla narrativa del bootcamp. Il percorso reale richiede più tempo - e questa è una buona notizia, perché significa che non c'è nessuna scorciatoia mancata. C'è solo il passo successivo da fare.

C'è un sesto tipo di difficoltà che vale la pena nominare, anche se è meno ovvia delle altre: la difficoltà di spiegare il proprio percorso non-lineare ai recruiter e ai hiring manager. Il CV di un developer che viene da giurisprudenza o da lettere ha una struttura che non assomiglia al CV standard del developer con formazione CS. Questo crea attrito nelle prime fasi del processo di selezione. La buona notizia è che questo attrito diminuisce significativamente man mano che si accumula esperienza lavorativa tech - e che nel frattempo il portfolio pubblico è lo strumento più efficace per aggirarlo.

Fernanda Penna Ribeiro, che ha abbandonato la carriera da avvocata per diventare backend engineer, descrive il processo di intervista come il momento più difficile della transizione: non perché non sapesse le risposte tecniche, ma perché il modo in cui raccontava il proprio percorso sembrava strano agli intervistatori abituati a pattern più convenzionali. Con il tempo, ha imparato a raccontare il percorso come un vantaggio - e lo è diventato.

Cosa ha funzionato (Federico)

Dopo anni di esperienza diretta e di osservazione di molti percorsi altrui, posso identificare alcune pratiche che tendono a funzionare in modo consistente per chi costruisce competenze da developer, indipendentemente dal punto di partenza.

1. Reading list curata, non casuale

Il problema della formazione autodidatta non è la mancanza di risorse - ce ne sono troppe. Il problema è scegliere. La maggior parte del tempo degli autodidatti viene sprecata a passare da una risorsa all'altra, senza mai approfondire nulla abbastanza da poterlo applicare. La soluzione è avere una reading list definita in anticipo, con un percorso sequenziale e milestone concrete.

Ho preparato una reading list curata con le 10 risorse che raccomando a chi parte da zero o quasi. La trovi nel PDF scaricabile qui sotto.

2. Side project portfolio: 3-5 progetti pubblici

Il portfolio è l'unico modo per dimostrare competenze in assenza di esperienza lavorativa formale. Ma non vale qualsiasi progetto: vale un progetto che risolve un problema reale, che è deployed su internet (non solo in locale), e che ha codice pubblico su GitHub che un recruiter o un tech lead può leggere.

Il numero ottimale per un junior developer in ricerca di lavoro è 3-5 progetti. Meno di 3 è troppo poco per far vedere ampiezza. Più di 5 rischia di diluire il segnale: meglio pochi progetti curati che molti incompleti o superficiali.

Syk Houdeib, che è passato da un background non tecnico a developer in 10 mesi, descrive il portfolio come la discriminante chiave nella sua ricerca di lavoro: le aziende non guardavano il suo background formativo, guardavano il codice che aveva scritto.

3. Pair programming con un senior

C'è un tipo di apprendimento che i libri e i corsi online non replicano: guardare qualcuno con più esperienza affrontare un problema reale, in tempo reale. Il pair programming - lavorare fianco a fianco su un task, con qualcuno che fa mentre tu osservi, e poi si inverte - è uno degli strumenti di apprendimento più potenti che conosco.

Se lavori già in un'azienda, cerca di fare pair programming il più spesso possibile con i colleghi senior. Se stai ancora studiando, cercalo nei programmi di mentorship, nelle community open source (molti maintainer sono disposti a fare pair programming con contribuenti interessati), o nei gruppi di studio locali.

4. Journaling tecnico quotidiano

Ogni giorno in cui impari qualcosa di nuovo, scrivi tre cose: cosa hai capito oggi, cosa non hai capito ancora, il passo concreto che farai domani per avanzare. Questa pratica sembra banale ma ha effetti concreti su tre fronti: consolida la comprensione (spiegare in parole proprie è il test della comprensione reale), crea un registro del progresso (utile nei momenti di dubbio), e allena l'abitudine alla riflessione sistematica che è uno dei tratti dei developer migliori che ho incontrato.

5. Lasciarsi tempo

La carriera da developer si costruisce in anni, non in mesi. I percorsi più brevi che conosco - persone che sono passate da zero a assunti come junior in meno di un anno - sono eccezioni che richiedono condizioni particolari: studio full-time, mentorship attiva, talento e fortuna nella ricerca di lavoro. Il percorso medio è più lungo, e questo va bene.

Il pericolo della narrativa accelerazionista dei bootcamp e dei corsi online ("Junior Developer in 90 giorni") è che crea aspettative irrealistiche che, quando non vengono soddisfatte, vengono interpretate come fallimento personale. Non lo è. È semplicemente il tempo che richiede costruire una competenza reale.

6. Accettare la frustrazione come segnale

La frustrazione non è il segnale che stai fallendo. È il segnale che stai imparando qualcosa che ancora non padroneggi - il che è esattamente quello che dovresti fare. Il punto in cui smetti di provare è il punto in cui smetti di imparare. Imparare a leggere la frustrazione come informazione utile ("questo argomento richiede più tempo") invece che come sentenza ("non sono portato per questo") è uno dei cambi mentali più importanti che puoi fare.

Framework cognitivo per developer non-CS

Oltre alle pratiche concrete, ci sono tre framework mentali che trovo particolarmente utili per chi costruisce una carriera da developer da un punto di partenza non convenzionale.

Career capital (Cal Newport)

Nel libro So Good They Can't Ignore You (ISBN 978-1455509126), Cal Newport argomenta contro l'idea che la carriera ideale si trovi "seguendo la propria passione". L'alternativa che propone è il concetto di career capital: competenze rare e preziose che si accumulano nel tempo attraverso la pratica deliberata, e che poi si possono "spendere" per ottenere le condizioni lavorative che si desiderano - autonomia, missione, impatto.

Per il developer non-CS, questo framework è liberatorio: non devi "amare il codice" per costruire una carriera solida. Devi costruire competenze reali, progressivamente, con metodo. Il lavoro viene prima della passione, non viceversa. E le competenze che porti dal tuo background precedente - analisi legale, pensiero critico filosofico, modellazione economica, comunicazione delle lettere - sono capital già accumulato che si trasferisce nel dominio tech più di quanto pensi.

Compounding daily practice (Newport + Clear)

Due libri si integrano perfettamente su questo punto. Deep Work di Cal Newport (ISBN 978-1455586691) sostiene che la capacità di concentrazione profonda su problemi difficili è sempre più rara e sempre più preziosa. Atomic Habits di James Clear (ISBN 978-0735211292) spiega come i piccoli miglioramenti quotidiani si compongono nel tempo in maniera non lineare.

Applicati insieme, questi framework suggeriscono una pratica concreta: 1-2 ore di studio profondo al giorno, ogni giorno, senza distrazioni, su un problema specifico e progressivamente più difficile. Non 5 ore il sabato. Non 20 minuti tra una notifica e l'altra. Un'ora densa, tutti i giorni. Il compounding fa il resto.

T-shaped skills (generalista + specialista)

Il modello delle T-shaped skills descrive un profilo professionale dove si ha profondità in un'area (la barra verticale della T) e larghezza superficiale in molte altre aree (la barra orizzontale). Per un developer non-CS, questo significa: scegli un percorso principale dove costruire competenza profonda (Frontend? Backend? Technical Writing?), e mantieni una comprensione funzionale di 4-5 aree adiacenti.

Il vantaggio per i non-CS è che la barra orizzontale è spesso già lì, costruita negli anni di formazione precedente. Un ex-giurista che diventa developer porta con sé una comprensione del ragionamento contrattuale, della gestione dei casi limite, della comunicazione formale - competenze trasversali che molti developer CS non hanno. Il lavoro è costruire la barra verticale tech senza perdere la barra orizzontale già posseduta.

Un esempio concreto: un economista che diventa data engineer porta con sé una comprensione intuitiva di cosa significa una distribuzione statistica, di come interpretare un trend, di cosa si cerca quando si analizzano dati aggregati. Questi non sono skills tech, ma sono competenze rare nei team di data engineering dove spesso le persone sanno costruire le pipeline ma non sanno cosa dovrebbero trovare nei dati. La barra verticale si costruisce. La barra orizzontale che porti già vale oro.

Camila Moura, che ha fatto la transizione dal background umanistico allo sviluppo software, descrive questo trasferimento di competenze con precisione: la capacità di analisi critica dei testi, di costruire argomenti complessi, di comunicare idee difficili in modo accessibile - queste competenze hanno un valore reale nel tech, specialmente in ruoli che richiedono di tradurre requisiti complessi in specifiche tecniche implementabili.

Letture e risorse essenziali

Dopo anni di studio e di osservazione dei percorsi di altri, ho ristretto la lista alle risorse che raccomando senza riserve a chi parte da background non-CS. Ho deliberatamente escluso risorse che richiedono di sapere già qualcosa di tecnico per essere fruibili: tutto quello che trovi qui funziona come punto di ingresso, non come integrazione di conoscenze già acquisite.

Un avvertimento preliminare sulle risorse online: il panorama cambia rapidamente. Quello che era il miglior corso di Frontend nel 2022 potrebbe essere obsoleto nel 2026. Ho verificato la qualità e l'aggiornamento di queste risorse prima di includerle, ma ti consiglio di fare una ricerca autonoma sullo stato attuale prima di investire tempo significativo in una specifica piattaforma.

Libri fondamentali

• Cal Newport, So Good They Can't Ignore You (ISBN 978-1455509126) - Il framework del career capital applicato alla costruzione di una carriera tech. Obbligatorio come primo passo mentale.
• Cal Newport, Deep Work (ISBN 978-1455586691) - La metodologia di studio profondo. Il modo in cui studi conta quanto quello che studi.
• Andrew Hunt e David Thomas, The Pragmatic Programmer (ISBN 978-0135957059) - Il manuale di mestiere dello sviluppatore professionista. Leggibile anche senza conoscere il codice in anticipo.
• James Clear, Atomic Habits (ISBN 978-0735211292) - Il libro sul compounding delle abitudini quotidiane. Applicato alla formazione tecnica, è un cambio di paradigma.
• Gayle Laakmann McDowell, Cracking the Coding Interview (ISBN 978-0984782857) - Il riferimento per la preparazione ai colloqui tecnici. Non per leggerlo tutto, ma per capire cosa aspettarsi.

Risorse gratuite online

• freeCodeCamp - Curriculum completo e gratuito per Frontend Developer, dalla base assoluta ai progetti certificati. Il punto di partenza standard che raccomando.
• CS50 Harvard - Il corso di introduzione all'informatica di Harvard, gratuito online. Fornisce le fondamenta concettuali che molti bootcamp saltano.
• Coursera: Code Yourself (Università di Edimburgo) - Introduzione alla programmazione pensata specificamente per chi non ha background tecnico. Ritmo gentile, ottima per il primo approccio.
• Vaidehi Joshi su DEV.to - Becoming a SWE series - Serie di articoli di una developer autodidatta sulla transizione verso il software engineering. Onesta, pratica, e molto ben scritta.
• GitBar Podcast (italiano) - Il podcast italiano sul mondo dello sviluppo software. Ottimo per abituarsi al vocabolario del settore e capire il contesto del mercato IT italiano.

Prossimo passo nella serie

Questo articolo è il cornerstone della serie: il punto di partenza che mappa il territorio e fornisce il framework mentale per orientarsi. Da qui, la serie si ramifica in due direzioni.

La prima direzione è per background: 8 articoli dedicati a giurisprudenza, matematica, economia, filosofia, lettere, lingue, scienze politiche e design. Ogni articolo racconta casi reali (citati con il consenso degli interessati o da fonti pubbliche), le difficoltà specifiche di quel background, e le risorse più adatte.

La seconda direzione è per percorso di carriera: 12 articoli che approfondiscono ciascuno dei path della career matrix - Frontend, Backend, AI Engineer, Data Engineer, DevOps, Mobile, Technical Writer, Security, Engineering Manager, SRE, ML Researcher, Solution Architect. Ogni articolo ha i prerequisiti dettagliati, le tappe, le risorse, e la trappola tipica per chi viene da background non-CS.

Ogni martedì esce un nuovo numero. Iscriviti qui sotto per riceverlo direttamente nella tua casella email. Nessuna sequenza automatizzata: Federico scrive quando ha qualcosa di utile da dire.

Cosa ho imparato scrivendo questo

Scrivere la cornerstone di una serie è un esercizio strano. Devi capire prima cosa vuoi dire nell'arco di 20 settimane, e poi devi comprimere quella visione in un articolo che funzioni da solo, come punto di ingresso, senza presupporre nulla di ciò che verrà dopo.

Il processo mi ha costretto a chiarire alcune cose che tenevo implicite. La prima: questa serie non è per "aspiranti developer" in astratto. È per persone che hanno già un background costruito in altro campo e stanno valutando se e come costruirne uno nel tech. La sfumatura conta. Chi viene da giurisprudenza con 5 anni di pratica legale ha già una forma mentis che si trasferisce - non è un principiante assoluto, è qualcuno che deve reimparare alcuni strumenti e acquisirne di nuovi.

La seconda cosa che ho chiarito è il tono. Ho riletto molte volte l'introduzione cercando di eliminare ogni forma di paternalismo. Il rischio quando scrivi su "come fare X" è scivolare nel registro del guru che illumina i meno illuminati. Non è quello che voglio fare. Voglio scrivere come un collega che ha già percorso la strada e ti mostra la mappa, sapendo bene che la strada la percorri tu.

La terza cosa: la serie è pensata per durare. Non è un contenuto usa-e-getta ottimizzato per i motori di ricerca. È qualcosa che voglio aggiornare nel tempo man mano che il mercato cambia, che ricevo storie dai lettori, e che imparo di più su cosa funziona davvero per chi fa questa transizione.

Se hai già percorso in parte questa strada - o se stai iniziando proprio ora - mi piacerebbe sapere dove ti trovi. Cosa ha funzionato, cosa non ha funzionato, cosa vorresti trovare in questa serie che non trovi altrove. 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.