Matteo Baccan
← Original Article

Il Celodurismo dei Programmatori

2024-03-15

Il "celodurismo" dei programmatori

Nel mondo della programmazione, esiste un fenomeno curioso che potremmo definire "celodurismo". Questo termine descrive un atteggiamento di ostinata resistenza all'evoluzione degli strumenti e delle pratiche di sviluppo software.

Un tempo, quando le risorse erano scarse e preziose, i programmatori dovevano essere incredibilmente ingegnosi per spremere ogni goccia di potenza dai loro sistemi. Questa necessità ha forgiato abitudini e mentalità che, in alcuni casi, sono sopravvissute ben oltre la loro utilità pratica, trasformandosi in una sorta di folklore professionale.

640K ought to be enough for anybody

Questa celebre frase attribuita a Bill Gates, anche se lui ne ha negato la paternità, rappresenta bene l'atteggiamento di molti "celoduristi" nei confronti dell'innovazione tecnologica. Per questi programmatori, l'idea di utilizzare strumenti moderni come IDE avanzati, debugger grafici o assistenti AI sembra quasi un'eresia, una violazione dei principi fondamentali della programmazione "vera", un sintomo di debolezza e incapacità.

Le radici storiche

Negli albori dell'informatica, quando i computer venivano alimentati a colpi di schede perforate, programmare significava lavorare con sistemi dotati di memoria e processori limitati. I programmatori dell'epoca dovevano essere veri e propri artisti dell'ottimizzazione, capaci di scrivere codice che fosse al contempo funzionale ed estremamente efficiente.

Questa era ha prodotto capolavori di ingegnosità, e pratiche che ancora sopravvivono in ambienti dotati di scarse risorse: avete mai provato a programmare per microcontrollori o sistemi embedded? Qui, ogni byte di memoria e ogni ciclo di clock contano, e l'arte dell'ottimizzazione vive ancora di ottima salute, anche se più di una crepa inizia a vedersi all'orizzonte.

Col passare del tempo e l'evoluzione dell'hardware, molte di queste limitazioni sono venute meno, ma l'etica del "fare di più con meno" è rimasta profondamente radicata nella cultura della programmazione, talvolta trasformandosi in un atteggiamento di resistenza verso strumenti e pratiche che potrebbero semplificare e velocizzare il lavoro di sviluppo.

"Il codice più efficiente è quello che non devi scrivere"

Il manifesto del celodurismo

Per capire che tipo di programmatori siete, ecco un piccolo test per valutare il vostro grado di "purezza". Provate a capire quanto siete a favore o a sfavore di queste affermazioni:

1. L'IDE non serve a nulla

Un programmatore deve essere spartano: meno strumenti usa, più è sinonimo di competenza

"Per scrivere del codice mi basta Notepad (o Vi) e la CLI"

Questa affermazione è spesso pronunciata con un misto di orgoglio e nostalgia. Chi la sostiene sembra voler comunicare: "Sono un vero programmatore, non ho bisogno di aiuti". Questa posizione ignora deliberatamente i vantaggi offerti dagli IDE moderni.

Personalmente ho visto programmatori usare comandi come:

copy con: pippo.prg

con lo stesso orgoglio di chi a scuola prende un ottimo voto.

Non sottovalutiamo però i vantaggi degli IDE moderni e come come prima cosa leviamoci dalla testa che gli IDE siano dei semplici editor di testo con qualche abbellimento. Sono potenti strumenti che integrano numerose funzionalità per migliorare la produttività e la qualità del codice:

Questi sono solo alcuni dei motivi per i quali, quando entro in un editor inventato negli anni '70, mi sento come se mi avessero tolto un braccio.

Per onestà intellettuale non possiamo negare che, in alcune situazioni, un IDE potrebbe essere eccessivo, quando ad esempio occorre fare una modifica rapida o quando si lavora su sistemi remoti con risorse limitate. In questi casi editor minimali o qualsiasi cosa che apre una console testuale, potrebbero essere la scelta migliore. Per il lavoro di tutti i giorni e per progetti di una certa complessità, rifiutare categoricamente l'uso di un IDE moderno significa privarsi di strumenti che possono significativamente migliorare la qualità del codice e la produttività del programmatore e dell'intero team (si, perché il codice non è solo tuo, ma di tutti quelli che ci lavorano).

2. La CLI è la soluzione a tutti i problemi

Non nascondiamoci dietro a un dito, la CLI ha un fascino innegabile. Anni di film con hacker piegati su tastiere meccaniche e schermi neri con scritte verdi hanno formato generazioni di programmatori. Cosa c'è di più potente che controllare un computer digitando comandi testuali? Questo approccio, anche se ha il fascino della prima ragazza incontrata al liceo, ha una serie di limiti che spesso vengono trascurati:

Git è un ottimo esempio di come CLI e GUI possano coesistere e completarsi a vicenda. Mentre la CLI di Git offre un controllo granulare e la possibilità di automatizzare operazioni attraverso script, strumenti GUI come le integrazioni in VSCode possono rendere più accessibili operazioni complesse come:

Come sempre la verità sta nel mezzo e l'approccio più saggio è quello di padroneggiare entrambi gli strumenti. Usare la CLI per operazioni rapide e per creare script automatizzati, ma non si deve esitare a passare a una GUI quando questa può offrire una visione più chiara o un flusso di lavoro più efficiente.

3. Non usiamo Windows perché i programmatori usano Linux (o MacOS)

Ormai non conto più le notti che ho passato a leggere e commentare le "guerre di religione" dei sistemi operativi.

"Winzoz" on funziona
Sarà bello Linux che ha 200 versioni e tutte incompatibili
Lasciate stare, con MacOS funziona tutto
Guarda che Apple ti fa pagare il doppio di quello che vale quel computer

Si potrebbe andare avanti all'infinito, creando flame pieni di odio e carichi di ignoranza, ma la realtà è che ogni sistema operativo ha i suoi pregi e difetti, ed è sbagliato sostenere che uno sia superiore agli altri in modo assoluto.

Un programmatore dovrebbe essere superiore a queste chiacchiere da bar. Questo non limita la sua libertà di sentirsi a suo agio su un sistema piuttosto che su un altro, ma è assolutamente controproducente mettersi i paraocchi e ignorare l'esistenza di altri sistemi operativi oltre a quello preferito.

Ragioniamo poi sul fatto di lavorare giornalmente su piattaforme differenti e dei vantaggi che questo approccio può portare:

Invece di legarsi dogmaticamente a un singolo sistema operativo, un approccio più produttivo è quello di scegliere lo strumento giusto per il lavoro giusto, mantenendo la flessibilità di muoversi tra diverse piattaforme quando necessario.

4. Il debugger è per i deboli

Sfatiamo un'idea

Un "vero programmatore" scrive codice perfetto al primo tentativo

Questa storiella gira nel mondo della programmazione da anni. Più o meno tutti i programmatori famosi si sono cuciti addosso questa immagine, e ognuno di noi è pronto a raccontarla a fine serata quanto le birre sono ormai finite. La realtà è che il debug e i test sono una parte essenziale ed inevitabile del processo di sviluppo software e questa mentalità di resistenza all'uso di strumenti di debug, vedendoli come una sorta di "stampella", è qualcosa che va superato.

Ormai non conto più le volte che ho preso in mano un software considerato "concluso", pieno i test funzionanti, e piano piano sono usciti fuori problemi, casi d'uso non coperti, problemi di analisi e progettazione: no, l'illusione che la prima stesura di un programma sia in grado di generare un software perfetto e che i test bastino per capire cosa funziona o non funziona è solo un'illusione.

In queste situazioni: log, debug e nuovi test diventano necessari per capire cosa non funziona e come risolverlo.

5. Il codice è tutto nella mia testa

L'analisi, la condivisione della conoscenza e la documentazione sono aspetti spesso trascurati nella programmazione.

Ho tutto in testa

Non esiste una frase meno produttiva di questa, che atrofizza qualsiasi tipo di discussione e di collaborazione.

Esiste una narrativa romantica del programmatore come genio solitario, capace di tenere interi sistemi complessi nella propria mente e di vedere il proprio software come Neo vedeva Matrix. Questo approccio ha un errore di base: la mente umana, seppur meravigliosa, ha limiti nella quantità di informazioni che può mantenere.

Non tutti siamo Dennis Nedry, il programmatore di Jurassic Park che sapeva tutto il codice del parco a memoria e, anche se lo fossimo, ricordiamoci che fine ha fatto.

Dimenticare il passato è una forma di protezione che viene attivata dal nostro cervello per evitare di impazzire. Questo è il motivo per cui è importante documentare il codice, condividere la conoscenza e lavorare in team.

Ma anche se la propria mente avesse una capacità infinita, ci sono altri motivi per cui il "codice nella mia testa" è un problema:

Occorre quindi che il "celodurista" si renda conto che il codice è un prodotto collaborativo e non condividere delle informazioni non è il miglior approccio per mantenere il proprio lavoro, quanto il modo migliore per perderlo.

Spingiamo quindi questi programmatori a documentare, scrivere Wiki, fare code review, usare diagrammi e schemi, in modo da condividere la conoscenza.

Un approccio che valorizza la documentazione e la condivisione della conoscenza non solo rende il progetto più robusto e mantenibile, ma contribuisce anche alla crescita professionale di tutto il team.

6. I programmatori non usano ChatGPT

Diciamocelo: le intelligenze artificiali sono tutto, fuorché intelligenti.

Guarda quanti errori fa ChatGPT, non può sostituire un programmatore

Le allucinazioni, ma soprattutto l'uso scorretto e superficiale delle AI, porta molti programmatori a pensare che siano strumenti non utilizzabili. No, le AI non sono motori di ricerca, sono strumenti di aggregazione linguistica, che possono apprendere il nostro contesto di lavoro, e come tali vanno usate.

A queste teoria si sovrappongono sempre di più le teorie che in futuro le AI sostituiranno i programmatori. Il programmatore "duro e crudo" non usa quindi questi strumenti, perché non ne ha bisogno, perché non funzionano, perché "io sono meglio".

Tutto vero, ma solo in parte. La realtà è che le AI sono strumenti che possono aiutare i programmatori a scrivere codice più velocemente e con meno errori, ma non basta un ora per arrivare a questo risultato, occorrono settimane di utilizzo per capire al meglio come usare questo strumento ed individuare al volo pregi e difetti.

L'AI deve essere vista come strumento di potenziamento, come l'evoluzione dell'autocompletamento dei moderni IDE, ma in grado di estendere il completamento a un contesto più ampio e complesso.

Ho visto di recente il film Atlas, non per Jennifer Lopez, come molti di voi saranno propensi a pensare, ma per arricchire la mia testa di nuove immagini su futuri possibili. All'interno di questo film l'AI viene vista come un completamento del lavoro dell'uomo ed entrambi si migliorano e potenziano, lavorando in simbiosi.

Per chi ha passato i pomeriggi della propria infanzia a guardare Star Trek: è l'evoluzione della fusione mentale dei vulcaniani o del simbionte dei Trill.

Ci sono molti aspetti della vita di un programmatore che traggono vantaggio da una AI

Invece di rifiutare categoricamente l'uso delle AI, i programmatori dovrebbero considerarle come strumenti che possono migliorare la loro produttività e la qualità del loro lavoro.

Conclusione

Il "celodurismo" nella programmazione, seppur radicato nella storia come simbolo di ingegnosità e ottimizzazione, rischia di diventare un freno all'innovazione e all'efficienza nel mondo dello sviluppo software moderno.

Un approccio più equilibrato riconosce il valore della tradizione e dell'esperienza, ma rimane aperto alle nuove tecnologie e metodologie che possono migliorare il processo di sviluppo.

Il vero segno di un programmatore esperto non è l'adesione dogmatica a pratiche del passato, ma la capacità di valutare criticamente e adottare gli strumenti e le pratiche più adatte a ogni situazione specifica.

Ammiro i celoduristi per la loro tenacia, ma sono sicuro che se avessero più coraggio potrebbero trarre grandi vantaggi da una rivalutazione delle loro posizioni.