Vengo da lettere classiche: il valore della readability del codice

Background di partenza

Carl Mungazi si è laureato in giornalismo. Per quattro anni ha fatto il giornalista - un lavoro centrato su una competenza specifica: comunicare informazioni complesse in modo chiaro, conciso, e comprensibile per un pubblico che non è esperto del dominio. Nel 2016 ha iniziato a imparare a programmare da autodidatta. Non aveva mai scritto una riga di codice. L'articolo su nocsdegree.com - parzialmente accessibile - documenta la transizione: giornalista che si insegna a codificare → front-end developer.

Syk Houdeib aveva un background diverso ma convergente: laurea in Music Technology (Spagna), poi otto anni come insegnante di inglese come lingua straniera - un lavoro in cui la capacità di spiegare concetti complessi in modo semplice, di adattare il linguaggio all'interlocutore, e di comunicare in modo strutturato è tutto. Nel 2018 ha scritto su freeCodeCamp una storia che è diventata una delle più lette della piattaforma: come ha ottenuto il suo primo lavoro come developer in dieci mesi, all'età di quarant'anni, partendo da zero con la programmazione.

I due percorsi sono diversi nei dettagli ma identici nella struttura: background comunicativo umanistico → autodidattismo → posizione nel mercato tech. E in entrambi i casi, la competenza comunicativa è stata un fattore esplicito di differenziazione, non solo un fatto biografico irrilevante.

Perché il background da lettere o giornalismo è spesso sottovalutato

Nelle guide al career change tech, il background umanistico è spesso presentato come qualcosa da "superare" - un punto di partenza svantaggioso che richiede compensazione tramite corsi, bootcamp, portfolio tecnico. Questa lettura non è sbagliata, ma è parziale. Quello che tende a non essere detto è che alcune delle competenze più difficili da sviluppare nel mercato tech - e più ricercate nei team senior - sono competenze che chi ha studiato lettere o giornalismo ha già costruito in modo sistematico.

La readability del codice è una di queste. Non perché sia irrilevante chi viene da CS - lo è eccome. Ma perché l'attenzione alla chiarezza, alla struttura, e all'impatto del testo sul lettore non fa parte del curriculum esplicito della formazione tecnica nella stessa misura in cui fa parte di un curriculum di lettere o giornalismo.

Un developer CS che ha scritto migliaia di righe di codice funzionante può avere difficoltà con la readability - non per mancanza di intelligenza, ma per mancanza di formazione esplicita sulla comunicazione scritta. Un developer che viene da giornalismo ha già quella formazione.

Il mercato del technical writing come porta d'ingresso e come nicchia premium

Vale la pena nominare un percorso che molti developer con background in lettere o giornalismo sottovalutano: il technical writing come porta d'ingresso al tech e, in molti casi, come destinazione finale di alto valore. Il technical writer è il profilo che produce la documentazione tecnica - tutorial, guide per sviluppatori, documentazione API, release notes, guide utente. In molte aziende tech di medie e grandi dimensioni, il technical writer è un ruolo strategico: la qualità della documentazione influisce direttamente sull'adozione del prodotto, sulla riduzione dei costi di supporto, e sulla reputazione del team engineering.

Stripe, Twilio, GitHub, Cloudflare - tutte aziende note per l'eccellenza della loro documentazione - hanno team di technical writer dedicati e ben retribuiti. Per chi viene da lettere o giornalismo, questo ruolo non richiede un lungo percorso di reskilling tecnico: richiede la capacità di capire il prodotto abbastanza da descriverlo con accuratezza, e di comunicarlo in modo chiaro per il pubblico target (developer). Questa combinazione è più rara di quanto sembri - molti technical writer producono documentazione tecnicamente accurata ma poco leggibile; molti developer producono documentazione leggibile ma tecnicamente superficiale. Chi viene da lettere con interesse per il tech può colmare questo gap in modo naturale.

Difficoltà tipiche

Chi viene da lettere o giornalismo e si avvicina alla programmazione incontra difficoltà specifiche - non le stesse di chi viene da un background scientifico, e non le stesse di chi viene da un background completamente diverso.

La sintassi come lingua straniera rigida

Un giornalista che impara a programmare è già esperto nell'imparare nuovi codici comunicativi - ha imparato il codice del giornalismo (lead, piramide rovesciata, fatto/opinione), ha imparato a scrivere per diversi formati (quotidiano, web, radio). Ma il codice della programmazione è diverso: non ammette ambiguità. Una virgola fuori posto genera un errore. L'ordine delle parole non è una questione di stile - è una questione di significato esatto.

Questa rigidità può essere frustante inizialmente. Il giornalista è abituato alla flessibilità della lingua naturale - dove molti modi diversi di dire la stessa cosa sono tutti corretti. Il compilatore o l'interprete del linguaggio di programmazione non ha questa flessibilità. Una cosa sola è giusta, e il resto non funziona.

Le basi matematiche come lacuna concreta

I curriculum di lettere classiche e giornalismo raramente includono matematica avanzata. Le basi dell'algebra (variabili, equazioni, funzioni), la logica booleana, la notazione big-O: concetti che molti developer danno per scontati e che un laureato in lettere deve costruire da zero - spesso in parallelo all'apprendimento della programmazione.

Syk Houdeib ha affrontato questa difficoltà in modo diretto nel suo articolo su freeCodeCamp: la matematica era la parte più difficile, non per mancanza di intelligenza ma per mancanza di esposizione. La risposta che ha dato - risorse di Khan Academy per l'algebra di base prima di affrontare concetti più avanzati - è replicabile e verificata.

Il pensiero procedurale vs il pensiero narrativo

Il giornalismo e la letteratura insegnano il pensiero narrativo: come costruire una storia che fluisce, che ha una tensione, che porta il lettore da un punto A a un punto B in modo coinvolgente. La programmazione richiede pensiero procedurale: come scomporre un problema in passi sequenziali, verificabili, ripetibili, che una macchina può eseguire senza ambiguità.

Questi due tipi di pensiero non sono incompatibili - ma il passaggio dall'uno all'altro richiede un'adattamento cognitivo esplicito. Non si tratta di "diventare più logici" o "meno creativi": si tratta di imparare a muoversi tra due modi diversi di organizzare l'informazione.

Il portfolio tecnico come barriera di ingresso

Il mercato tech chiede evidenze concrete di competenza tecnica - un portfolio GitHub con progetti funzionanti, contributi open source, codice verificabile. Un giornalista che inizia a programmare non ha questo portfolio. Costruirlo richiede tempo e produce un livello di visibilità diverso da quello che un giornalista ha nel proprio campo.

Houdeib ha affrontato questa difficoltà costruendo progressivamente progetti reali - piccoli, imperfetti, ma pubblici. Mungazi ha fatto lo stesso. Entrambi hanno usato la propria capacità di scrittura per documentare il percorso in modo visibile - blog post, articoli - che hanno funzionato sia come portfolio della competenza tecnica in sviluppo sia come prova della capacità comunicativa già matura.

Cosa ha funzionato (Carl Mungazi, Syk Houdeib e la readability come vantaggio)

I percorsi di Mungazi e Houdeib condividono alcune pratiche che si sono dimostrate efficaci - non casuali, ma coerenti con le competenze che il loro background aveva già sviluppato.

1. Scrivere codice come se fosse un testo da leggere

Il principio centrale di Clean Code di Robert C. Martin (ISBN 978-0137081073) è che il codice viene letto molto più spesso di quanto venga scritto. Un developer passa la maggior parte del tempo a leggere codice - il proprio, quello dei colleghi, quello delle librerie. Scrivere codice leggibile non è una questione estetica: è una questione di produttività del team nel lungo periodo.

Martin identifica le caratteristiche del codice leggibile: nomi significativi per variabili e funzioni, funzioni brevi con responsabilità singola, commenti che spiegano il perché non il cosa, struttura che segue la logica del problema. Queste caratteristiche sono esattamente quelle che un giornalista applica alla propria scrittura: titoli che comunicano il contenuto, paragrafi brevi e focalizzati, struttura logica che segue il filo argomentativo.

Mungazi ha riconosciuto questo parallelo in modo esplicito: il codice è un testo scritto per essere letto da umani (oltre che eseguito da macchine), e la formazione giornalistica è direttamente applicabile alla qualità di quel testo. Il risultato pratico è che il suo codice tendeva a essere più leggibile rispetto a quello di colleghi senza formazione comunicativa - non perché fosse tecnicamente più complesso, ma perché era strutturato in modo più attento al lettore.

2. La documentazione come differenziatore naturale

In molti team di sviluppo, la documentazione è il compito che nessuno vuole fare. Non perché sia inutile - è fondamentale - ma perché richiedere chiarezza scritta a qualcuno che non ha formazione esplicita sulla scrittura produce spesso output di bassa qualità. Un giornalista che scrive documentazione tecnica porta qualcosa di diverso: la capacità di identificare cosa il lettore ha bisogno di sapere, in quale ordine, con quale livello di dettaglio.

Houdeib ha descritto come, nei suoi primi mesi di lavoro come developer, la capacità di scrivere documentazione chiara e strutturata lo avesse differenziato in modo visibile dai colleghi - anche da quelli con competenze tecniche più avanzate. Questa competenza non è automaticamente riconosciuta nei job posting, ma viene riconosciuta e apprezzata nei team una volta che si inizia a lavorare.

3. La comunicazione con i non-tecnici come competenza premium

I team di sviluppo operano in contesti organizzativi che includono stakeholder non tecnici: product manager, business analyst, clienti, dirigenza. Uno dei punti di frizione più comuni nei team è la comunicazione tra developer e non-tecnici - i developer tendono a over-specificare i dettagli implementativi, a usare gergo tecnico non necessario, a non calibrare il livello di dettaglio al contesto.

Un giornalista sa fare esattamente il contrario: sa identificare cosa è essenziale, sa adattare il linguaggio all'interlocutore, sa costruire una narrativa che porta il lettore a capire qualcosa di complesso senza sentirsi sopraffatto. Questa competenza - traducibile direttamente in riunioni efficaci con stakeholder business, report tecnici comprensibili, e spiegazioni di incidenti o ritardi - è preziosa a tutti i livelli di seniority, ma diventa critica a partire dal mid-level.

4. Il tempo come alleato, non come nemico

Houdeib ha ottenuto il suo primo lavoro come developer in dieci mesi - un tempo relativamente breve, ma che lui stesso descrive come il risultato di un approccio strutturato e consistente piuttosto che di un talento straordinario. La lezione che generalizza è quella del ritmo sostenuto: imparare ogni giorno, costruire progetti reali il prima possibile, usare la comunità (freeCodeCamp, Stack Overflow, GitHub) come risorsa di feedback continuo.

La formazione giornalistica ha abituato Houdeib a lavorare sotto deadline - una competenza che si è rivelata utile anche nell'apprendimento tecnico. Non nel senso di fretta, ma nel senso di consegna: c'è un momento in cui smetti di affinare il testo e lo pubblichi, anche se non è perfetto. Lo stesso principio applicato al codice - consegnare qualcosa che funziona, anche se imperfetto, e poi migliorarlo - è uno dei principi fondamentali dello sviluppo agile.

5. La rete professionale come ponte verso il tech

Mungazi ha usato la propria rete professionale giornalistica come punto di accesso iniziale al mercato tech - non candidandosi a posizioni tech tradizionali, ma sfruttando i contatti nei media digitali, nelle startup di news, e nelle aziende che cercavano developer capaci di capire il giornalismo dall'interno. Questo posizionamento iniziale - "developer con background giornalistico per prodotti media" - è stato più efficace del tentativo di competere direttamente con developer CS in contesti generici.

Framework cognitivo

I percorsi di Mungazi e Houdeib illustrano un principio che la letteratura sul career switch tecnico conferma: la competenza trasferita funziona meglio quando viene usata come differenziatore invece che nascosta come lacuna.

La readability come metrica di qualità del codice

La comunità tecnica ha un dibattito in corso da decenni sulla qualità del codice. Una delle conclusioni più solide - sostenuta da Martin, da Hunt e Thomas in The Pragmatic Programmer, e da ricerche sull'ingegneria del software - è che il codice leggibile riduce i costi di manutenzione, riduce i bug introdotti durante modifiche, e accelera l'onboarding di nuovi membri del team.

Questo non è un principio astratto: ha conseguenze concrete sul costo di sviluppo nel lungo periodo. Un team che produce codice leggibile spende meno ore a capire cosa fa il codice esistente, meno ore a debuggare effetti collaterali imprevisti, meno ore a spiegare ai nuovi arrivati come funziona il sistema. Il risparmio è documentato - i numeri specifici variano, ma il senso della direzione è coerente in tutti gli studi.

Chi viene da lettere o giornalismo porta una sensibilità per la readability che non è genericamente "artistica" ma strutturalmente compatibile con questo principio di qualità del codice. Non è un vantaggio indiretto - è un vantaggio diretto, misurabile in termini di costo del software nel tempo.

Il paradigma del "domain expertise" applicato ai media

Mungazi non è diventato un developer generico. È diventato un developer con background giornalistico - e ha usato quella combinazione per posizionarsi in contesti dove il background giornalistico ha valore diretto: media digitali, prodotti news, startup che costruiscono strumenti per giornalisti, aziende con content platform interne.

Questo è il meccanismo del domain expertise che emerge in tutti i percorsi di career switch riusciti: non si compete sull'asse "developer CS generico" dove il vantaggio competitivo è difficile da costruire partendo da un background non tecnico. Si compete sull'asse "developer con background X in un contesto dove X conta" - dove il vantaggio competitivo è strutturale e difficile da replicare per chi non ha quel background.

Il peer learning come acceleratore

Houdeib ha descritto il peer learning - imparare insieme ad altri in percorsi simili, non solo dagli esperti - come uno degli acceleratori più significativi del suo apprendimento. freeCodeCamp, i forum tecnici, i meetup locali: tutti contesti in cui si impara non solo dai più bravi, ma anche dai pari che stanno affrontando le stesse difficoltà. Questo tipo di apprendimento è particolarmente efficace per chi viene da background umanistici, abituati all'ambiente del seminario e della discussione collettiva.

La carriera in tech è un testo che si scrive, non un destino prestabilito

Sia Mungazi sia Houdeib hanno descritto il proprio percorso come una scrittura progressiva - non una conversione improvvisa ma una costruzione deliberata, passo dopo passo, con revisioni e aggiustamenti lungo il percorso. Questa mentalità narrativa - il percorso come storia con un arco, non come destino lineare - è coerente con la formazione umanistica e aiuta a gestire i momenti di difficoltà senza interpretarli come segnali definitivi di inadeguatezza.

Il code review come pratica di editing redazionale

Una competenza che chi viene da lettere o giornalismo porta in modo naturale - e che nel tech richiede mesi di formazione esplicita - è la capacità di fare code review di qualità. Una code review efficace non è solo la verifica tecnica che il codice funziona: è la lettura critica di un testo scritto da qualcun altro, con l'obiettivo di identificare ambiguità, imprecisioni, strutture poco chiare, e opportunità di miglioramento che l'autore non ha visto perché troppo vicino al proprio lavoro.

Questa è esattamente la pratica del redattore - o dell'editor letterario: leggere un testo scritto da qualcun altro con lo sguardo critico di chi viene dall'esterno, identificare cosa funziona e cosa no, e fornire feedback costruttivo che migliori il testo senza imporvi la propria voce. Chi ha fatto editing redazionale - o chi ha partecipato a workshop di scrittura creativa con feedback strutturato - porta questa competenza già sviluppata.

Il code review è uno dei momenti più formativi nel percorso di un developer junior - ma è anche uno dei momenti più ansiogeni. Chi viene da lettere, abituato sia a ricevere editing sia a farne, affronta il code review con una naturalezza che molti developer CS non hanno, perché la cultura del feedback critico costruttivo fa parte della tradizione umanistica in modo molto più esplicito di quanto non faccia nella cultura dell'ingegneria informatica.

Letture e risorse

Per chi viene da lettere o giornalismo e sta costruendo il percorso verso la programmazione, alcune risorse sono particolarmente utili - quelle che sfruttano la sensibilità comunicativa già presente e colmano le lacune più specifiche.

I percorsi di Carl Mungazi e Syk Houdeib

• Carl Mungazi - "This Journalist Taught Himself to Code and Is Now a Front-End Developer" (nocsdegree.com, 2016) - Il profilo di Mungazi, parzialmente accessibile. Il sommario pubblico documenta la transizione: giornalismo → autodidattismo → front-end developer. Il case centrale è la readability del codice come vantaggio diretto dalla formazione giornalistica.
• Syk Houdeib - "How I Switched Careers and Got a Developer Job in 10 Months" (freeCodeCamp, 2018) - Articolo completo e liberamente accessibile. Houdeib descrive in dettaglio il percorso: risorse usate (freeCodeCamp, Khan Academy, progetti reali), tempo investito, difficoltà incontrate (inclusa la matematica), e il ruolo della competenza comunicativa nel differenziarsi nel mercato. Una delle storie di career change più oneste e operative disponibili in rete.

Libri di riferimento

• Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship (ISBN 978-0137081073) - Il libro sulla readability del codice per eccellenza. Martin argomenta che il codice è comunicazione - scritto per essere letto da esseri umani, non solo eseguito da macchine. Per chi viene da lettere o giornalismo, questo libro è immediatamente comprensibile: i principi che enuncia sono gli stessi della buona scrittura, applicati al codice. Il capitolo sui nomi significativi da soli vale la lettura.
• Andy Hunt + Dave Thomas, The Pragmatic Programmer (ISBN 978-0135957059) - Il libro più utile per imparare a pensare come un developer indipendentemente dal linguaggio specifico. Non insegna a programmare in Python o JavaScript: insegna un modo di ragionare sul software che vale per qualsiasi linguaggio e per qualsiasi ruolo tecnico. Il capitolo sulla comunicazione tecnica - spesso ignorato da chi viene da background tecnici - è particolarmente utile per chi invece ha già quella competenza e vuole contestualizzarla nel dominio software.

Risorse online

• freeCodeCamp - Career Change Stories - La raccolta più ampia di storie verificate di career change verso il tech. Include storie da background giornalistico, letterario, e umanistico in generale. Utile per calibrare le aspettative e trovare percorsi riconoscibili.
• roadmap.sh - Frontend Developer Roadmap - La mappa del percorso verso i ruoli frontend - il percorso più diretto per chi viene da lettere o giornalismo, perché combina competenze tecniche (HTML, CSS, JavaScript) con competenze di comunicazione visiva e UX che chi ha un background umanistico spesso porta già in forma implicita.
• DEV.to - Developer Community - Piattaforma di blogging tecnico aperta. Per chi viene da lettere o giornalismo, scrivere su DEV.to - documentare il proprio percorso di apprendimento, spiegare concetti tecnici che si stanno imparando - è un modo di costruire portfolio e visibilità simultaneamente, sfruttando una competenza già presente.

Nella reading list che ho preparato per la serie trovi 50 risorse annotate - libri, articoli, corsi - selezionate specificamente per developer che vengono da background non tecnici. Cinque di queste risorse sono dedicate ai developer con background in lettere, giornalismo, e comunicazione: le risorse che colmano le lacune matematiche senza richiedere formazione accademica, e quelle che aiutano a costruire un portfolio tecnico sfruttando le competenze comunicative già presenti. Puoi scaricarla gratuitamente qui sopra.

Prossimo passo nella serie

Questo articolo ha esaminato i percorsi di Carl Mungazi (giornalista → front-end developer) e Syk Houdeib (insegnante ESL → developer), e il framework che fa della readability del codice un vantaggio strutturale per chi viene da lettere o giornalismo.

Il prossimo articolo della serie esamina un background con una connessione ancora più diretta a un'area tecnica specifica: chi viene da lingue straniere e traduzione, e come questa formazione si traduce in un superpotere nella internazionalizzazione (i18n) del software. Camila Moura - laureata in Relazioni Internazionali - ha documentato su DEV.to come la sua competenza linguistica l'abbia differenziata nel mercato tech in modo concreto e misurabile.

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.

Vedi anche: Filosofia e pensiero critico: la disciplina perfetta per debugging - il background filosofico ha sovrapposizioni interessanti con quello delle lettere classiche: ragionamento formale, capacità di analisi testuale, abitudine alla scrittura strutturata.

Vedi anche: Networking introverso via email - come costruire una rete professionale nel tech senza eventi e senza estroversia forzata, partendo dalla competenza comunicativa scritta che chi viene da lettere già ha.

Cosa ho imparato scrivendo questo

Scrivere di Carl Mungazi e Syk Houdeib mi ha portato a riflettere su qualcosa che sento ripetere spesso nelle conversazioni sul career switch verso il tech: l'idea che le "soft skills" siano un complemento gentile alle "hard skills" vere, ma non una competenza autonomamente preziosa.

Questa gerarchia è sbagliata, e i percorsi di Mungazi e Houdeib lo dimostrano in modo empirico. La readability del codice non è un "nice to have" - è una competenza che riduce i costi di sviluppo in modo misurabile. La capacità di comunicare con stakeholder non tecnici non è una caratteristica di personalità - è una competenza professionale che molti team cercano attivamente e faticano a trovare. La documentazione chiara non è un ornamento - è un fattore di produttività del team.

Ho imparato che chi viene da lettere o giornalismo tende a sottovalutare sistematicamente queste competenze - le vede come "cose che sa già", non come "competenze rare nel mercato tech". Il cambio di prospettiva è importante: non stai entrando nel tech "nonostante" il tuo background umanistico. Stai entrando con competenze che il mercato tech cerca e non trova in abbondanza.

Ho anche imparato - dal confronto tra i due percorsi - che la velocità di transizione dipende molto meno dal background e molto più dall'approccio: Houdeib ha impiegato dieci mesi, Mungazi ha impiegato più tempo. Le variabili che spiegano la differenza non sono il background (entrambi erano umanisti) ma il metodo: la frequenza dell'apprendimento, la precocità nella costruzione di progetti reali, la qualità della community di supporto.

Se vieni da lettere o giornalismo e stai valutando la transizione, o sei già nel mezzo del percorso, mi piacerebbe sapere in quale punto ti trovi - e in particolare: hai già trovato contesti in cui la tua competenza comunicativa è stata riconosciuta come un vantaggio? Scrivimi a federico@federicocalo.dev.

Ti rispondo. Sempre.