Cosa avrei voluto sapere quando ho iniziato a programmare

Background di partenza

Quando ho iniziato a programmare in modo serio, non avevo nessuna mappa. Avevo la curiosità - quella c'era tutta - ma non avevo un framework per capire come organizzare l'apprendimento, cosa studiare prima e cosa dopo, quanto tempo aspettarsi che una cosa richiedesse prima di diventare fluente. Navigavo a vista, e la navigazione a vista ha dei costi: si finisce spesso in vicoli ciechi, si perde tempo su cose che non servono nel breve termine, si tralascia cose fondamentali perché non si sa che lo sono.

Questo articolo è quello che avrei voluto leggere in quel momento. Non è una guida di studio - per quella c'è la Guida studio 6 mesi scaricabile qui sotto. È qualcosa di più personale: una lista di cose che avrei voluto che qualcuno mi dicesse esplicitamente, che ho invece dovuto imparare nel modo difficile, spesso dopo aver già perso tempo e fatto errori evitabili.

Alcune di queste cose sembrano ovvie in retrospettiva. Le cose ovvie in retrospettiva sono quasi sempre le stesse cose che nessuno ti dice all'inizio, perché chi le sa già dà per scontato che tu le sappia. Non è arroganza - è una forma di cecità cognitiva. Una volta che sai qualcosa, è difficile ricordare come era non saperlo. Questo articolo è un tentativo di attraversare quella cecità e parlare all'io che ero all'inizio.

Una nota sul tono: non scrivo questo articolo con l'intento di lamentarmi del tempo perso o di chi non mi ha detto queste cose. Il percorso è stato quello che è stato, e mi ha portato dove sono adesso. Scrivo con l'intento di trasferire ciò che ho imparato in modo utile per chi è all'inizio. Il resto è irrilevante.

Questo articolo è la seconda puntata della serie. Non presuppone di aver letto la prima, ma se vuoi il contesto completo, la cornerstone della serie raccoglie tutti gli articoli e la career matrix con i 12 percorsi. Se hai già letto il primo articolo sull'impostor syndrome, alcune cose di questo risuoneranno come continuazione naturale - perché lo sono.

Difficoltà tipiche

Le difficoltà che ho incontrato all'inizio non erano tutte tecniche. Alcune delle più impattanti erano meta-difficoltà: problemi nel modo in cui stavo apprendendo, non nel contenuto di quello che stavo imparando.

Paralisi da scelta delle risorse

Il primo problema enorme è stato la quantità di risorse disponibili. Tutorial, corsi, libri, video, bootcamp, documentazioni ufficiali - il panorama è vastissimo e non esiste una mappa chiara. Ho passato settimane a valutare opzioni invece di usare una sola opzione e andare avanti. Ogni volta che sentivo parlare di una risorsa potenzialmente migliore di quella che stavo usando, ero tentato di cambiare. Il risultato era un apprendimento frammentato, senza progressione lineare, senza consolidamento.

La paralisi da scelta delle risorse è un problema reale e sottovalutato. Non perché le risorse siano cattive - la maggior parte delle risorse mainstream sono buone - ma perché il passare da una risorsa all'altra impedisce di raggiungere la profondità necessaria perché i concetti si consolidino. Il cervello impara attraverso la ripetizione e il collegamento tra concetti, non attraverso l'esposizione superficiale a molte fonti diverse.

Il mito del "piano perfetto"

Un'altra trappola frequente all'inizio è cercare il piano di studio perfetto prima di iniziare. Ho letto decine di guide su "come diventare developer in N mesi", ho costruito roadmap dettagliate settimana per settimana, ho fatto confronti tra bootcamp e auto-studio, tra linguaggi di programmazione diversi come primo passo. Tutto questo tempo lo stavo usando per procrastinare l'inizio reale.

Il piano di studio perfetto non esiste. Esiste un piano abbastanza buono che si aggiusta nel tempo in base a quello che si impara. Il piano si corregge mentre si esegue - non si trova prima di iniziare. Aspettare di avere il piano perfetto è una forma di procrastinazione mascherata da diligenza.

L'isolamento dello studio solitario

Ho studiato da solo per molto tempo, senza nessuno con cui confrontarmi, senza codice altrui da leggere, senza feedback esterno. L'isolamento dello studio solitario ha un costo specifico: sviluppi abitudini e pattern che possono essere sbagliati senza saperlo, perché non hai un punto di confronto. Il codice che scrivi funziona - ottimo - ma è scritto in modi che nessuno che lavora in un team professionale accetterebbe.

La cosa che avrei voluto sapere è che esistono risorse per uscire dall'isolamento anche prima di avere un lavoro tech: community online come DEV.to, programmi di open source per contribuenti junior, meetup locali, hackathon, coding bootcamp anche brevi solo per il valore del confronto con altri. Lo studio solitario va bene per fasi specifiche, ma l'esposizione al codice altrui è fondamentale prima di quanto pensi.

C'è anche una dimensione psicologica dell'isolamento che ho sottovalutato: quando studi da solo, non hai feedback su quanto stai progredendo rispetto agli altri che stanno imparando le stesse cose. Questo non significa che il confronto con gli altri sia necessario - non lo è in senso competitivo. Ma vedere qualcuno che ha iniziato nello stesso periodo e che ha fatto progressi simili ai tuoi è un ancoraggio alla realtà che quando studi da solo non hai. Senza quell'ancoraggio, è facile sovrastimare la propria lentezza o sottostimare la propria crescita.

La confusione tra consumare e imparare

Una difficoltà sottile ma importante è la tendenza a confondere il consumo di contenuti formativi con l'apprendimento reale. Guardare 20 ore di video-corsi in una settimana non è imparare. Leggere 3 capitoli di un libro tecnico senza aprire l'editor non è imparare. Il consumo di contenuti è la fase zero - è necessaria, ma non sufficiente.

Il momento in cui avviene l'apprendimento reale è quando provi a fare qualcosa da solo, incontri un problema, cerchi come risolverlo, lo risolvi, e poi ci sei passato abbastanza che quella conoscenza è tua. Questo processo richiede attrito: la frustrazione di non riuscire subito, la ricerca di soluzioni, il tentativo-errore. Il consumo passivo di contenuti non produce attrito, e senza attrito non c'è apprendimento consolidato.

La regola pratica che ho iniziato ad applicare: per ogni ora di tutorial o corso, almeno un'ora di pratica autonoma sullo stesso argomento. Non seguire il tutorial mentre guardi - costruire qualcosa di simile da zero, senza copiare, usando solo quello che hai capito. Se non riesci, è un segnale che non hai capito così bene come pensavi. E questo è informazione utile.

Cosa ha funzionato (Federico)

Alcune cose hanno funzionato meglio di altre. Le raccolgo qui in ordine approssimativo di impatto, ma l'ordine è soggettivo - il contesto conta.

1. Scegliere una risorsa e finirla

La cosa più impattante che ho fatto, in un certo punto del percorso, è stata scegliere una risorsa e finirla prima di passare alla successiva. Sembra banale ma non lo è: la pressione a cambiare risorsa è costante, alimentata dall'abbondanza di opzioni e dalla sensazione che ci sia sempre qualcosa di migliore. Resistere a quella pressione e completare quello che si è iniziato è un'abilità in sé.

Per la formazione web base, freeCodeCamp è il curriculum che raccomando: gratuito, completo, con progetti pratici certificabili. Ma il curriculum conta meno della disciplina di finirlo. Qualsiasi curriculum buono, finito, vale più di cinque curriculum ottimi abbandonati a metà.

2. Costruire qualcosa di reale ogni settimana

A un certo punto ho smesso di cercare il progetto perfetto su cui lavorare e ho iniziato a costruire qualcosa ogni settimana, qualunque cosa. Un generatore di numeri casuali. Un convertitore di temperature. Un sito personale con CSS minimale. Un parser di file CSV. Piccolo, banale, ma reale: codice che girava, che faceva qualcosa, che potevo mostrare.

Il valore di costruire cose reali non è solo tecnico. È psicologico: ogni cosa che funziona è un'evidenza concreta di progresso. Sono queste evidenze che contrastano la voce dell'impostore nel lungo periodo - non i pep talk, non la motivazione astratta. Codice che funziona.

3. CS50 Harvard come fondamenta concettuali

CS50 di Harvard, disponibile gratuitamente online, è il corso che raccomando come primo fondamento concettuale per chi parte da zero. Non perché insegni il linguaggio "giusto" - insegna C e Python, che non sono necessariamente i linguaggi con cui lavorerai - ma perché insegna come pensare ai problemi computazionali: cosa è una variabile, cosa è un algoritmo, cosa sono le strutture dati, perché certe soluzioni sono più efficienti di altre.

Queste fondamenta concettuali mi mancavano, e la loro assenza si faceva sentire ogni volta che dovevo ragionare su un problema non banale. Avevo imparato la sintassi prima della semantica - il come prima del perché. CS50 inverte quest'ordine nel modo giusto.

4. Leggere codice altrui sistematicamente

Una cosa che nessuno mi ha detto esplicitamente è che leggere codice scritto da altri sviluppatori - buono, professionale, in produzione - è una delle forme di apprendimento più efficaci disponibili. Non leggere tutorial su come scrivere codice. Leggere codice reale, con i suoi compromessi, le sue convenzioni, i suoi pattern, le sue imperfezioni.

GitHub è la biblioteca più grande di codice pubblico che esiste. Ho iniziato a leggere repository di progetti che usavo - librerie, framework, tool - per capire come erano costruiti internamente. All'inizio capivo poco. Poi un po' di più. Col tempo, leggere codice altrui è diventato uno degli strumenti principali per imparare pattern che non avrei trovato nei libri.

5. Atomic Habits applicato allo studio tecnico

Atomic Habits di James Clear (ISBN 978-0735211292) è il libro sull'accumulo di abitudini piccole che si compongono nel tempo. La sua applicazione allo studio tecnico è diretta: 30 minuti di codice ogni giorno, senza eccezioni, vale significativamente più di 4 ore una volta alla settimana. Il compounding delle abitudini quotidiane è reale - e il codice scritto ogni giorno si accumula in modo non lineare.

La cosa concreta che ho implementato da questo libro: ho definito un orario fisso ogni giorno per lo studio, ho rimosso ogni attrito che poteva far saltare quella sessione (computer già aperto con il file pronto, nessuna decisione da prendere su cosa fare), e ho tracciato ogni sessione su un calendario a vista. L'identità da developer si costruisce un giorno alla volta, non in blocchi intensivi.

6. Specializzarsi presto, non aspettare

Una delle cose che avrei voluto capire prima è che nel mondo dello sviluppo software non c'è un modo per "imparare tutto" - e che aspettare di avere una comprensione completa prima di scegliere una direzione è una trappola. La specializzazione non è una chiusura: è una strategia per costruire competenza reale in un tempo ragionevole.

La pressione a conoscere tutto - frontend e backend e database e cloud e sicurezza e machine learning - è reale, ma è anche paralizzante. Il developer che conosce un po' di tutto senza approfondire nulla è difficile da piazzare nel mercato del lavoro rispetto a chi ha una competenza verticale chiara e una comprensione orizzontale sufficiente a collaborare con gli altri. Scegliere un percorso specifico - anche se imperfetto, anche se si cambia idea dopo - è meglio che restare nel limbo del generalista indeciso.

Il modo pratico per scegliere: qual è il tipo di problema che trovi più interessante risolvere? Se la risposta è "costruire interfacce che funzionano bene per le persone", Frontend. Se è "costruire sistemi che gestiscono dati in modo efficiente", Backend o Data Engineering. Se è "costruire cose che si comportano in modo intelligente", AI Engineering. Non è una scelta definitiva - si cambia spesso nel corso della carriera. Ma è un punto di partenza con cui muoversi.

7. Imparare a leggere la documentazione ufficiale

Una skill che ho sottovalutato per lungo tempo è la capacità di leggere la documentazione ufficiale dei linguaggi e dei framework che uso. I tutorial spiegano come usare un tool in scenari preconfigurati. La documentazione ufficiale spiega come funziona il tool in tutti gli scenari, compresi quelli che il tutorial non copre.

Passare dai tutorial alla documentazione diretta è un salto cognitivo non banale - la documentazione è spesso più densa, meno narrativa, più tecnica nel linguaggio. Ma è anche il modo per uscire dalla dipendenza dai tutorial e sviluppare l'autonomia di cercare soluzioni in modo diretto. Ogni volta che incontri un problema che il tutorial non copre, hai due opzioni: cercare un altro tutorial, o imparare a usare la documentazione. La prima opzione scala male nel lungo periodo. La seconda no.

Framework cognitivo

Due framework mi hanno aiutato a organizzare il modo in cui pensavo all'apprendimento tecnico, e continuano a influenzare il modo in cui mi avvicino a cose nuove.

Pratica deliberata vs pratica casuale (Newport + Ericsson)

Non tutta la pratica è uguale. La ricerca di Anders Ericsson - resa nota al grande pubblico da Newport in So Good They Can't Ignore You (ISBN 978-1455509126) - distingue tra pratica casuale (fare la stessa cosa che sai già fare, ancora e ancora, per accumulare ore) e pratica deliberata (lavorare specificamente sul limite della tua competenza attuale, su problemi che ti forzano a imparare qualcosa di nuovo, con feedback immediato).

Per lo sviluppo software, questo si traduce in una domanda concreta: sto lavorando su cose che mi sfidano, o sto lavorando su cose che so già fare? Il comfort è necessario per consolidare - ma se stai solo nel comfort, stai accumulando ore senza costruire competenza reale. Il discomfort produttivo - il momento in cui sei alle prese con qualcosa che ancora non padroneggi - è dove avviene la maggior parte dell'apprendimento.

Il principio dello scaffolding cognitivo

La pedagogia moderna parla di scaffolding come di una struttura temporanea di supporto che permette di costruire competenze che poi reggono da sole. Nel contesto dell'auto-studio tecnico, lo scaffolding sono le risorse strutturate - corsi, libri, tutorial - che ti guidano passo per passo attraverso un contenuto che non potresti affrontare da solo senza un percorso.

Il rischio è diventare dipendenti dallo scaffolding: studiare solo attraverso risorse strutturate, senza mai provare a fare cose non guidate. Lo scaffolding va rimosso progressivamente: si parte dal tutorial guidato, si passa al progetto semi-guidato (con documentazione ma senza istruzioni passo passo), si arriva al progetto completamente autonomo dove devi trovare da solo le risorse di cui hai bisogno. Questo progressivo allontanamento dallo scaffolding è quello che produce l'autonomia reale.

Questo framework mi ha aiutato a capire perché molti autodidatti restano bloccati a un certo livello: continuano a fare tutorial quando avrebbero bisogno di togliere il tutorial e costruire da soli. Il passo successivo non è un tutorial più avanzato - è costruire qualcosa senza tutorial.

Il costo dell'imparare da fonti random vs percorsi curati

Una cosa che non capivo all'inizio è il costo dell'apprendimento non strutturato. Quando impari da fonti casuali - un video qui, un articolo lì, un tutorial là - ogni fonte ha la sua terminologia, le sue convenzioni, il suo modo di presentare i concetti. Il risultato è un insieme di conoscenze frammentate che non si connettono in modo coerente.

La differenza tra un percorso curato e la navigazione libera non è la qualità delle singole risorse - è la progressione. Un curriculum ben progettato introduce i concetti in ordine: prima le fondamenta, poi le strutture più complesse costruite su quelle fondamenta. La navigazione libera introduce i concetti in ordine casuale, e quando arrivi a qualcosa di avanzato senza avere le basi, le basi diventano un debito cognitivo che rallenta l'avanzamento.

Il mio consiglio pratico: per le prime basi (il primo linguaggio, i fondamentali del web, i concetti base dell'informatica), scegli un curriculum strutturato e seguilo fino in fondo. Dopo aver completato le basi, la navigazione libera diventa uno strumento efficace - perché hai il contesto per mettere ogni nuova informazione nel posto giusto. Prima di avere quel contesto, la navigazione libera è costosa in termini di tempo e di coerenza del sapere acquisito.

Letture e risorse

Queste sono le risorse che avrei voluto conoscere dall'inizio, non dopo anni di navigazione a vista. Le ho selezionate per il rapporto qualità/tempo e per l'applicabilità immediata.

Curriculum e risorse strutturate

• freeCodeCamp - Il curriculum web development gratuito più completo disponibile online. Dal HTML/CSS base al JavaScript, alle librerie frontend, ai test, alle API. Ha il vantaggio di essere strutturato con progressione logica e certificazioni verificabili. Non è necessario fare tutto il curriculum - anche solo i moduli Responsive Web Design e JavaScript Algorithms and Data Structures coprono le basi essenziali per la maggior parte dei percorsi frontend. Il punto di ingresso che raccomando per chi parte da zero.
• CS50 Harvard - Fondamenta concettuali dell'informatica, gratis. Non è un corso di web development - è un corso su come pensare come un informatico. La differenza è importante. Raccomando di farlo prima o in parallelo a freeCodeCamp, non dopo.

Libri fondamentali

• Andrew Hunt e David Thomas, The Pragmatic Programmer (ISBN 978-0135957059) - Il manuale del mestiere dello sviluppatore professionista. Non è un libro tecnico nel senso stretto - non insegna un linguaggio specifico. Insegna come pensare al proprio lavoro come developer: come apprendere, come fare debugging, come scrivere codice mantenibile, come comunicare in un team. Leggibile anche all'inizio, ma sempre più denso di senso con l'esperienza.
• James Clear, Atomic Habits (ISBN 978-0735211292) - Non è un libro tecnico, ma è probabilmente il libro che ha impattato di più il mio modo di studiare. Il framework delle abitudini piccole che si compongono nel tempo è la risposta pratica alla domanda "come faccio a trovare tempo per studiare ogni giorno quando ho già una vita piena di impegni?".

Ho preparato una reading list curata con 50 risorse annotate per developer da background non-CS - libri, corsi, podcast, blog, con note su quando e perché usarli. Puoi scaricarla gratuitamente qui sopra in cambio dell'iscrizione alla newsletter.

Prossimo passo nella serie

La settimana prossima esce il terzo articolo della serie: Cosa farei oggi se ricominciassi da zero come developer. È la versione operativa di quello che hai appena letto: non "cosa avrei voluto sapere" in modo retrospettivo, ma "cosa farei concretamente, passo per passo, se dovessi ripartire da zero oggi, con quello che so adesso".

La differenza tra i due articoli è importante: questo parla di consapevolezze, il prossimo parla di azioni. Uno è orientativo, l'altro è operativo. Se questo articolo ti ha dato una mappa, il prossimo ti dà un percorso.

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

Vedi anche: L'impostor syndrome non finisce mai (ed è normale) - il primo articolo di questa serie, su come convivere con la sindrome dell'impostore senza che blocchi il lavoro.

Cosa ho imparato scrivendo questo

Questo articolo è stato più difficile da scrivere di quanto mi aspettassi. Non per mancanza di contenuto - il problema era l'opposto. Ho troppe cose che avrei voluto sapere all'inizio, e scegliere le più importanti tra tutte ha richiesto più tempo della scrittura stessa.

Il criterio che ho usato alla fine è semplice: ho incluso solo le cose la cui assenza mi ha causato problemi concreti, misurabili in tempo perso o in errori evitabili. Non ho incluso cose che sono "buone da sapere" in astratto. Il filtro è stato: "Se non avessi saputo questa cosa, cosa sarebbe successo di diverso?"

Ho anche resistito alla tentazione di rendere questo articolo una guida esaustiva. Una guida esaustiva di "cose da sapere quando inizi a programmare" sarebbe inutile - troppo lunga, impossibile da ricordare, parallela a mille altre guide identiche. Quello che volevo scrivere era qualcosa di più specifico e di più mio: le cose che, nel mio percorso, hanno fatto la differenza più grande.

Una cosa che ho notato nel processo di scrittura: molte delle "cose che avrei voluto sapere" non riguardano il codice. Riguardano il meta-livello: come organizzare lo studio, come scegliere le risorse, come misurare il progresso, come uscire dall'isolamento. Il codice si impara relativamente facilmente se il contorno è giusto. Il contorno - le abitudini, il metodo, la rete - è quello che fa la differenza tra chi arriva dove vuole andare e chi si perde lungo la strada.

Ho anche riflettuto sul perché queste cose non vengono dette all'inizio. In parte è la cecità cognitiva che menzionavo nell'introduzione: chi sa già queste cose non ricorda come era non saperle. In parte è che il settore tech tende a glorificare la storia del "genio autodidatta che ha imparato tutto da solo" - il che crea un'aspettativa implicita che il percorso debba essere difficile per essere autentico. Non deve. La difficoltà dovrebbe essere nel contenuto - la complessità tecnica reale - non nelle informazioni meta su come imparare in modo efficace.

Se c'è una cosa sola che puoi portarti da questo articolo, è questa: il tempo che investi nel capire come imparare non è tempo sottratto all'apprendimento. È investimento che si ripaga con gli interessi. Il metodo giusto vale decine di ore risparmiate nel lungo periodo.

Hai cose che avresti voluto sapere all'inizio che non ho nominato qui? Mi piacerebbe saperlo. 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.