Filosofia e pensiero critico: la disciplina perfetta per debugging

Background di partenza

Alec McEachran ha studiato filosofia. Non informatica, non matematica, non ingegneria. Filosofia - con tutto quello che questo comporta: logica formale, epistemologia, etica, storia del pensiero. Il tipo di corso di laurea che molti selezionatori tech guardano con perplessità, chiedendosi cosa abbia a che fare con il codice.

La risposta, a guardare il percorso di McEachran, è: molto. Molto più di quanto sembri da fuori.

McEachran ha raccontato la propria transizione su nocsdegree.com nel 2020 - un sito dedicato a documentare i percorsi di developer che hanno raggiunto posizioni significative senza una laurea in computer science. Il profilo è parzialmente dietro paywall, ma il dato centrale è pubblico: filosofia → autodidattismo → posizione come software engineer a Google. Il percorso non è stato rapido né privo di difficoltà. Ma è stato fatto. E il modo in cui è stato fatto è istruttivo.

La domanda che vale la pena porsi non è "come ha fatto un filosofo a diventare un developer?" - formulata così, la domanda assume che ci sia qualcosa di strano nella transizione. La domanda più utile è: "quali competenze filosofiche si sono rivelate direttamente trasferibili alla programmazione, e perché?"

La risposta a questa seconda domanda è più articolata e più utile di una semplice storia di determinazione.

Cosa studia, concretamente, un laureato in filosofia

Per capire la trasferibilità, vale la pena essere precisi su cosa implica una laurea in filosofia - almeno nella sua versione analitica, che è la tradizione dominante nelle università anglosassoni e in molte italiane.

Un curriculum di filosofia analitica include, tipicamente: logica formale (proposizionale, predicativa, modale), teoria dell'argomentazione, epistemologia (come si produce conoscenza giustificata), filosofia del linguaggio (come funzionano le parole e i significati), etica (ragionamento normativo sistematico), filosofia della mente (cosa sono i processi cognitivi), e spesso una buona dose di storia della matematica e della logica - da Aristotele a Frege, da Russell a Wittgenstein.

Questo curriculum non è casuale. È il risultato di secoli di affinamento di strumenti per il ragionamento rigoroso in condizioni di incertezza. E quando lo si mette a confronto con le competenze che un developer usa ogni giorno - debuggare codice rotto, progettare architetture coerenti, documentare ragionamenti complessi, comunicare decisioni tecniche - la sovrapposizione è molto più ampia di quanto ci si aspetti.

Il contesto che rende la transizione plausibile

Vale la pena nominare una dato di contesto: secondo il Developer Survey di Stack Overflow 2023, circa il 40-45% dei developer professionisti non ha una laurea specifica in informatica o ingegneria informatica. La distribuzione si concentra nei ruoli di frontend e fullstack, ma la presenza di background umanistici - inclusa la filosofia - è documentata e non trascurabile.

Il mercato tech non cerca solo competenze algoritmiche pure. Cerca persone capaci di ragionare con precisione, comunicare in modo chiaro, documentare decisioni, e lavorare in team che includono profili non tecnici - designer, product manager, stakeholder business. Queste competenze non sono automatiche nei developer CS. Sono, invece, parte del curriculum esplicito di chiunque abbia studiato filosofia in modo serio.

Il profilo del developer filosofo nel mercato attuale

Il mercato tech 2024-2026 mostra una tendenza emergente: le aziende che costruiscono prodotti di AI - chatbot, sistemi di raccomandazione, strumenti di analisi del linguaggio - cercano persone capaci di ragionare sulle implicazioni etiche e sociali di questi sistemi, non solo di implementarli. Questo ha creato una domanda nuova per profili con background in filosofia della mente, etica, e logica: non come consulenti esterni ma come membri permanenti dei team di prodotto.

OpenAI, Anthropic, e DeepMind hanno tutti team dedicati all'AI safety e all'AI alignment che includono filosofi tra i loro ricercatori. Queste posizioni non richiedono necessariamente competenze tecniche da machine learning researcher - richiedono la capacità di ragionare in modo rigoroso su problemi come la formalizzazione degli obiettivi di un sistema AI, la coerenza dei valori in contesti di incertezza, e le implicazioni di lungo termine di decisioni di design. Competenze che un curriculo di filosofia analitica sviluppa in modo diretto.

Per chi viene da filosofia e considera la transizione verso il tech, questo contesto cambia il calcolo del percorso: non è solo "impara a programmare e poi trova un lavoro". È "impara a programmare abbastanza da contribuire a team che hanno già bisogno di competenze filosofiche". La soglia tecnica richiesta per entrare in questi team è diversa - e spesso più raggiungibile - rispetto alla soglia richiesta per diventare un software engineer tradizionale.

Difficoltà tipiche

Chi viene da filosofia e si avvicina alla programmazione incontra difficoltà specifiche. Non sono quelle dell'incapacità - sono quelle del disallineamento tra abitudini cognitive consolidate e le aspettative del dominio tecnico.

L'astrazione senza implementazione

La filosofia abituà a ragionare su concetti astratti senza che sia necessario - anzi, spesso senza che sia possibile - produrre un risultato concreto e verificabile in modo immediato. Un argomento filosofico non ha un test di compilazione. Non genera un output. Non fallisce con un errore specifico che ti dice esattamente dove hai sbagliato.

La programmazione è diversa in modo radicale: ogni affermazione può essere immediatamente verificata. Il codice funziona o non funziona. L'errore è specifico - non è una valutazione soggettiva dell'argomentazione, è un messaggio di errore con un numero di riga e un tipo di eccezione. Questo passaggio dall'astrazione pura alla verificabilità immediata richiede un adattamento cognitivo che molti filosofi descrivono come liberatorio - finalmente, un dominio in cui "hai ragione o hai torto" ha una risposta definitiva - ma che inizialmente genera frustrazione, perché toglie lo spazio di interpretazione a cui la formazione filosofica abitua.

La terminologia tecnica come barriera di ingresso

La filosofia ha un suo vocabolario tecnico denso - "ontologia", "epistemologia", "dialettica", "proposizione", "predicato". La programmazione ne ha uno altrettanto denso, ma diverso: "polimorfismo", "heap", "stack", "garbage collection", "asincronismo", "idempotenza". Il filosofo che inizia a programmare si trova in una posizione paradossale: è abituato a navigare vocabolari tecnici complessi, ma deve impararne uno completamente nuovo.

La differenza cruciale è che la terminologia filosofica ammette sfumature - termini come "verità" o "conoscenza" hanno definizioni dibattute da millenni. La terminologia tecnica è più rigida: "thread" significa qualcosa di preciso, "null pointer" significa qualcosa di preciso. Questa rigidità può essere frustrante per chi è abituato alla densità interpretativa del testo filosofico.

La matematica come lacuna specifica

Non tutti i curriculum filosofici includono matematica avanzata. Quelli che includono logica formale costruiscono basi solide per l'algebra booleana e la teoria degli insiemi - basi sufficienti per molta programmazione. Ma i curriculum filosofici senza logica formale possono lasciare lacune concrete in aritmetica booleana, notazione big-O, basi numeriche. Queste lacune non sono insuperabili, ma richiedono un investimento di apprendimento esplicito.

Il feedback loop lento rispetto alle aspettative

Nella formazione filosofica, il feedback sulle proprie argomentazioni arriva attraverso seminari, discussioni, commenti scritti - cicli lunghi settimane o mesi. Nella programmazione, il feedback è immediato: il codice funziona o no, e lo saprai in millisecondi. Questo cambio di ritmo richiede di reimparare a gestire il feedback - non più come valutazione interpretativa dilazionata, ma come dato diretto e immediato.

Cosa ha funzionato (Alec McEachran e il ragionamento filosofico applicato)

Il percorso di McEachran non è documentato in dettaglio operativo pubblico - il profilo su nocsdegree.com è parzialmente dietro paywall. Ma il dato chiave è pubblico: la transizione da filosofia a software engineer a Google ha funzionato. E dai profili simili documentati in modo più esteso - ad esempio nel thread Hacker News "Ask HN: Those who learned to code without a CS degree" (2020, oltre 400 commenti) - emerge un pattern coerente per chi viene da filosofia.

1. La logica formale come ponte diretto verso il codice

Chi ha studiato logica formale in un curriculum filosofico ha già incontrato i concetti fondamentali che sottendono la programmazione: proposizioni, predicati, quantificatori, operatori booleani, tabelle di verità, implicazione, equivalenza. La distanza tra la logica proposizionale e l'algebra booleana che regola i condizionali in programmazione è minima. Chi ha scritto dimostrazioni formali sa già, in modo implicito, come funziona un condizionale complesso con operatori AND, OR, NOT.

McEachran ha probabilmente sfruttato questo ponte in modo diretto: la familiarità con il ragionamento formale ha ridotto il tempo necessario per capire i costrutti di controllo del flusso, la logica dei predicati ha facilitato la comprensione delle query su database, e la teoria degli insiemi - presente in molti curriculum di logica filosofica - ha reso più intuitive le strutture dati fondamentali.

2. Il debugging come analisi degli argomenti

Il debugging è fondamentalmente un processo di analisi dell'argomentazione: hai una premessa (il codice che hai scritto), hai una conclusione attesa (il comportamento che ti aspetti), e hai un output reale che non corrisponde. Il lavoro del debugging è identificare dove l'argomento si rompe - dove la premessa non è quella che credevi, dove la logica intermedia ha un errore, dove l'output è diverso da quello atteso per una ragione specifica.

Questa struttura è esattamente quella dell'analisi filosofica degli argomenti - la stessa tecnica che si usa per smontare un sillogismo fallace, trovare la premessa implicita scorretta, o identificare l'equivocazione in un termine. La filosofia addestra questo tipo di ragionamento in modo esplicito e sistematico. Chi ha fatto anni di esercizi di analisi argomentativa porta questa competenza nel debugging in modo diretto.

Cal Newport in Deep Work (ISBN 978-1455586691) parla della capacità di concentrazione profonda come competenza rara e preziosa nell'economia dell'informazione. I filosofi, che per formazione trascorrono ore a ragionare su problemi complessi in modo sostenuto, hanno già sviluppato questa capacità di concentrazione. Nel debugging di problemi complessi - quelli che richiedono di tenere in testa più variabili simultaneamente e di ragionare su interazioni non ovvie - questa capacità è un vantaggio diretto.

3. La documentazione come argomentazione scritta

Scrivere documentazione tecnica chiara è una delle competenze più apprezzate in un team di sviluppo - e una delle più rare. La formazione filosofica produce scrittori abituati a: definire i termini in modo preciso prima di usarli, strutturare l'argomentazione in modo sequenziale e verificabile, anticipare le obiezioni del lettore, e distinguere tra ciò che si sta affermando e ciò che si sta assumendo come dato.

Queste sono esattamente le competenze che producono buona documentazione tecnica. Un README scritto da un filosofo tende a essere più chiaro, più strutturato, e più utile per chi lo legge rispetto a uno scritto da un developer CS che non ha ricevuto formazione esplicita sulla scrittura argomentativa.

4. L'epistemologia applicata alla verifica del codice

L'epistemologia - la branca della filosofia che studia come si produce conoscenza giustificata - ha un'applicazione diretta nella verifica del software. La domanda "come sai che questo codice fa quello che pensi che faccia?" è una domanda epistemologica. La risposta corretta - "perché ho scritto un test che verifica questo comportamento specifico" - è una risposta epistemologicamente fondata. La risposta sbagliata - "perché ho letto il codice e mi sembra corretto" - è epistemologicamente debole.

I filosofi che si avvicinano al Test-Driven Development spesso lo trovano intuitivamente coerente con la loro formazione: è il modo in cui si risponde formalmente alla domanda "come sai che funziona?". Questa intuizione accelera l'adozione di buone pratiche di testing.

5. La gestione dell'incertezza come competenza professionale

La filosofia insegna a operare con rigore in condizioni di incertezza - a distinguere tra ciò che si sa, ciò che si ipotizza, e ciò che si ignora; a costruire ragionamenti solidi anche quando le premesse non sono certe; a comunicare con onestà il livello di confidenza nelle proprie affermazioni. Questa competenza è direttamente spendibile nello sviluppo software, dove molte decisioni vengono prese in condizioni di informazione incompleta, e dove la capacità di comunicare chiaramente "so che X, ipotizzo che Y, non so Z" è preziosa nei team.

Framework cognitivo

Il percorso di McEachran illustra un principio più generale che la letteratura sul career change tecnico conferma: la competenza trasferita è spesso più robusta della competenza acquisita ex novo, perché è stata costruita su problemi reali nel corso di anni.

Filosofia analitica e informatica teorica: una storia comune

Non è casuale che molti fondatori dell'informatica teorica abbiano backgrounds in logica e filosofia matematica. Alan Turing ha studiato matematica con una forte componente di logica filosofica. Alonzo Church - che ha inventato il lambda calcolo, base teorica della programmazione funzionale - era un logico. Gottlob Frege, il cui lavoro sulla logica predicativa è stato fondamentale per l'informatica teorica, era un filosofo della matematica. La connessione tra filosofia (in particolare logica) e informatica non è accidentale: è storica e strutturale.

Questo non significa che ogni filosofo sia un potenziale informatico. Ma significa che la tradizione di rigorismo formale che sottende la filosofia analitica è la stessa che sottende l'informatica teorica. Chi ha studiato quella tradizione non parte da zero.

Il pensiero critico come differenziatore nel mercato tech

Il mercato del lavoro tech tende a ottimizzare per una cosa specifica: la capacità di completare task tecnici in modo rapido e accurato. Questa competenza è necessaria ma non sufficiente per i ruoli più avanzati, dove si richiede anche: valutare le implicazioni di una decisione architetturale a lungo termine, comunicare scelte tecniche a stakeholder non tecnici, identificare i presupposti impliciti in un requisito di business, e ragionare su trade-off complessi con molte variabili.

Queste competenze - pensiero critico applicato a decisioni complesse - non sono automaticamente presenti nei developer CS. Sono, invece, parte del curriculum esplicito della filosofia. Un developer con background filosofico che raggiunge la seniority tecnica spesso si trova in una posizione di vantaggio in ruoli che richiedono ragionamento strategico, comunicazione con business stakeholders, e leadership tecnica.

Il "long game" e la pratica deliberata

Cal Newport in Deep Work argomenta che la capacità di concentrazione profonda - il tipo di lavoro cognitivo che produce output di alta qualità - è diventata rara nell'economia dell'attenzione frammentata. I filosofi, per formazione, hanno già sviluppato questa capacità attraverso anni di lavoro su testi densi e problemi complessi.

Applicare questa capacità all'apprendimento della programmazione - studiare in modo profondo e sostenuto invece che in session frammentate - è il modo più efficiente per un filosofo di costruire competenze tecniche solide. Non è necessariamente il percorso più rapido in assoluto, ma tende a produrre una comprensione più profonda dei fondamentali, che si traduce in maggiore robustezza del codice prodotto.

La "filosofia del codice" come nicchia emergente

C'è una nicchia emergente nel mercato tech che vale la pena nominare: la filosofia dell'AI e dell'etica tecnologica. Man mano che i sistemi AI diventano più pervasivi, le organizzazioni cercano persone capaci di ragionare in modo rigoroso sulle implicazioni etiche di queste tecnologie - qualcosa che un filosofo con competenze tecniche può fare meglio di un puro CS o di un puro filosofo senza competenze tecniche. Questa è una nicchia piccola ma con domanda crescente, e il profilo "philosopher-developer" è quasi per definizione raro e ricercato.

Il ragionamento controfattuale come competenza di testing

Una competenza filosofica meno citata ma direttamente spendibile nella programmazione è il ragionamento controfattuale - la capacità di ragionare su "cosa succederebbe se...". La filosofia modale, che si occupa di possibilità e necessità, e la filosofia delle cause controfattuali ("A ha causato B se, in assenza di A, B non sarebbe avvenuto") hanno un'applicazione diretta nel testing del software. Scrivere un test efficace è fondamentalmente un esercizio di ragionamento controfattuale: si definisce un comportamento atteso, e si verifica che in assenza delle condizioni corrette quel comportamento non si verifichi.

Questo tipo di ragionamento - "questo test fallisce se e solo se il codice non rispetta questa proprietà precisa" - è esattamente il tipo di pensiero che la filosofia analitica sviluppa attraverso la logica formale e l'analisi degli argomenti. Chi ha studiato filosofia porta questa competenza già sviluppata. La sfida è riconoscerla come tale e applicarla sistematicamente alla scrittura dei test.

Il Test-Driven Development (TDD), che molti team tech considerano una best practice elevata, è fondamentalmente un ciclo di ragionamento filosofico applicato al codice: si definisce prima la proprietà che il sistema deve avere (il test), si verifica che la proprietà non sia soddisfatta (il test fallisce), si implementa il minimo necessario per soddisfarla (il codice), e si verifica che la proprietà sia ora soddisfatta (il test passa). Un filosofo che legge questa descrizione riconosce immediatamente il pattern del ragionamento ipotetico-deduttivo che ha studiato in epistemologia della scienza.

Letture e risorse

Per chi viene da filosofia e sta costruendo il percorso verso la programmazione, alcune risorse sono particolarmente utili - non le stesse che si consigliano a un autodidatta CS, ma quelle che sfruttano le competenze filosofiche già presenti.

Il profilo di Alec McEachran

• Alec McEachran - "How This Philosophy Grad Became a Developer and Got Hired by Google" (nocsdegree.com, 2020) - Il profilo originale, parzialmente accessibile. Il sommario pubblico conferma il percorso: laurea in filosofia, autodidattismo, Google. La citazione chiave che emerge dal contesto pubblico è che McEachran ha sfruttato esplicitamente il ragionamento logico filosofico per accelerare la comprensione dei fondamentali algoritmici.

Libri di riferimento

• Cal Newport, Deep Work: Rules for Focused Success in a Distracted World (ISBN 978-1455586691) - Il libro più direttamente applicabile per chi viene da filosofia: argomenta che la capacità di concentrazione profonda è la competenza più preziosa nell'economia dell'informazione, e fornisce un framework pratico per svilupparla e proteggerla. I filosofi hanno già questa capacità; questo libro aiuta a valorizzarla nel contesto professionale.
• Scott Shenker et al., Structure and Interpretation of Computer Programs (SICP - liberamente disponibile online a mitpress.mit.edu/sicp/) - Il libro di riferimento per chi vuole capire i fondamentali della programmazione in modo rigoroso e teoricamente fondato. Scritto in Scheme (un dialetto Lisp) con un'enfasi sulla struttura matematica e logica dei programmi. Un filosofo con logica formale trova in SICP un testo più accessibile rispetto ai libri "how to code" pratici - perché il livello di astrazione è quello giusto.
• Michael Sipser, Introduction to the Theory of Computation - Teoria dell'informatica formale: automi, linguaggi formali, computabilità. Per un filosofo con logica formale, questo testo è sorprendentemente accessibile - e fornisce la comprensione teorica che molti developer autodidatti mancano.

Risorse online

• Ask HN: Those who learned to code without a CS degree (Hacker News, 2020) - Thread con oltre 400 commenti da developer che hanno imparato a programmare senza laurea CS. Molti descrivono come background in scienze umane (inclusa filosofia) ha influenzato il loro modo di approcciarsi alla programmazione. Una lettura utile per calibrare le aspettative e trovare pattern riconoscibili nel proprio percorso.
• Stanford Encyclopedia of Philosophy - Classical Logic - Per chi vuole ripassare la logica formale prima di affrontare la programmazione: la SEP offre articoli enciclopedici di alta qualità, liberamente accessibili, sulla logica proposizionale e predicativa. Il ponte tra questa logica e la programmazione è diretto.
• roadmap.sh - Software Engineer Roadmap - Mappa visuale del percorso verso ruoli da software engineer. Utile per identificare le lacune specifiche da colmare rispetto alla formazione filosofica - e quelle che invece sono già coperte (logica, ragionamento algoritmico di base).

Se stai costruendo il tuo CV come developer proveniente da filosofia, il CV template che ho preparato include un esempio pensato per chi vuole posizionare la laurea in filosofia come differenziatore invece che come ostacolo - in particolare per ruoli in AI ethics, product engineering, o team che valorizzano il pensiero critico accanto alle competenze tecniche. Puoi scaricarlo gratuitamente qui sopra.

Prossimo passo nella serie

Questo articolo ha esaminato il percorso di Alec McEachran da filosofia a software engineer a Google, e il framework cognitivo che rende le competenze filosofiche - in particolare la logica formale, il debugging argomentativo, e la capacità di concentrazione profonda - direttamente trasferibili alla programmazione.

Il prossimo articolo della serie esamina un background diverso ma con sovrapposizioni interessanti: quello dei developer che vengono da lettere classiche o da studi di giornalismo. Carl Mungazi - giornalista prima di diventare frontend developer - ha documentato come la capacità di scrivere in modo chiaro e la sensibilità per la readability del codice siano competenze che chi viene da lettere porta in modo naturale. E come queste competenze, nel mercato tech attuale, siano più preziose di quanto si pensi.

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: Compensare i gap matematici da autodidatta - un articolo della serie che esamina come affrontare le lacune in matematica discreta, statistica di base, e algebra lineare quando non vengono dal percorso universitario.

Vedi anche: Le 5 trappole cognitive del bootcamper - inclusa la trappola del "sovra-analizzare prima di implementare", particolarmente comune nei developer con background filosofico o umanistico.

Cosa ho imparato scrivendo questo

Scrivere di Alec McEachran - con le informazioni limitate disponibili pubblicamente sul suo percorso - mi ha costretto a essere preciso sui confini di ciò che so e di ciò che inferisco. Il profilo su nocsdegree.com è parzialmente dietro paywall. Il dato pubblico centrale - filosofia → Google - è verificabile. I dettagli operativi del percorso non lo sono nella stessa misura.

Questo mi ha spinto a costruire l'articolo su due livelli: il caso specifico di McEachran come punto di ancoraggio verificabile, e il framework più ampio - costruito su letteratura pubblica, thread documentati, e la struttura logica della filosofia analitica - come corpo principale dell'analisi. È un approccio onesto. Non aggiunge dettagli non verificabili al percorso di McEachran, ma non lascia il lettore con sola una storia incompleta.

Ho imparato che la connessione tra filosofia e informatica è più solida e più documentata di quanto sembri nelle conversazioni casuali sul career change. Non è una consolazione per chi viene da filosofia e teme di essere "troppo lontano" dal tech. È un fatto strutturale: l'informatica teorica è nata dalla logica matematica e filosofica, e le competenze di ragionamento formale che la filosofia sviluppa sono le stesse su cui si fondano l'architettura dei compilatori, la progettazione dei database, e l'ingegneria dei sistemi distribuiti. La distanza percepita è minore di quella reale.

Ho imparato anche che la difficoltà più comune che i filosofi riportano - il perfezionismo analitico che rallenta l'implementazione - è una competenza mal calibrata, non un difetto. La stessa capacità di analisi che blocca l'implementazione nelle fasi iniziali diventa un vantaggio nella fase di revisione del codice, nell'identificazione dei presupposti impliciti nei requisiti, e nel debugging di problemi complessi. Il trucco è calibrare quando accenderla e quando tenerla spenta.

Se vieni da filosofia e stai valutando la transizione, o sei già nel mezzo del percorso, mi piacerebbe sapere dove ti trovi - quali competenze hai trovato immediatamente utili, e dove invece hai incontrato le resistenze più concrete. 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.