Vengo da matematica pura: come diventare data scientist o ML engineer

Nota metodologica: i percorsi descritti in questo articolo sono ricostruzioni basate su dati aggregati da ricerca pubblica - Stack Overflow Developer Survey 2023, testimonianze pubbliche da DEV.to e freeCodeCamp, e letteratura sul career development tecnico. Per la traiettoria specifica "matematica pura → data scientist", casi individuali con il livello di dettaglio di Zubin Pratap o Fernanda Ribeiro non erano disponibili nelle fonti verificate al momento della scrittura. Il pattern aggregato è informativo, ma chi cerca un singolo caso guida di riferimento potrebbe trovare più utile il percorso di Pratap (giurisprudenza) o di Ribeiro (legge) come analogia strutturale.

Background di partenza

Il matematico puro che decide di entrare nel mondo della data science o del machine learning si trova in una posizione ambivalente. Da un lato, ha una base formale che molti data scientist autodidatti non hanno - o hanno acquisito in modo incompleto: il calcolo differenziale e integrale che sta sotto alla backpropagation delle reti neurali, l'algebra lineare che governa le trasformazioni di dati ad alta dimensionalità, la probabilità e la statistica che sono il linguaggio nativo dell'inferenza statistica e del machine learning bayesiano. Queste non sono cose che si imparano in un weekend leggendo un tutorial.

Dall'altro lato, la formazione in matematica pura - quella che forma ricercatori e accademici, non ingegneri e tecnici - non include quasi mai le competenze che trasformano una comprensione matematica in un sistema software funzionante. Programmare in Python, gestire dati reali e sporchi, lavorare con librerie e framework, deployare modelli, scrivere codice testabile, collaborare in un team con Git e code review: queste sono competenze che un percorso in matematica pura non forma sistematicamente.

Il dato della Stack Overflow Developer Survey 2023 è informativo: tra chi lavora come data scientist o ML engineer, il 52% ha una laurea in informatica o ingegneria informatica, il 22% ha una laurea in matematica o statistica, e il restante 26% viene da background diversi o è autodidatta. Il 22% con background matematico è significativo: mostra che la transizione è fattibile e non rara. Mostra anche che richiede un percorso integrativo specifico - perché la laurea in matematica, da sola, non è sufficiente per il mercato del lavoro.

Cosa separa chi ce la fa da chi si ferma a metà? Quasi mai la matematica - quella quasi tutti i laureati in matematica pura l'hanno. Quello che separa è la capacità di costruire la parte ingegneristica in modo sistematico, senza dare per scontato che le competenze di programmazione arrivino naturalmente dalla comprensione teorica.

Non arrivano naturalmente. Arrivano con pratica deliberata, esattamente come la matematica è arrivata con anni di studio e di esercizi. Il matematico che impara a programmare deve affrontare lo stesso tipo di percorso che ha affrontato per imparare la topologia o la teoria dei gruppi: concetti nuovi, esercizi, errori, correzioni, sedimentazione nel tempo. Non è più difficile. Ma non è più facile solo perché si capisce la matematica che sta sotto.

Il mercato del lavoro per matematici in tech

Il mercato del lavoro per chi viene da matematica pura nel tech è concentrato in alcune aree specifiche. Le più ricettive sono: data science e analisi dati (dove la base statistica è un vantaggio diretto), machine learning e AI (dove le basi di algebra lineare e calcolo sono necessarie per capire e implementare i modelli più avanzati), quantitative finance (dove la matematica applicata è al centro del lavoro), ricerca scientifica in ambito tech (dove le competenze di modellazione matematica si trasferiscono in modo quasi diretto), e cryptography e sicurezza (dove la matematica discreta e la teoria dei numeri sono fondamentali).

Il mercato per ruoli generalisti - web developer, mobile developer, DevOps - non è chiuso per chi viene da matematica, ma in questi ruoli il background matematico non è un differenziatore significativo. La strategia efficace è posizionarsi in quelle aree in cui la base matematica è un vantaggio reale, non uno sfondo irrilevante.

Difficoltà tipiche

Le difficoltà che un matematico puro incontra nel percorso verso la data science o il machine learning non sono quelle che ci si aspetta. Non sono la matematica - quella c'è. Sono altre, e vale la pena nominarle con precisione.

Il "so già le basi" come trappola

Il laureato in matematica pura che inizia a studiare machine learning tende a saltare la parte matematica dei tutorial e dei corsi - con buona ragione, dato che la conosce già. Il problema è che questa efficienza nell'attraversare i concetti teorici crea l'illusione di essere più avanti nel percorso di quanto si sia. Si arriva alla parte "costruiamo il modello" prima di aver acquisito le competenze di programmazione necessarie per farlo in modo non banale.

Il risultato è spesso uno stallo frustrante: la matematica è chiara, ma il codice non viene. E la frustrazione è amplificata dalla consapevolezza che "dovrebbe essere facile, capisco la teoria". La difficoltà non è stupidità - è che la teoria e l'implementazione sono competenze diverse che richiedono apprendimento separato. Un matematico che sa dimostrare che il gradiente descende nella direzione di diminuzione più rapida non sa necessariamente come implementare una rete neurale che converge in modo stabile su un dataset reale.

La distanza tra matematica teorica e matematica applicata

La matematica che si studia in un corso di laurea in matematica pura è diversa - in enfasi, in formalismo, e in obiettivi - dalla matematica che si usa in pratica nella data science. Un corso di analisi in un percorso di matematica pura studia la convergenza di serie, la misura di Lebesgue, gli spazi di Hilbert. Un data scientist usa derivate e gradienti in modo applicato, senza la struttura rigorosa della matematica pura. La transizione tra i due registri - dal formalismo puro all'applicazione computazionale - è una competenza che si acquisisce, ma non è automatica.

Il matematico puro che legge un paper di machine learning di solito capisce la matematica. Ma "capire la matematica" di un paper non significa essere in grado di implementarlo in modo che funzioni su dati reali, che scala su dataset di grandi dimensioni, che non esplode per problemi numerici che il paper ignora perché assume dati ideali. Queste sono problematiche ingegneristiche che il percorso accademico in matematica pura non affronta.

La programmazione come linguaggio straniero

Per chi non ha mai programmato - o ha programmato solo in modo superficiale durante il percorso universitario - Python è un linguaggio straniero che richiede tempo per diventare fluente. Non "conoscere i comandi" ma davvero pensare in termini di codice: strutturare soluzioni come funzioni, capire quando usare una lista invece di un dizionario, sapere come debuggare quando le cose non funzionano, scrivere codice che altri possano leggere e mantenere.

Questa fluenza si acquisisce scrivendo codice ogni giorno, non leggendo tutorial. Il matematico che ha studiato Python su Codecademy per due settimane e poi inizia a lavorare con dati reali scopre presto che la fluenza nel linguaggio era molto minore di quanto pensasse. Questa scoperta, che può sembrare un fallimento, è in realtà un segnale diagnostico preciso: serve più pratica sulla programmazione, non sulla matematica.

Il debugging come competenza non banale

Una delle competenze meno valorizzate nell'apprendimento della programmazione - e una delle più importanti nel lavoro quotidiano - è il debugging: la capacità di capire perché il codice non funziona e di trovare la soluzione in modo sistematico invece di casuale. Il matematico è abituato a lavorare in un sistema formale in cui gli errori hanno una struttura chiara - una dimostrazione è sbagliata o giusta, e si può verificare passo per passo. Il debugging del codice è diverso: gli errori possono dipendere da variabili di stato, da dati input inattesi, da interazioni tra componenti del sistema, da differenze di versione tra librerie. Sviluppare una metodologia di debugging sistematica è una competenza separata che richiede pratica specifica.

Il mercato del lavoro per entry-level data scientist

Il mercato del lavoro per data scientist entry-level è significativamente più competitivo di quello per developer backend o frontend. Le posizioni spesso richiedono sia competenze tecniche (Python, SQL, librerie ML) sia esperienza con dati reali (progetti di portfolio, contributi pubblici, Kaggle competitions). Il laureato in matematica pura che si candida senza queste esperienze concrete si trova in svantaggio rispetto a candidati con background meno solido matematicamente ma con più progetti dimostrabili.

Il paradosso - che molti matematici in questa posizione trovano frustrante - è che il loro bagaglio matematico è genuinamente superiore a quello di molti candidati data scientist, ma il sistema di selezione non è in grado di misurarlo direttamente. I colloqui tecnici per data scientist tendono a valutare: Python, SQL, capacità di analisi di un dataset, implementazione di modelli con Scikit-learn. La matematica teorica profonda viene valorizzata in posizioni senior o di ricerca, non in quelle entry-level.

Cosa ha funzionato (percorsi da matematica pura)

Dai pattern aggregati di chi ha fatto questa transizione con successo - documentati in discussioni pubbliche su DEV.to, Reddit r/datascience, e Hacker News - emergono alcune pratiche ricorrenti.

1. Separare l'apprendimento matematico da quello ingegneristico

Il percorso più efficace che emerge dalle storie documentate è quello che separa esplicitamente la fase di costruzione delle competenze di programmazione dalla fase di applicazione matematica. Prima: Python solido, strutture dati, algoritmi base. Poi: NumPy, Pandas, visualizzazione dati. Poi: Scikit-learn con dataset reali. Poi: teoria ML applicata. Poi: frameworks di deep learning.

Questo sequenziamento sembra lento all'inizio - soprattutto per chi ha già la base matematica - ma produce competenze più solide e riduce il rischio di stallo nella fase di implementazione. Il matematico che segue questa sequenza arriva alla parte matematicamente interessante (i modelli di ML) con le competenze ingegneristiche già costruite, e può concentrare l'attenzione sulla comprensione profonda degli algoritmi invece di fare debugging di sintassi Python.

2. Lavorare con dati reali il prima possibile

I dataset accademici puliti - Iris, MNIST, Boston Housing - sono utili per imparare la sintassi, ma non preparano al lavoro con dati reali. I dati reali sono sporchi, incompleti, con outlier imprevisti, con encoding irregolari, con formati che cambiano a metà del dataset, con valori mancanti che non seguono nessun pattern ovvio. Lavorare con dati reali - dataset pubblici su Kaggle, UCI Repository, o progetti propri - è la differenza tra "ho completato un tutorial" e "so lavorare con i dati".

Per il matematico, questa transizione è spesso la più rivelatoria: si aspetta che il lavoro con i dati sia simile al lavoro con variabili matematiche - pulito, definito, con proprietà precise. Scopre che i dati reali non hanno queste proprietà, e che gran parte del lavoro di un data scientist è proprio il preprocessing - pulire, normalizzare, gestire i valori mancanti, capire cosa significa un valore anomalo - prima di toccare qualsiasi modello.

3. Costruire un portfolio con progetti end-to-end

Un portfolio che mostra solo modelli addestrati non è sufficiente per il mercato del lavoro. Il portfolio che funziona nei colloqui include progetti end-to-end: raccolta dei dati (o acquisizione da una fonte pubblica), preprocessing, esplorazione dei dati (EDA - Exploratory Data Analysis), modellazione, valutazione con metriche appropriate, e - idealmente - deployment in qualche forma accessibile (Streamlit per una demo interattiva, Flask per un'API semplice, o almeno un notebook Jupyter ben documentato su GitHub).

Questo dimostra non solo la comprensione matematica del modello, ma la capacità di costruire qualcosa che funziona in un contesto reale. Per il matematico, la parte più impegnativa di questo portfolio è spesso il deployment: non perché sia matematicamente difficile, ma perché richiede competenze di ingegneria del software (containerizzazione, API, gestione delle dipendenze) che il percorso accademico in matematica non copre.

4. Contribuire a discussioni tecniche pubbliche

Rispondere a domande su Stack Overflow, partecipare a discussioni su GitHub, scrivere spiegazioni di concetti matematici complessi in modo accessibile: queste attività costruiscono visibilità e dimostrano competenza in modo diverso dal portfolio. Per chi viene da matematica pura, la capacità di spiegare concetti matematici complessi in modo chiaro - sviluppata attraverso anni di seminari e presentazioni accademiche - è un differenziatore rispetto a molti sviluppatori CS che non hanno la stessa padronanza teorica.

Un articolo su DEV.to che spiega l'intuizione geometrica dietro la PCA (Principal Component Analysis) in modo accessibile è più prezioso come segnale di competenza di dieci righe di codice Python che fanno la stessa operazione. La capacità di comunicare concetti difficili è una competenza rara nel mondo tech, e il matematico che l'ha sviluppata attraverso la formazione accademica porta questo vantaggio in modo naturale.

5. Usare la matematica come vantaggio nella ricerca applicata

Chi viene da matematica pura ha un vantaggio significativo nelle posizioni che richiedono comprensione profonda degli algoritmi - research engineer, ML researcher, posizioni in team di R&D di grandi aziende tech o di startup AI. Queste posizioni sono meno numerose di quelle data analyst o ML engineer generalist, ma sono anche quelle in cui il background matematico è il differenziatore principale e in cui la progressione di carriera è più rapida per chi ha basi solide.

Identificare precocemente quale fascia del mercato si vuole raggiungere aiuta a calibrare il percorso di apprendimento. Chi punta a posizioni di ricerca deve investire anche nella capacità di leggere e implementare paper accademici - una competenza che il background matematico facilita enormemente. Chi punta a posizioni data scientist generaliste deve investire di più nella velocità di produzione e nella capacità di comunicare risultati a stakeholder non tecnici.

6. Partecipare a Kaggle competitions

Le Kaggle competitions sono uno dei modi più efficaci per un matematico che sta costruendo competenze di data science di verificare il proprio livello, imparare dai migliori (i notebook pubblici dei top performer sono documenti tecnici di alta qualità), e costruire visibilità nel mercato. Una medaglia Kaggle - anche di bronzo - è un segnale di competenza che molti recruiter tech riconoscono e valorizzano.

La struttura competitiva di Kaggle forza anche una disciplina importante: si lavora su un problema reale, con un dataset reale, con una scadenza fissa, e con feedback immediato (la leaderboard aggiorna i risultati in tempo reale). Questo tipo di esercizio accelera l'apprendimento in modo che la pratica su dataset locali non riesce a replicare.

Framework cognitivo

La transizione da matematica pura a data science o ML engineering ha una struttura teorica precisa, che aiuta a capire perché certe pratiche funzionano e altre no.

Career capital e competenze complementari (Newport)

Cal Newport in So Good They Can't Ignore You (ISBN 978-1455509126) descrive il career capital come l'insieme delle competenze rare e preziose costruite nel tempo. Il laureato in matematica pura ha un career capital matematico che è genuinamente raro nel mercato tech. Ma il career capital tecnico - programmazione, ingegneria del software, data engineering - è scarso o assente.

La strategia efficace non è sostituire uno con l'altro. È costruire il secondo in aggiunta al primo, fino al punto in cui la combinazione diventa un differenziatore. Un ML engineer che capisce la teoria dei modelli a un livello che molti colleghi non raggiungono è un professionista con un vantaggio competitivo reale. Ma quella comprensione teorica deve essere accompagnata dalla capacità di implementare, testare, e deploiare - altrimenti rimane un asset teorico che non si traduce in valore lavorativo. Newport chiama questo il "craftsman mindset": invece di chiedersi "sono abbastanza bravo?", chiedersi "cosa devo costruire per diventare prezioso in questo mercato?"

La pratica deliberata nel dominio tecnico (Ericsson)

Anders Ericsson - il ricercatore che ha formalizzato il concetto di pratica deliberata - ha mostrato che la competenza in domini complessi si costruisce attraverso pratica intenzionale nelle aree di debolezza specifica, con feedback immediato. Per un matematico che sta costruendo competenze di programmazione, questo significa: non imparare la stessa cosa in modi diversi (variante A del tutorial, variante B del corso), ma identificare la specifica lacuna - "non capisco come funzionano i generatori Python", "non riesco a gestire il join tra dataframe con chiavi duplicate" - e studiarla direttamente, con esercizi mirati, fino a che diventa chiara.

La pratica deliberata è diversa dalla pratica casuale: non è "programmare ogni giorno" in senso generico, è "lavorare ogni giorno su qualcosa che non so ancora fare, in modo da ricevere feedback immediato su dove sto sbagliando". Il matematico abituato alla pratica deliberata accademica (esercizi strutturati, soluzioni verificabili, progressione per difficoltà crescente) può trasferire questa disciplina all'apprendimento della programmazione - a patto di identificare le lacune con la stessa precisione con cui identificherebbe i punti mancanti in una dimostrazione.

Il ruolo dei dati reali nell'apprendimento empirico

La matematica pura è fondamentalmente astratta: il suo oggetto di studio non dipende dal contesto empirico. La data science è l'opposto: il suo oggetto di studio sono i dati reali, con tutte le loro irregolarità, i loro outlier, le loro storie. Il passaggio mentale dal ragionamento astratto al ragionamento empirico è un cambio di frame che richiede pratica deliberata con dati reali - non solo comprensione teorica di come funzionano i modelli.

Un matematico che ha capito perfettamente la teoria della regressione OLS ma non ha mai fatto un'analisi su un dataset reale non è pronto per il mercato del lavoro data scientist. Un matematico che ha fatto analisi su cento dataset reali - anche senza capire i dettagli teorici di ogni tecnica usata - è molto più vicino alla competenza lavorativa. La teoria e la pratica empirica si completano a vicenda, ma la pratica empirica è spesso il collo di bottiglia per chi viene dalla formazione matematica accademica.

L'intuizione numerica come vantaggio specifico

Una competenza che il matematico porta naturalmente alla data science - e che spesso non viene riconosciuta come vantaggio - è l'intuizione numerica: la capacità di "sentire" quando un risultato è plausibile o no, di notare quando un numero è fuori scala rispetto alle aspettative, di riconoscere quando un modello sta overfittando prima ancora di guardare le metriche di validazione. Questa intuizione, costruita attraverso anni di lavoro con oggetti matematici, è un tipo di sanity check automatico che accelera il debugging e migliora la qualità dell'analisi.

Letture e risorse

Le risorse più utili per chi viene da matematica pura e vuole entrare nella data science o nel ML engineering sono quelle che assumono la base matematica già presente e si concentrano sul lato ingegneristico - che è il lato che manca.

Percorso di apprendimento consigliato

• Khan Academy - Computer Science - Per chi parte da zero con la programmazione. Coprire i fondamenti di algoritmi e strutture dati nella sezione CS. Gratuito, ben strutturato, utile come prima esposizione prima di passare a risorse più tecniche.
• freeCodeCamp - Machine Learning with Python - Percorso gratuito che porta da zero Python all'applicazione di algoritmi ML con Scikit-learn e TensorFlow. Particolarmente utile dopo aver acquisito basi di Python solide, come ponte verso il lavoro con dati reali.
• freeCodeCamp - Machine Learning Articles - Una raccolta curata di articoli su machine learning: tutorial applicati, guide agli algoritmi, e storie di professionisti che lavorano nel campo. Utile per chi vuole capire come il ML viene usato nella pratica - non solo nella teoria.

Libri di riferimento

• Cal Newport, So Good They Can't Ignore You (ISBN 978-1455509126) - Il framework del career capital applicato alla costruzione di competenze complementari. Per capire come trasformare il background matematico in un vantaggio di mercato, non solo in una base formativa.
• Andy Hunt + Dave Thomas, The Pragmatic Programmer (ISBN 978-0135957059) - Fondamenti di ingegneria del software per autodidatti. Insegna come pensare al codice in modo professionale - testing, refactoring, documentazione, versionamento - non solo come eseguire tutorial. Il capitolo sull'apprendimento deliberato è direttamente applicabile al percorso di transizione da matematica a tech.

Dati di riferimento

• Stack Overflow Developer Survey 2023 - Dataset pubblico con statistiche su background educativo dei developer, salari per ruolo e area geografica, tecnologie più usate. La sezione su data scientist e ML engineer è particolarmente rilevante per calibrare le aspettative sul mercato e sulla distribuzione dei background.

La Roadmap 12 percorsi include una mappa dettagliata del percorso ML Engineer e Data Engineer - con i prerequisiti matematici, le tappe di apprendimento ingegneristico, e i tempi realistici per ciascuna fase. Include anche una sezione specifica sul posizionamento nel mercato per chi viene da matematica pura. Puoi scaricarla gratuitamente qui sopra.

Prossimo passo nella serie

Questo articolo ha esplorato il percorso da matematica pura a data science o ML engineering: la base matematica come vantaggio, le competenze ingegneristiche come gap da colmare sistematicamente, e le pratiche che accelerano la transizione in modo sostenibile.

Il prossimo articolo della serie - complementare a questo - esplora un tema specifico che riguarda molti autodidatti con background matematico variabile: come compensare i gap matematici quando si viene da background in cui la matematica è stata studiata ma non approfondita al livello necessario per il ML. Non tutti vengono da una laurea in matematica pura. Molti vengono da informatica, economia, o altri campi in cui la matematica era presente ma non centrale. Per chi si trova in questa posizione, la sfida è diversa: identificare i gap specifici e colmarli senza tornare all'università.

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: L'impostor syndrome non finisce mai (ed è normale) - incluso specificamente per chi viene da matematica e si trova a confrontarsi con colleghi che programman da anni mentre lui sa fare derivate che loro non capiscono: il confronto asimmetrico è una delle fonti di impostor syndrome più frustranti.

Vedi anche: Cosa farei oggi se ricominciassi da zero - per capire, guardando indietro, quali risorse avrebbero fatto la differenza all'inizio del percorso.

Cosa ho imparato scrivendo questo

Scrivere di questa transizione - da matematica pura a data science - mi ha aiutato a capire qualcosa sulla natura della competenza tecnica che pensavo di capire già, ma che scrivere ha reso più preciso.

La competenza tecnica non è un continuum uniforme. È un insieme di competenze distinte che si sviluppano su ritmi diversi e che non si trasferiscono automaticamente le une alle altre. Capire la matematica di un algoritmo non significa saper implementarlo. Saper implementarlo non significa saper deployarlo. Saper deployarlo non significa saper lavorare in un team su quel codice in modo sostenibile. Ciascuna di queste competenze richiede apprendimento specifico - e nessuna è "ovvia" o "banale" per chi viene dalla matematica pura, anche se dall'esterno possono sembrare meno sofisticate della teoria matematica.

Questo è un punto che il discorso pubblico sul "basta studiare matematica per fare ML" trascura sistematicamente. La matematica è necessaria - senza non si va lontano nei ruoli tecnici più avanzati. Ma non è sufficiente. E confondere "necessario" con "sufficiente" porta a investire tutto il tempo sulla parte già forte (la matematica) invece di dedicarne una quota significativa al punto di debolezza (la programmazione e l'ingegneria). Il matematico che si trova a fare questo errore spesso si accorge del problema solo quando inizia a candidarsi e scopre che i colloqui tecnici richiedono Python fluente e capacità di analisi dati che non ha sviluppato.

Ho scelto di essere trasparente sul fatto che i percorsi individuali in questo articolo sono ricostruzioni aggregate - non casi singoli con il livello di dettaglio di Pratap o Ribeiro. Questa onestà metodologica non rende l'articolo meno utile, ma permette a chi legge di capire la natura delle evidenze su cui si basa: pattern aggregati da molte fonti, non un singolo caso che potrebbe essere un'eccezione statistica.

Se sei in questo percorso - matematica, o vicino alla matematica, e stai cercando di diventare data scientist o ML engineer - mi interessa davvero sapere dove sei e cosa stai trovando difficile. Le difficoltà specifiche che incontri chi viene da matematica pura sono probabilmente diverse da quelle di chi viene da giurisprudenza o da economia, e capire questi pattern specifici mi aiuterebbe a scrivere articoli più utili per questa parte della serie. Scrivimi a federico@federicocalo.dev.

Ti rispondo. Sempre.