Cosa farei oggi se ricominciassi da zero come developer

Background di partenza

Ricominciare da zero è un esercizio mentale che ogni developer fa almeno una volta, di solito a un punto della carriera in cui si guarda indietro e si vedono chiaramente le deviazioni, i vicoli ciechi, il tempo speso su cose che non servivano e quello non speso su cose che avrebbero aiutato molto prima. È un esercizio onesto e a volte scomodo - ma è anche uno degli strumenti più utili per capire cosa conta davvero.

Questo articolo è la risposta alla domanda: se domani mattina mi svegliassi senza nessuna delle competenze tech che ho adesso, sapendo quello che so adesso, cosa farei? Non ho la risposta perfetta - quella non esiste. Ho la risposta più onesta che riesco a dare, basata su quello che ho osservato funzionare in modo consistente, sia nel mio percorso sia in quello di molti altri developer che ho incrociato nel tempo.

La premessa di questo articolo è diversa da quella del precedente. Il secondo articolo della serie era retrospettivo: "cosa avrei voluto sapere". Questo è prospettico: "cosa farei". La differenza è che qui ci sono scelte e azioni concrete, non solo consapevolezze. Ogni sezione di questo articolo contiene almeno una decisione operativa - qualcosa che puoi fare, non solo pensare.

Se hai già letto i due articoli precedenti di questa serie, alcuni dei temi qui risuoneranno. Non li ripeto in dettaglio - invece li traduco in passi concreti. Il filo conduttore è sempre lo stesso: il percorso da background non-CS a developer non è un percorso casuale. Ha una struttura. Quella struttura si può imparare.

Una premessa sul timing: l'articolo parla di un percorso di 12 mesi, ma il percorso reale per molte persone è più lungo - soprattutto se non studi a tempo pieno. Se studi 2 ore al giorno in parallelo a un lavoro esistente, i 12 mesi del piano diventano 18-24 mesi. Non è un fallimento - è matematica. Il piano è scalabile: le fasi rimangono le stesse, le durate si allungano in proporzione al tempo disponibile. L'importante è non comprimere le fasi eliminando la pratica - che è il modo più comune in cui il piano si rompe. Si può allungare il tempo, ma non si può saltare la pratica.

Difficoltà tipiche

Le difficoltà nel pianificare un percorso di ripartenza non sono solo pratiche - sono anche cognitive. Il modo in cui si pensa al percorso influenza quello che si fa.

La falsa scelta tra teoria e pratica

Una delle tensioni più frequenti per chi inizia è la domanda: devo imparare prima la teoria (algoritmi, strutture dati, fondamenta informatiche) o la pratica (costruire qualcosa che funziona, anche con lacune teoriche)? La risposta giusta è: entrambe, in sequenza e in modo integrato - non come alternativa. La teoria senza pratica produce conoscenza astratta che non si consolida. La pratica senza teoria produce codice che funziona ma che non si capisce abbastanza da modificare o da estendere.

Il bilanciamento ottimale cambia in base agli obiettivi: chi vuole trovare lavoro nel breve termine ha un incentivo a pesare di più verso la pratica (portfolio, progetti deployati) perché il mercato del lavoro junior valuta quello. Chi vuole costruire competenza solida nel lungo termine ha un incentivo a non sacrificare le fondamenta. Il modo per fare entrambe le cose senza impazzire è alternare: una settimana con focus su fondamenta, una con focus su progetto pratico.

Il parallelismo delle opzioni di percorso

Un'altra difficoltà è la simultaneità di percorsi possibili. Frontend, Backend, Full-stack, Data Engineering, AI Engineering, DevOps - tutti sembrano possibili e nessuno sembra definitivo. La tentazione è di studiare un po' di tutto per avere opzioni. Il risultato, quasi invariabilmente, è arrivare al mercato del lavoro senza una competenza verticale chiara in nulla.

Il modo per uscire da questo parallelismo non è scegliere "per sempre" - quella scelta non esiste nel tech, dove le traiettorie cambiano spesso. È scegliere "per i prossimi 18 mesi" con l'intenzione di revisitare la scelta dopo. Questa distinzione riduce la pressione della decisione senza eliminare la necessità di farla.

Una metafora utile: scegliere un percorso tecnico è come scegliere una lingua da imparare. La scelta di imparare spagnolo non esclude di imparare anche il francese in futuro - ma se cerchi di imparare spagnolo e francese e tedesco contemporaneamente con lo stesso livello di intensità, finisci per non parlare bene nessuna delle tre. Il secondo linguaggio si impara molto più velocemente dopo aver costruito la fluenza nella prima. Lo stesso vale per i percorsi tech: scegli uno, costruisci la fluenza, poi espandi.

L'infodemia formativa

Il mercato della formazione tech è uno dei più saturi che esistano. Ci sono letteralmente decine di migliaia di corsi, bootcamp, libri, tutorial, youtube channel, newsletter, community. In questo scenario, la capacità di filtrare e di ignorare è più preziosa della capacità di trovare. Il 95% delle risorse disponibili è ridondante con il 5% che conta davvero. Il tempo speso a valutare risorse extra è tempo sottratto all'esecuzione delle risorse scelte.

Uno dei pattern che ho osservato con più frequenza è il "tutorial hopping": passare da un tutorial all'altro senza completarne nessuno, con la giustificazione che si sta cercando "quello giusto". Il tutorial giusto quasi sempre non esiste in senso assoluto - esiste il tutorial abbastanza buono che si finisce. Finire un tutorial mediocre produce più apprendimento di iniziare dieci tutorial eccellenti.

La disconnessione tra studio e portfolio

Un'altra difficoltà che osservo spesso: chi studia per mesi senza costruire nulla di pubblico, accumulando conoscenza teorica senza produrre evidenze concrete. La disconnessione tra studio e portfolio nasce dall'idea che il portfolio viene "dopo" - dopo che sei abbastanza bravo, dopo che hai finito il curriculum, dopo che ti senti pronto. Ma non ti senti mai abbastanza pronto finché non hai già qualcosa di pubblico che funziona. L'attesa produce un circolo vizioso che si rompe solo costruendo qualcosa - anche imperfetto, anche piccolo - e pubblicandolo.

Il portfolio non è la dimostrazione che hai finito di imparare. È il tracker in tempo reale di dove sei nel percorso. Un portfolio con 5 piccoli progetti che cresce nel tempo racconta una storia di crescita. Un portfolio con zero progetti finché non sei "pronto" non racconta nulla, perché il momento in cui sei pronto non arriva mai per definizione.

Cosa ha funzionato (Federico)

Questo è il cuore dell'articolo. Non è una roadmap generica - è quello che farei io, in quest'ordine, partendo da zero oggi.

1. Settimana 0: scegliere il percorso verticale

Prima di aprire qualsiasi editor, definirei il percorso. Non "voglio fare il developer" - "voglio fare il Frontend Developer / il Backend Developer / il Data Engineer". La scelta del percorso determina il curriculum, le risorse, il portfolio, i colloqui. Fatta questa scelta, tutte le decisioni successive diventano più semplici perché c'è un criterio: "Questo serve per il mio percorso? Sì → avanti. No → ignora."

Come scegliere? Il modo più pratico che conosco è guardare roadmap.sh, che raccoglie roadmap curate per ogni percorso tech, e leggere le prime 3-4 settimane di ciascuno dei percorsi che mi sembrano interessanti. Quello che leggo con più curiosità e meno fatica è probabilmente il segnale più onesto di dove investire tempo. Non è un criterio infallibile - ci sono percorsi che sembrano interessanti e poi si rivelano meno adatti, e percorsi che sembrano difficili all'inizio e poi diventano i più adatti. Ma è un punto di partenza sufficientemente buono per iniziare a muoversi.

2. Mesi 1-2: fondamenta + primo linguaggio

I primi due mesi li passerei su due risorse in parallelo: CS50 Harvard per le fondamenta concettuali e freeCodeCamp per la pratica applicata. CS50 dà il "perché" - come funziona un computer, cosa è un algoritmo, cosa sono le strutture dati. freeCodeCamp dà il "come" - sintassi, pattern, progetti.

Il primo linguaggio su cui mi concentrerei dipende dal percorso scelto: JavaScript per Frontend e Full-stack, Python per Backend e AI, Go o Java per Backend enterprise. Non cambierei linguaggio durante i primi due mesi - il rischio è usare il cambio di linguaggio come procrastinazione mascherata da strategia.

3. Mese 3: primo progetto pubblico

Al terzo mese costruirei il primo progetto pubblico su GitHub. Non il progetto migliore - il primo. Qualcosa di piccolo che risolve un problema reale, anche banale: un convertitore di unità di misura, un generatore di password, un semplice blog statico. Il requisito minimo è che sia deployed su internet (GitHub Pages è gratuito per i siti statici) e che il codice sia pubblico.

Il motivo per iniziare così presto con un progetto pubblico non è la qualità del progetto - sarà inevitabilmente imperfetto. È l'abitudine: costruire qualcosa, farlo funzionare, pubblicarlo, passare al prossimo. Questa abitudine produce il portfolio in modo naturale nel tempo, senza dover fare un "progetto portfolio" speciale alla fine della formazione.

4. Mesi 4-8: verticale tecnica + portfolio 3-5 progetti

Nei mesi centrali, il focus sarebbe sulla verticalizzazione nel percorso scelto: framework principali (React/Angular per Frontend, Spring Boot/FastAPI per Backend, dbt/Spark per Data), database (SQL è obbligatorio per tutti i percorsi, come secondo step), git workflow professionale (feature branches, pull request, code review). In parallelo, porterei il portfolio da 1 a 3-5 progetti di qualità crescente.

La regola sui progetti portfolio che ho imparato: ogni progetto deve rispondere a due domande. Prima: risolve un problema reale, anche piccolo? Seconda: il codice è leggibile da qualcuno che non lo ha scritto? Se la risposta a entrambe è sì, il progetto è adatto per il portfolio. Se la risposta è no a una delle due, va migliorato prima di essere mostrato.

5. Mesi 9-12: ricerca lavoro come secondo lavoro

Dopo 8-9 mesi di studio serio, inizierei la ricerca di lavoro attiva - non dopo aver "finito la formazione", perché la formazione non finisce mai. Il processo di ricerca lavoro per un developer junior richiede in media 3-6 mesi nel mercato italiano. Iniziare a mese 9 significa che la probabilità di essere assunti intorno a mese 12-15 è significativa. Iniziare a mese 18 sposta tutto di 9 mesi senza un motivo tecnico valido.

La ricerca lavoro la tratto come un secondo lavoro: 2-3 ore al giorno, con metriche tracciate (candidature inviate, risposte ricevute, colloqui, offerte), con iterazione basata sui feedback. I feedback dai colloqui - anche quelli andati male - sono dati preziosi su dove concentrare lo studio delle settimane successive.

6. Durante tutto il percorso: network attivo ma calibrato

Una cosa che farei dall'inizio, non come fase separata ma come pratica parallela costante, è costruire una presenza online minima ma attiva. Non una strategia di personal branding elaborata - qualcosa di molto semplice: un profilo GitHub aggiornato, qualche commento su DEV.to o Stack Overflow su argomenti che sto studiando, la partecipazione occasionale a community italiane di developer (GitBar ha una community Slack, esistono meetup locali in molte città).

Il motivo per iniziare presto non è la visibilità nel breve termine - quella è trascurabile all'inizio. È l'abitudine. Chi inizia a partecipare alle community da subito, anche in modo minimo, ha un vantaggio concreto quando inizia la ricerca di lavoro: ha già una rete, per piccola che sia. Chi inizia a partecipare solo quando cerca lavoro parte da zero in un momento in cui ha già molte altre priorità.

Il tempo da investire in questa dimensione è piccolo: 15-20 minuti al giorno, non di più. L'obiettivo non è diventare un influencer tech - è essere presente nella conversazione del settore, anche da ascoltatore all'inizio.

7. La preparazione al colloquio tecnico: iniziare presto

Una delle cose che farei diversamente rispetto al percorso che ho fatto è iniziare la preparazione ai colloqui tecnici molto prima di quanto sembra necessario. Il colloquio tecnico per un ruolo junior è un esame su algoritmi e strutture dati - contenuti che nei bootcamp e nei curriculum online vengono spesso trattati superficialmente, e che invece sono il focus principale del processo di selezione nelle aziende che fanno colloqui tecnici strutturati.

La risorsa standard per questa preparazione è Cracking the Coding Interview di Gayle Laakmann McDowell (ISBN 978-0984782857), ma il libro da solo non basta - va integrato con la pratica su piattaforme come LeetCode o HackerRank. Farei 1-2 problemi al giorno a partire dal mese 5-6, non aspetterei il mese 9-10. Due problemi al giorno per 3 mesi producono circa 180-200 problemi risolti - che è una base solida per la maggior parte dei colloqui junior.

Framework cognitivo

Due framework mentali che userei dall'inizio, non solo come filosofia ma come strumenti pratici di decisione.

Deep Work come modalità di studio (Newport)

Cal Newport in Deep Work (ISBN 978-1455586691) distingue tra lavoro profondo - concentrazione intensa su problemi cognitivamente difficili, senza distrazioni - e lavoro superficiale - task frammentati, email, notifiche, multitasking. Il valore economico del lavoro profondo è alto e in crescita. La capacità di farlo è rara e si deteriora se non si allena.

Applicato allo studio tecnico, questo significa: sessioni di studio senza telefono, senza notifiche, senza social. Non 20 minuti tra una distrazione e l'altra - 60-90 minuti di lavoro cognitivo denso su un problema specifico. Il rendimento per ora è incomparabilmente superiore. Se dovessi ricominciare, inizierei a praticare questa modalità dal primo giorno - non aspetterei di "avere più tempo".

Il sistema di revisione spaced repetition

Un framework pratico che integrerei subito è la spaced repetition per i concetti tecnici. Ogni concetto nuovo che incontro - un pattern di programmazione, una funzione della libreria, un comando Git - va in un sistema di revisione (Anki è gratuito) con due versioni: la domanda e la risposta. La revisione avviene a intervalli crescenti nel tempo. Il risultato è che i concetti che uso meno frequentemente rimangono accessibili, invece di scomparire dalla memoria attiva.

Sembra un overhead eccessivo all'inizio. Non lo è. Il tempo investito nella creazione delle card viene ripagato ogni volta che ti ricordi qualcosa che altrimenti avresti dovuto cercare di nuovo. Il compounding della memoria è altrettanto reale del compounding delle abitudini quotidiane.

Il principio dell'80/20 applicato allo studio tecnico

Un framework che avrei voluto conoscere prima è il principio di Pareto applicato all'apprendimento tecnico: l'80% dei problemi che incontrerai nel lavoro reale viene risolto con il 20% delle conoscenze teoriche disponibili. Questo non significa che il 80% rimanente sia inutile - significa che c'è un ordine di priorità nell'acquisizione delle conoscenze, e che studiare le cose più usate prima di quelle meno usate è una strategia razionale.

Per il Frontend Developer, il 20% che conta di più è: HTML semantico, CSS layout (Flexbox + Grid), JavaScript asincrono (Promises + async/await), una libreria o framework principale (React o Angular), e il ciclo Git base (commit, push, pull, merge). Con queste conoscenze si risolve l'80% dei problemi nel lavoro quotidiano di un junior. Il resto - TypeScript avanzato, performance optimization, architettura complessa, testing avanzato - viene aggiunto progressivamente sull'esperienza lavorativa, non necessariamente in anticipo.

L'implicazione pratica: smetti di studiare cose avanzate mentre ancora non padroneggi le basi. La tentazione di saltare alle tecnologie "cool" - GraphQL, WebAssembly, microservizi - quando ancora fatico con la gestione degli stati in React è una forma di procrastinazione tecnica. Il lavoro è profondità prima della larghezza, non il contrario.

Letture e risorse

Queste sono le risorse che userei, in questo ordine, se ricominciassi da zero. Non è una lista esaustiva - è una lista minima che copre i bisogni reali delle prime fasi.

Risorse strutturate per i primi 6 mesi

• roadmap.sh - Prima tappa: scegli il percorso, leggi la roadmap per esteso, identifica le prime 10 milestone. Non è un curriculum - è una mappa. Usala come orientamento, non come checklist da seguire alla lettera.
• CS50 Harvard - Fondamenta concettuali. Mesi 1-2, in parallelo alla pratica applicata. Il costo in tempo è 10-15 ore totali per le lecture principali - il ritorno è una comprensione dei fondamenti che dura anni.
• freeCodeCamp - Curriculum pratico per i mesi 1-4. Scegli il percorso corrispondente al tuo verticale. Fallo tutto - non saltare i moduli che sembrano banali.

Libri fondamentali

• Cal Newport, Deep Work (ISBN 978-1455586691) - Lo studio tecnico richiede concentrazione profonda. Questo libro insegna come coltivarla. Da leggere prima di iniziare, non dopo.
• Andrew Hunt e David Thomas, The Pragmatic Programmer (ISBN 978-0135957059) - Il manuale del developer professionista. Non sostituisce l'apprendimento tecnico, lo orienta. Un capitolo alla settimana mentre procedi con il curriculum.

La Guida studio 6 mesi che ho preparato è il piano dettagliato settimana per settimana di quello che farei - con le risorse specifiche per ogni settimana e i checkpoint di auto-valutazione. È quello che avrei voluto avere all'inizio. Puoi scaricarla gratuitamente qui sopra.

Risorse per la preparazione ai colloqui

• Gayle Laakmann McDowell, Cracking the Coding Interview (ISBN 978-0984782857) - Il riferimento standard per la preparazione ai colloqui tecnici. Non è da leggere dall'inizio alla fine come un libro - è da usare come workbook, facendo i problemi e controllando le soluzioni.
• LeetCode - La piattaforma per la pratica di algoritmi e strutture dati. Inizia dalla sezione "Easy" - i problemi "Hard" possono aspettare fino a quando non hai una base solida sugli "Easy" e "Medium".

Prossimo passo nella serie

Martedì prossimo esce il quarto articolo della serie: Il mio errore più grande dopo la laurea CS (e cosa ho imparato). È ancora un articolo io-narratore, ma con un focus specifico sugli errori - non come confessione, ma come fonte di dati. Gli errori raccontano dove le aspettative erano fuori calibrazione, e quelle aspettative sono spesso le stesse per tutti, indipendentemente dal background.

Se sei arrivato a questo articolo, hai letto già tre puntate della serie. Ogni articolo è autonomo - puoi leggerne uno senza gli altri. Ma la lettura sequenziale crea un filo narrativo che ha senso: dal perché (l'impostor syndrome) al cosa (le cose da sapere) all'operativo (cosa fare).

Puoi trovare tutti gli articoli della serie nella cornerstone della serie, dove c'è anche la career matrix completa con i 12 percorsi e i lead magnet scaricabili.

Vedi anche: Cosa avrei voluto sapere quando ho iniziato a programmare - il secondo articolo della serie, complementare a questo.

Cosa ho imparato scrivendo questo

Scrivere questo articolo è stato un esercizio di sintesi forzata. Il problema non era trovare il contenuto - era tagliare. Ho scritto e riscritto la sezione "Cosa mi ha funzionato" quattro volte, ogni volta togliendo qualcosa che in retrospettiva sembrava ovvio o che si sovrapponeva a cose già dette nei due articoli precedenti della serie.

Una cosa che ho capito nel processo: c'è differenza tra quello che ha funzionato per me e quello che funzionerebbe per me se ricominciassi adesso. Non è la stessa lista. Le risorse cambiano, le opportunità cambiano, le best practice cambiano. Quello che non cambia è la struttura: fondamenta prima della pratica avanzata, progetto pubblico prima di cercare lavoro, verticale tecnica chiara prima del generalismo. Su questi principi ho più fiducia.

Ho anche notato che le parti dell'articolo che ho trovato più difficili da scrivere sono quelle con consigli più forti - "smettila di fare questo, inizia a fare quello". Il tono prescrittivo è scomodo quando scrivi in prima persona, perché ogni persona ha il proprio contesto. La soluzione che ho trovato è sempre filtrare attraverso "questo è quello che farei io" - non "questo è quello che dovresti fare". La differenza è piccola nel testo, ma è grande nella responsabilità della dichiarazione.

Una cosa che ho tolto da una versione precedente di questo articolo: una sezione sulla motivazione. L'avevo scritta come terzo framework cognitivo - come mantenere la motivazione nel lungo periodo quando il percorso è lento e i risultati non si vedono subito. Ho deciso di toglierla perché non è il tipo di problema che si risolve con un framework. La motivazione si mantiene costruendo cose che funzionano, vedendo i progressi concreti, avendo una rete di persone che stanno facendo lo stesso percorso. Non si risolve con un articolo che spiega come mantenerla. Il miglior consiglio sulla motivazione è: costruisci la prima cosa pubblica il prima possibile, e lascia che l'evidenza concreta faccia il suo lavoro.

Una cosa che invece ho aggiunto rispetto alla prima bozza: la sezione sulla preparazione ai colloqui tecnici. Avevo paura che sembrasse troppo "meccanica" - come se ridurre la ricerca di lavoro a numeri e metriche togliesse qualcosa di umano al processo. Poi ho riflettuto e ho deciso di tenerla, perché è onesta. Il colloquio tecnico è un'abilità specifica che si allena, non un esame sulla "bontà" del developer. Trattarlo come un'abilità specifica - con pratica deliberata, feedback, iterazione - è rispettoso verso se stessi, non il contrario.

Se stai pianificando il tuo ricominciare - che sia da zero assoluto o da una formazione parziale - mi piacerebbe sapere dove sei adesso e cosa ti blocca. Non per darti risposte già confezionate, ma perché le domande specifiche aiutano a capire se gli articoli che scrivo rispondono ai problemi 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.