Da giurisprudenza a developer: il percorso lungo è possibile

Background di partenza

Zubin Pratap non è un caso isolato. Ma è uno dei casi meglio documentati: ha scritto lui stesso della propria transizione, in prima persona, con un livello di dettaglio e di onestà che rende il suo racconto raro nel genere "career change story" - un genere spesso dominato da versioni semplificate e ottimistiche di percorsi che nella realtà sono stati molto più complicati.

Il dato biografico di base è questo: Pratap si è laureato in legge in India, ha esercitato come avvocato aziendale per oltre un decennio - prima in India, poi in Australia - e ha iniziato a imparare a programmare su autodidatta in parallelo al lavoro, senza lasciare la professione legale dall'oggi al domani. Non era un ragazzino che si annoiava. Era un professionista di mezza carriera con una rete professionale consolidata, un reddito stabile, e la prospettiva concreta di una carriera nel diritto che avrebbe continuato a progredire.

Quello che lo ha spinto verso la programmazione non è stato un momento di illuminazione né una crisi professionale. È stato qualcosa di più sottile: la curiosità verso un dominio che lui stesso descrive come "il futuro del diritto e del business" - e, con il tempo, la scoperta che programmare lo coinvolgeva in modo diverso e più profondo rispetto al lavoro legale. Ma questa scoperta è venuta dopo, non prima. All'inizio era una sperimentazione.

Il percorso da quella sperimentazione iniziale al contratto con Google ha richiesto anni. Non mesi. Pratap è stato esplicito su questo: non si è trattato di un bootcamp di sei mesi e un portfolio brillante. Si è trattato di apprendimento continuativo, di fallimenti in colloqui tecnici, di ricominciare su basi più solide, e di un livello di persistenza che lui stesso definisce come la variabile più importante dell'intero percorso.

Perché la storia di Pratap è rilevante per chi viene da un background in giurisprudenza? Perché rappresenta un caso limite in senso positivo: se il percorso è fattibile a 39 anni, dopo dodici anni di carriera legale, partendo da zero con la programmazione, allora le variabili che contano non sono l'età e non sono il background specifico. Sono altre.

Questo articolo le analizza. Non come lista di consigli generici, ma come struttura coerente estratta da quello che Pratap stesso ha documentato - e da quello che la letteratura sul career change tecnico conferma.

Se vieni da giurisprudenza e stai valutando se la transizione sia possibile, la risposta breve è: sì. La risposta lunga è questo articolo.

Il contesto del mercato legale che spinge verso la transizione

Vale la pena contestualizzare il caso di Pratap in un trend più ampio. Il mercato del lavoro legale - in molti paesi, inclusa l'Italia - sta attraversando una trasformazione strutturale guidata dall'automazione. Molte attività che occupavano gli avvocati junior e i paralegali - ricerca giurisprudenziale, revisione contratti, due diligence documentale, redazione di atti standardizzati - sono già parzialmente o totalmente automatizzabili con gli strumenti di AI legale disponibili oggi: Ross Intelligence, Contract Pilot, Lexis+ AI. Questa automazione riduce la domanda di profili legali junior e crea domanda di profili tecnici capaci di costruire, implementare, e gestire questi strumenti.

Pratap ha anticipato questo trend - non necessariamente come previsione consapevole, ma come intuizione che "il futuro del diritto passa dalla tecnologia". Chi viene da giurisprudenza oggi e sta valutando la transizione tech non è solo in fuga dalla professione legale: è potenzialmente in anticipo su un cambiamento che riguarderà tutta la professione nel prossimo decennio. Questo cambia il frame: non è "abbandono della carriera legale", è "anticipazione del futuro del settore legale".

Il profilo LegalTech - un developer che capisce il diritto - è uno dei profili più cercati nel mercato tech europeo in questo momento. Le startup legali, le banche con dipartimenti di compliance, le assicurazioni con uffici legali interni, le grandi law firm che costruiscono i propri strumenti digitali: tutte cercano profili tecnici con background legale. È una nicchia piccola ma con domanda di offerta squilibrata a favore di chi ha entrambe le competenze.

Difficoltà tipiche

Chi viene da giurisprudenza e si avvicina alla programmazione incontra difficoltà specifiche che chi viene da altri background non-CS non necessariamente condivide. Vale la pena nominarle con precisione, perché nominarle è il primo passo per non lasciarsi sorprendere da esse.

Il pensiero normativo contro il pensiero procedurale

La formazione giuridica è fondata sul pensiero normativo: l'interpretazione di regole, la ricerca del precedente, la costruzione di argomentazioni basate su fonti di autorità. La programmazione - in particolare l'informatica di base - richiede un tipo di pensiero diverso: procedurale, algoritmico, orientato all'esecuzione step-by-step di istruzioni che una macchina può seguire senza ambiguità.

Questi due tipi di pensiero non sono incompatibili. Ma il passaggio dall'uno all'altro richiede un'attività cognitiva specifica che molti ex-giuristi descrivono come "imparare a pensare in modo diverso" - un'espressione vaga, ma che nasconde qualcosa di reale. Il giurista è abituato a ragionare su casi in cui l'interpretazione ha margine. L'algoritmo non ha margine: funziona o non funziona.

La difficoltà pratica emerge soprattutto nelle prime fasi di apprendimento, quando i concetti fondamentali - variabili, tipi, cicli, condizioni, funzioni - sembrano elementari ma richiedono un cambio di frame mentale che non sempre avviene immediatamente. Molti ex-giuristi descrivono i primi mesi come frustranti in modo specifico: "so già fare cose complesse nel mio campo, perché questa cosa semplice non mi viene?"

La risposta è che non è semplice. È diversa. E "diverso" richiede tempo di adattamento, indipendentemente dal livello di intelligenza o dalla capacità di apprendimento. Il giurista che si frustrava perché "non capiva la ricorsione" spesso stava impostando il problema in modo sbagliato: cercava la regola giuridica che governasse il caso (c'è sempre una norma che si applica) invece di costruire un meccanismo che si auto-chiami. Sono due tipi di ragionamento fondamentalmente diversi.

La credenziale sbagliata nel contesto sbagliato

Un giurista che cerca lavoro come developer si trova in una posizione paradossale: ha una credenziale forte - la laurea in giurisprudenza - che nel mercato del lavoro tech è quasi irrilevante come segnale tecnico. Anzi, può essere controproducente in alcuni contesti, perché il selezionatore si chiede "perché un avvocato vuole fare il developer?" prima ancora di valutare le competenze tecniche.

Pratap ha affrontato questa situazione in modo diretto: ha costruito il suo portfolio prima di candidarsi, ha contribuito a progetti open source, e ha usato la sua storia come differenziatore invece di nasconderla. Ma questo richiede una quantità di lavoro preparatorio che chi viene da un background CS non deve fare nella stessa misura.

La credenziale legale non è inutile nel mercato tech: è mal posizionata se usata nel contesto sbagliato. In una startup che costruisce software generico, la laurea in legge è sostanzialmente irrilevante. In una startup LegalTech, in un team compliance di una banca, o in un'azienda che sviluppa strumenti di contrattualistica automatizzata, diventa un asset differenziante. La strategia efficace è non nascondere il background, ma posizionarsi in contesti in cui quel background ha valore.

Il peso dei costi opportunità percepiti

Lasciare una carriera legale avviata - con il suo status, la sua rete professionale, e spesso uno stipendio nella fascia medio-alta - per ricominciare come junior developer con uno stipendio inferiore è un trade-off che molti giuristi faticano a fare anche quando la motivazione è reale. Non è irrazionalità: è la valutazione corretta di un costo opportunità concreto.

Pratap non ha lasciato immediatamente. Ha studiato in parallelo per anni prima di fare il salto. Questa è una delle strategie più documentate tra chi ha fatto questa transizione con successo: ridurre il rischio finanziario studiando in sovrapposizione con il lavoro esistente, invece di lasciare tutto il primo giorno.

C'è anche un aspetto di identità professionale legato al costo opportunità percepito. Un avvocato aziendale con dieci anni di esperienza che ricomincia come developer junior non perde solo stipendio: perde status, perde la rete professionale che conta per quel ruolo, perde la sicurezza che viene dall'essere competente in modo riconosciuto. Questi costi sono reali e va fatto il conto con essi prima di decidere. Ma sono anche temporanei: dopo tre anni di lavoro tecnico, la seniority si ricostruisce - e spesso su basi più solide, perché la persona porta con sé una comprensione del dominio che non aveva prima.

Il colloquio tecnico come ostacolo specifico

I colloqui tecnici per posizioni entry-level nel software engineering valutano spesso competenze di algoritmi e strutture dati che non fanno parte del curriculum naturale di autodidatti non-CS. Pratap ha fallito diversi colloqui tecnici durante il suo percorso - lo dice esplicitamente nel suo articolo. La risposta che ha dato è stata investire tempo specifico nella preparazione ai colloqui tecnici come dominio separato dall'apprendimento della programmazione in generale.

Questa distinzione è importante: saper programmare e saper passare un colloquio tecnico sono competenze correlate ma non identiche. Ignorare questa distinzione porta a lunghi periodi di candidature fallite anche con competenze tecniche reali. La preparazione ai colloqui tecnici - LeetCode, algoritmi di base, strutture dati classiche - richiede uno studio specifico che va fatto in parallelo alla costruzione del portfolio, non dopo.

Un ex-giurista che affronta la preparazione ai colloqui tecnici porta un vantaggio specifico: la capacità di strutturare argomenti in modo logico e di comunicare il proprio ragionamento mentre risolve un problema. Questa capacità - che i developer CS spesso non hanno sviluppato in modo esplicito - è un fattore che nei colloqui "algoritmo + spiegazione" può fare la differenza tra un candidato che sa fare ma non sa comunicare e uno che sa fare e sa spiegare perché.

Cosa ha funzionato (Zubin Pratap)

Pratap ha documentato in dettaglio cosa ha funzionato nel suo percorso. Le pratiche che emerge dalla sua testimonianza si articolano intorno a pochi principi coerenti - non strategie isolate ma una filosofia di apprendimento che si è rivelata efficace nel lungo periodo.

1. Apprendimento continuativo e non intensivo

Pratap non ha fatto un bootcamp intensivo di tre mesi. Ha imparato in modo continuativo, ogni giorno, per anni, in parallelo al lavoro di avvocato. Questa scelta non era necessariamente quella più rapida - un bootcamp a tempo pieno avrebbe probabilmente compresso il tempo di apprendimento. Era quella più sostenibile per la sua situazione finanziaria e professionale.

Il pattern dell'apprendimento quotidiano continuativo - anche solo 1-2 ore al giorno - ha dimostrato di produrre risultati più solidi a lungo termine rispetto all'apprendimento intensivo seguito da periodi di inattività. Questo perché la programmazione richiede sedimentazione: concetti che sembrano chiari subito spesso richiedono di essere applicati più volte in contesti diversi prima di diventare parte del modo di pensare. Un ciclo for scritto oggi, dimenticato per due settimane, e poi riscritto da zero non produce lo stesso apprendimento di un ciclo for usato in contesti diversi ogni giorno per due settimane.

Per un giurista che lavora a tempo pieno, questo significa: trovare il momento del giorno in cui si è più freschi - mattina presto, pausa pranzo, sera tardi a seconda del ritmo personale - e proteggerlo come tempo di apprendimento. Non "appena ho tempo libero" ma "ogni giorno a quest'ora". La regolarità vale più del volume.

2. Costruire cose reali il prima possibile

Pratap ha iniziato a costruire progetti reali - piccoli, imperfetti, ma funzionanti - molto prima di sentirsi "pronto". Questa scelta ha accelerato il suo apprendimento in modo significativo, perché costruire cose reali espone a problemi reali che i tutorial e i corsi online non coprono: debugging, deploy, dipendenze, versioning, integrazione con sistemi esistenti.

La tentazione di molti autodidatti - studiare ancora un corso prima di costruire qualcosa - è una delle trappole più documentate nel career switch tecnico. Pratap la nomina esplicitamente: a un certo punto ha smesso di studiare per studiare e ha iniziato a studiare per costruire. La differenza nel ritmo di apprendimento è stata significativa.

Per un ex-giurista, il primo progetto reale può essere qualcosa di direttamente connesso al proprio background professionale: un tool che automatizza la generazione di atti tipo, un aggregatore di sentenze su un tema specifico, uno script che analizza la struttura di contratti PDF. Non deve essere sofisticato - deve essere reale, deve risolvere un problema reale, e deve richiedere di affrontare problemi che i tutorial non coprono.

3. Usare il background legale come vantaggio contestuale

Pratap lavora oggi su problemi tecnici che si intersecano con il dominio legale. Non ha dovuto inventarsi un dominio da zero: il suo background giuridico lo ha reso capace di ragionare su problemi di compliance, privacy, contratti digitali, e governance tecnica in modo che molti sviluppatori CS non hanno. Questo "domain expertise" è stato un fattore differenziante nel suo percorso.

La lezione generalizzabile è che il background legale non è solo un ostacolo da superare nel career switch. È anche una risorsa che, nel contesto giusto, diventa un vantaggio competitivo. LegalTech, RegTech, compliance automation, privacy engineering: sono aree in cui il background giuridico è direttamente spendibile come competenza tecnica. Chi viene da giurisprudenza e studia privacy engineering è in una posizione molto più forte rispetto a un developer CS che deve imparare il GDPR on the job - e può portare questa competenza combinata a team che la cercano.

4. Gestire il fallimento come dato, non come giudizio

Pratap ha fallito colloqui tecnici multipli. Ha ricominciato da capo su basi più solide più di una volta. Ha documentato questi fallimenti non come momenti di crisi ma come dati informativi: "questo colloquio mi ha detto che non so abbastanza sugli algoritmi di ordinamento. La risposta è studiare gli algoritmi di ordinamento."

Questo approccio - trattare il fallimento come feedback piuttosto che come giudizio sull'adeguatezza - è coerente con quello che Cal Newport chiama "pratica deliberata": l'apprendimento intenzionale nelle aree di debolezza specifica, guidato dal feedback invece che dalla comfort zone. Il giurista ha un vantaggio qui: la cultura del processo, con i suoi feedback strutturati (sentenza, obiezione, rigetto) ha abituato molti avvocati a gestire il feedback negativo in modo professionale. Portare quella stessa mentalità nei colloqui tecnici falliti - "questo mi dice cosa devo studiare" invece di "questo mi dice che non sono capace" - è un trasferimento diretto di competenza.

5. Costruire visibilità progressiva

Pratap ha scritto della propria transizione, ha contribuito a progetti open source, ha costruito un portfolio pubblico. Questa visibilità progressiva ha avuto due funzioni: da un lato, ha creato evidenze concrete di competenza che poteva mostrare ai selezionatori; dall'altro, ha creato una forma di commitment pubblico che ha reso più difficile mollare nei momenti di difficoltà.

La visibilità non deve essere grande o immediata. Può iniziare con un repository GitHub, un articolo su DEV.to, una risposta utile su Stack Overflow. L'importante è che esista qualcosa di concreto e verificabile che testimoni il percorso. Per un giurista, la capacità di scrivere in modo chiaro e strutturato - sviluppata in anni di redazione di atti e memorie - è un vantaggio diretto nella costruzione di visibilità tecnica: un articolo tecnico scritto da un ex-giurista tende ad essere più leggibile e meglio strutturato di uno scritto da chi non ha quella formazione.

6. Gestire le relazioni professionali durante la transizione

Un aspetto che Pratap menziona - e che viene spesso ignorato nelle guide al career change - è la gestione delle relazioni professionali durante la transizione. Lasciare una carriera legale significa lasciare anche una rete professionale costruita in anni di lavoro. Quella rete non è inutile nella transizione tech: può portare a opportunità in LegalTech, a consulenze ibrida, a clienti che cercano qualcuno che capisce sia il codice sia il diritto. Ma va gestita con cura: presentare la transizione in modo professionale, mantenere le relazioni anche durante la fase di apprendimento, e usare la rete legale come ponte verso la rete tech invece di trattarle come mondi separati.

Framework cognitivo

Il percorso di Pratap non è solo una storia di perseveranza. È anche la prova empirica di un framework teorico che la letteratura sul career change tecnico ha identificato in modo abbastanza preciso.

Career capital e percorsi non lineari (Newport)

Cal Newport in So Good They Can't Ignore You (ISBN 978-1455509126) distingue tra "passione" e "career capital". La passione - l'idea che esistano persone naturalmente predisposte a fare una cosa - è una metafora utile per il marketing dei corsi ma una guida mediocre per le decisioni di carriera. Il career capital è diverso: è l'insieme delle competenze rare e preziose che hai costruito nel tempo attraverso la pratica deliberata.

Pratap aveva career capital legale significativo - dodici anni di pratica in diritto aziendale. Questo non era inutile nella transizione: era il punto di partenza da cui costruire career capital tecnico. La transizione non era un azzeramento; era un'aggiunta a qualcosa che esisteva già.

Newport argomenta che i percorsi professionali non lineari - quelli che sembrano "cambi di rotta" visti dall'esterno - sono spesso costruzioni coerenti viste dall'interno, dove competenze diverse si sovrappongono e si amplificano. Il background legale di Pratap non era la zavorra da eliminare. Era uno degli elementi del valore che ha portato in Google. Il ragionamento logico, la capacità di analisi sistematica, la comprensione delle implicazioni legali dei sistemi tecnici: tutte cose che un developer CS non porta automaticamente, ma che un developer ex-giurista porta come patrimonio.

Il "long game" nei career switch tecnologici

La letteratura sul career change in tech - da freeCodeCamp alle interviste di Career Foundry - converge su un dato: i career switch tecnici che funzionano hanno quasi tutti una caratteristica comune. Non sono sprint. Sono maratone.

Il tempo medio riportato nelle storie verificate di transizione verso ruoli tecnici da background non-CS è di 18-36 mesi per la prima posizione significativa. Pratap è nella parte alta di questa distribuzione - il suo percorso ha richiesto circa cinque anni. Ma la direzione è coerente: aspettarsi di essere pronti in sei mesi è statisticamente improbabile se parti da zero; aspettarsi di arrivare in tre anni è più realistico e permette di pianificare in modo sostenibile.

Questa calibrazione temporale ha conseguenze pratiche immediate: se sai che il percorso richiederà due-tre anni, puoi pianificare le finanze di conseguenza (continuare a lavorare come avvocato mentre studi), puoi gestire le aspettative di famiglia e colleghi, e puoi costruire un piano di apprendimento sostenibile invece di uno sprint che esaurisce le energie dopo tre mesi.

Il vantaggio del "domain expertise" nella specializzazione tecnica

Una ricerca condotta da Stack Overflow (Developer Survey 2023) mostra che il 40-45% dei developer professionali non ha una laurea in informatica o ingegneria informatica. La varianza è ampia: dal frontend puro (dove la barriera di entrata è più bassa) al machine learning (dove le basi matematiche contano di più). Ma il dato aggregate mostra che il background non-CS non è una rarità nel mercato tech.

Quello che è raro, e quindi prezioso, è la combinazione di competenza tecnica con expertise in un dominio specifico. Un developer che capisce il diritto contrattuale - davvero, non superficialmente - è un candidato diverso da un developer CS che deve imparare il diritto on the job. Questa differenziazione è il meccanismo che ha funzionato per Pratap, ed è replicabile. La strategia non è "diventare il miglior developer CS" - quello è un terreno in cui il vantaggio competitivo è difficile da costruire partendo da zero a 35 anni. La strategia è "diventare il miglior developer legale" - un terreno molto meno affollato, con domanda di offerta squilibrata a favore di chi ha entrambe le competenze.

La mentalità del problem-solver vs la mentalità del knowledge-seeker

Un'osservazione che emerge dal racconto di Pratap - e che la ricerca sull'apprendimento adulto conferma - è che gli adulti imparano meglio in contesti orientati al problema che in contesti orientati alla conoscenza astratta. Un giurista di 35 anni che studia Python non è motivato dalla bellezza della sintassi del linguaggio: è motivato dal fatto che Python gli permette di automatizzare qualcosa che altrimenti farebbe manualmente. Costruire l'apprendimento intorno a problemi reali da risolvere - invece che intorno a concetti da padroneggiare - è la strategia più efficace per questa fascia di apprendenti.

Letture e risorse

Il percorso di Pratap non si è basato su una lista di risorse definitiva, ma alcune sono ricorrenti nella sua documentazione e in quella di altri giuristi che hanno fatto la stessa transizione.

La storia di Zubin Pratap in prima persona

• Zubin Pratap, "From Lawyer to Google Engineer" (freeCodeCamp, 2021) - Il racconto in prima persona dell'intera transizione. Onesto sulle difficoltà, preciso sulle pratiche, senza filtri motivazionali. Il punto di partenza obbligatorio per chiunque stia valutando un percorso simile. Pratap racconta i fallimenti nei colloqui, le volte in cui ha ricominciato da capo, il tempo che ci ha messo - e perché ne è valsa la pena.

Libri di riferimento

• Cal Newport, So Good They Can't Ignore You (ISBN 978-1455509126) - Il framework del career capital applicato ai percorsi non lineari. Newport smonta l'idea della "passione preesistente" e la sostituisce con la pratica deliberata come motore della crescita professionale. Essenziale per calibrare la strategia a lungo termine.
• Andy Hunt + Dave Thomas, The Pragmatic Programmer (ISBN 978-0135957059) - Il libro di riferimento per chi impara a programmare in modo serio. Non insegna un linguaggio specifico: insegna un modo di pensare al software che vale per qualsiasi linguaggio. Particolarmente utile per chi viene da un background non tecnico e vuole costruire basi solide senza passare per un'università. Il capitolo sull'apprendimento continuo e sulla pratica deliberata è direttamente applicabile al percorso di transizione.

Risorse online

• freeCodeCamp - Career Change - Una raccolta di storie verificate di persone che hanno cambiato carriera per entrare nel tech. Molto più utile dei blog generici sul career change perché le storie sono specifiche, documentate, e scritte da persone che hanno davvero fatto la transizione. Trovi anche storie da background legali, medici, artistici - la varietà aiuta a capire che nessun background è insuperabile.
• roadmap.sh - Mappa visuale dei percorsi di apprendimento per diverse specializzazioni tecniche (frontend, backend, devops, ecc.). Utile per capire quale sia il percorso più diretto verso il ruolo target - e per non perdere tempo su materie non necessarie. Un giurista che vuole fare backend developer non ha bisogno di studiare design grafico; questa mappa aiuta a evitare le deviazioni inutili.
• Stack Overflow Developer Survey 2023 - Dataset pubblico annuale con statistiche sul mercato del lavoro tech: salari, tecnologie più usate, background educativo dei developer, soddisfazione lavorativa. Utile per calibrare le aspettative in modo basato su dati reali invece che su aneddoti.

Se stai costruendo il tuo portfolio e il tuo CV per candidarti come developer proveniente da giurisprudenza, il CV template che ho preparato include tre esempi concreti - uno dei quali è pensato specificamente per chi viene da un background legale e vuole posizionarsi nel mercato LegalTech o nel tech generale con il background legale come differenziatore invece che come ostacolo. Puoi scaricarlo gratuitamente qui sopra.

Prossimo passo nella serie

Questo articolo ha raccontato la storia di Zubin Pratap e le pratiche che hanno funzionato nel suo percorso da avvocato a software engineer a Google. È un caso di percorso lungo - cinque anni circa dalla prima riga di codice al contratto con Google - e di apprendimento continuativo che non si è mai interrotto.

Il prossimo articolo della serie esplora un caso diverso ma complementare: quello di Fernanda Penna Ribeiro, avvocata brasiliana che ha affrontato il burnout professionale nel 2018 e ha ricostruito la propria carriera tecnica in Europa come backend engineer a STRV. E quello di Benton Wong, che ha attraversato tre carriere diverse - biotech, diritto, leadership aziendale - prima di completare un bootcamp a New York e diventare software engineer a Scribd. Due storie, due traiettorie diverse, un tema comune: come si recupera dopo anni di carriera in un campo completamente diverso, e come si ricostruisce l'identità professionale durante la transizione.

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) - come convivere con la voce che dice "non sei abbastanza", indipendente dal background. Pratap lo menziona esplicitamente: la sindrome dell'impostore è stata una compagna costante per i primi anni della transizione.

Vedi anche: Cosa farei oggi se ricominciassi da zero - una riflessione su come impostare il percorso di apprendimento nel modo più efficiente fin dall'inizio.

Cosa ho imparato scrivendo questo

Scrivere di Zubin Pratap mi ha obbligato a confrontarmi con la differenza tra storie che ispirano e storie che informano. Le storie che ispirano funzionano sull'emozione: il momento di svolta, il sacrificio, l'happy ending. Le storie che informano funzionano sui dettagli: quanto tempo ha richiesto, cosa ha fallito, quali competenze erano necessarie, quali non lo erano.

Pratap ha scritto una storia che informa - e questo è raro. Nella grande maggioranza delle "career change stories" online, i dettagli scomodi vengono levigati: il tempo reale viene compresso, i fallimenti vengono minimizzati, le difficoltà finanziarie vengono elise. Quello che rimane è una storia che sembra fattibile ma non dice davvero come. Pratap ha fatto la scelta opposta: ha scritto di cinque anni, non di sei mesi; ha scritto di colloqui falliti, non solo di quello che ha funzionato; ha scritto di ripensamenti, non solo di determinazione lineare.

Ho imparato che il valore di una storia documentata onestamente non è solo nel messaggio "è possibile". È nel dettaglio operativo: il momento in cui ha smesso di studiare per studiare e ha iniziato a costruire cose; la decisione di non lasciare il lavoro legale prima di avere un piano concreto; la gestione sistematica dei fallimenti nei colloqui come problema da risolvere invece che come conferma di inadeguatezza. Questi dettagli sono la parte utile. E sono quelli che le storie ottimizzate per l'ispirazione tendono a tagliare.

Ho eliminato diverse versioni di questo articolo che aggiungevano dettagli non verificabili sulla storia di Pratap - dettagli plausibili, ma che non erano nella sua testimonianza diretta. Li ho eliminati perché l'onestà sui limiti delle fonti è più utile di una storia più completa ma meno accurata. Quello che è scritto qui viene da quello che Pratap ha scritto lui stesso, o da fonti pubbliche verificabili. Niente di più.

Un'ultima cosa che ho imparato: il contesto del mercato LegalTech - il fatto che il profilo "developer con background legale" sia genuinamente ricercato, non solo tollerato - è una cosa che ho verificato in modo più preciso scrivendo questo articolo. Non è la storia di un talento raro che ha sfidato le probabilità. È la storia di una persona che ha capito dove stava andando il mercato - dove si stava creando domanda per un profilo specifico - e ha costruito le competenze per rispondere a quella domanda. Questa lettura del percorso di Pratap non è meno ambiziosa: è più replicabile.

Se vieni da giurisprudenza e stai valutando questa transizione - o sei già nel mezzo del percorso - mi piacerebbe sapere dove sei. Non per raccogliere testimonianze, ma per capire se quello che scrivo in questa serie risponde a domande reali. 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.