Quando si inizia a programmare, l’attenzione è quasi sempre rivolta a una sola cosa: scrivere codice.

Si seguono tutorial, si costruiscono piccoli progetti, si sperimenta. Ogni riga scritta dà la sensazione di progresso.

Questo porta a una convinzione implicita:

diventare bravi significa scrivere sempre più codice.

In realtà, nel lavoro reale, le cose funzionano in modo diverso.

Il mito dello sviluppatore che scrive tutto da zero

Molti immaginano il lavoro dello sviluppatore come un processo creativo continuo: nuove funzionalità, nuovi progetti, nuove soluzioni.

Nella pratica, soprattutto in azienda, la situazione è diversa.

Ti ritrovi quasi sempre davanti a codice già esistente:

• Progetti scritti da altri
• Architetture consolidate
• Logiche costruite nel tempo

Prima ancora di scrivere qualcosa di nuovo, devi capire cosa hai davanti e questo richiede una competenza spesso sottovalutata: leggere codice.

Leggere codice non significa scorrerlo

Leggere codice non vuol dire semplicemente “capire cosa fa una funzione”.

Significa ricostruire il contesto, ponendosi le giuste domande, ovvero:

• Perché è stata scritta in questo modo?
• Quale problema risolve?
• Quali vincoli aveva lo sviluppatore?
• Quali alternative ha scartato?

Ogni pezzo di codice è il risultato di una serie di decisioni.

Leggerlo significa risalire a quelle decisioni.

Il vero allenamento: ricostruire il ragionamento

Quando scrivi codice, parti da un problema noto e costruisci una soluzione.

Quando leggi codice altrui, succede l’opposto: parti da una soluzione e cerchi di ricostruire il problema e il ragionamento che l’ha generata.

È un cambio di prospettiva importante.

Non stai più solo imparando “nuove righe di codice”, ma stai allenando la capacità di inferire il pensiero dietro una soluzione e allo stesso tempo stai ampliando la tua concezione funzionale di quel progetto.

Capire il codice significa capire il modo di pensare

Con il tempo ti accorgi che non esiste un solo modo di risolvere un problema. Due sviluppatori possono affrontare la stessa situazione in modi completamente diversi:

• Uno privilegia la semplicità
• Uno la performance
• Uno la riusabilità
• Uno la leggibilità

Leggere codice ti espone a questi approcci.

E questo è il punto in cui inizi a sviluppare un vero “modello mentale” del problem solving.

Il collegamento con gli algoritmi

Quando inizi a riconoscere questi schemi, smetti di vedere il codice come una sequenza di istruzioni isolate.

Inizi a vedere strutture ricorrenti:

• iterazioni
• trasformazioni di dati
• ricerca e filtraggio
• gestione dello stato
• ricorsione

In altre parole, inizi a riconoscere gli algoritmi dietro le implementazioni e questo accelera drasticamente la tua capacità di comprendere nuovo codice.

Il valore del codice esistente

In una codebase reale non parti mai da zero.

Esiste già una storia:

• Codice scritto in momenti diversi
• Approcci differenti tra sviluppatori
• Soluzioni già adottate

Leggere questo codice ti permette di:

• Capire cosa funziona davvero nel contesto reale
• Evitare duplicazioni inutili
• Adattarti agli standard del progetto
• Scrivere codice più coerente

Quando il tuo codice diventa codice di qualcun altro

Mi è capitato di lavorare per lo stesso cliente per diversi anni, dopo alcuni anni mi si ripresenta una modifica su un progetto sul quale avevo lavorato in passato, e quindi mi sono ritrovato del codice scritto da me stesso.

Non lo ricordavo nei dettagli. Era diventato, di fatto, codice scritto da un altro sviluppatore.

In quel momento ho sperimentato direttamente la distanza tra chi scrive codice e chi lo legge nel tempo.

Il ruolo dei commenti

In quella situazione mi è stato molto utile aver commentato in modo chiaro le parti più importanti.

I commenti non spiegavano cosa facesse il codice, ma soprattutto perché era stato scritto in quel modo. Ed è proprio questo il punto critico.

Capire cosa fa una funzione è relativamente semplice, ma capire perché è stata progettata così, molto meno.

Commentare significa preservare il ragionamento

Un buon commento non ripete il codice.

Serve a conservare:

• Il motivo di una scelta
• Il contesto in cui è stata fatta
• Le alternative considerate
• I vincoli che hanno portato a quella soluzione

In questo senso, i commenti non descrivono il codice, descrivono il pensiero dietro il codice.

Perché aiuta anche nel lavoro quotidiano

Questa cosa non è utile solo quando rileggi il tuo codice dopo anni. È fondamentale anche quando lavori su codice scritto da altri. Se il codice è ben documentato, riesci molto più velocemente a capire:

• Il flusso logico;
• Le decisioni architetturali;
• Il motivo delle scelte implementative.

E questo riduce drasticamente il tempo necessario per entrare in un progetto.

Un effetto collaterale importante

Scrivere commenti chiari ha un altro effetto spesso sottovalutato. Ti costringe a chiarire il tuo stesso ragionamento mentre stai scrivendo codice. Cosa ancora più importante, se non riesci a spiegare perché stai facendo una scelta, probabilmente quella scelta non è ancora ben definita.

Capire il codice come accesso al pensiero

In alcuni casi, leggere codice scritto da altri significa entrare nel loro modo di ragionare. Non è sempre possibile, e dipende dalla qualità del codice. Ma quando il codice è chiaro, puoi risalire a:

• Strategie di risoluzione
• Modelli mentali
• Pattern ricorrenti

Questo ti permette di apprendere non solo soluzioni, ma modi di pensare.

Il vero salto di livello

Quando questo meccanismo diventa naturale, succedono due cose:

• Riconosci più velocemente le soluzioni
• Inizi a scrivere codice più consapevole, perché hai visto alternative reali

Non stai più solo programmando, ma stai scegliendo tra modi diversi di ragionare.

Conclusione

Quando si inizia a programmare si pensa che la crescita passi esclusivamente attraverso la scrittura di nuovo codice. Con il tempo ci si rende conto che una parte fondamentale del lavoro consiste nel comprendere ciò che è già stato scritto.

Ogni progetto, ogni repository e ogni codebase raccontano il modo di ragionare di chi ci ha lavorato prima di noi. Imparare a leggere quel ragionamento significa acquisire nuovi approcci, scoprire soluzioni che non avevamo considerato e sviluppare una maggiore consapevolezza nelle nostre scelte.

È una competenza che richiede pazienza e pratica, ma che ripaga enormemente nel lungo periodo.

Perché alla fine, il vero obiettivo non è soltanto scrivere codice che funzioni, ma scrivere codice che un giorno possa essere compreso facilmente da un collega o persino da noi stessi.

Uno sviluppatore cresce davvero quando non si limita a scrivere codice, ma impara a leggere, comprendere e assimilare il modo di pensare racchiuso nel codice degli altri.

Grazie per aver dedicato qualche minuto alla lettura di questo articolo. Mi auguro che queste riflessioni possano esserti utili nel tuo percorso di crescita come sviluppatore. Ci leggiamo la prossima settimana con una nuova puntata di Pensare da Developer