From law school to developer: the long path is possible

Starting Background

Zubin Pratap is not an isolated case. But he is one of the best-documented: he wrote about his own transition in the first person, with a level of detail and honesty that makes his account rare in the "career change story" genre - a genre often dominated by simplified and optimistic versions of paths that in reality were far more complicated.

The basic biographical data: Pratap graduated in law in India, practiced as a corporate lawyer for over a decade - first in India, then in Australia - and began learning to program self-taught in parallel with work, without leaving the legal profession overnight. He wasn't a young person getting bored. He was a mid-career professional with a consolidated professional network, a stable income, and the concrete prospect of a legal career that would have continued to advance.

What drove him toward programming was not a moment of illumination or a professional crisis. It was something more subtle: curiosity toward a domain that he himself describes as "the future of law and business" - and, over time, the discovery that programming engaged him in a different and deeper way than legal work. But this discovery came later, not before. At the beginning it was an experiment.

The path from that initial experimentation to the Google contract required years. Not months. Pratap was explicit about this: it wasn't a six-month bootcamp and a brilliant portfolio. It was continuous learning, failures in technical interviews, starting again on more solid foundations, and a level of persistence that he himself defines as the most important variable in the entire journey.

Why is Pratap's story relevant for those coming from a legal background? Because it represents a boundary case in the positive sense: if the path is feasible at 39, after twelve years of legal career, starting from scratch with programming, then the variables that matter are not age and not the specific background. They are others.

This article analyzes them. Not as a list of generic advice, but as a coherent structure extracted from what Pratap himself documented - and from what the literature on technical career changes confirms.

If you come from law and are wondering whether the transition is possible, the short answer is: yes. The long answer is this article.

The legal market context pushing toward transition

It's worth contextualizing Pratap's case within a broader trend. The legal job market - in many countries, including Italy - is undergoing a structural transformation driven by automation. Many activities that occupied junior lawyers and paralegals - legal research, contract review, documentary due diligence, drafting standardized documents - are already partially or totally automatable with legal AI tools available today: Ross Intelligence, Contract Pilot, Lexis+ AI. This automation reduces demand for junior legal profiles and creates demand for technical profiles capable of building, implementing, and managing these tools.

Pratap anticipated this trend - not necessarily as a conscious prediction, but as an intuition that "the future of law runs through technology." Those who come from law today and are considering the tech transition are not only fleeing the legal profession: they are potentially ahead of a change that will affect the entire profession in the next decade. This changes the frame: it's not "abandoning a legal career," it's "anticipating the future of the legal sector."

The LegalTech profile - a developer who understands law - is one of the most sought-after profiles in the European tech market right now. Legal startups, banks with compliance departments, insurance companies with internal legal offices, large law firms building their own digital tools: all are looking for technical profiles with legal backgrounds. It's a small niche but with supply-demand imbalance in favor of those who have both competencies.

Typical Difficulties

Those coming from law who approach programming encounter specific difficulties that those from other non-CS backgrounds don't necessarily share. It's worth naming them precisely, because naming them is the first step to not being caught off guard.

Normative thinking vs procedural thinking

Legal training is built on normative thinking: the interpretation of rules, the search for precedent, the construction of arguments based on authority sources. Programming - particularly basic computer science - requires a different type of thinking: procedural, algorithmic, oriented to the step-by-step execution of instructions that a machine can follow without ambiguity.

These two types of thinking are not incompatible. But the transition from one to the other requires a specific cognitive activity that many ex-lawyers describe as "learning to think differently" - a vague expression, but one that hides something real. The lawyer is accustomed to reasoning about cases where interpretation has room. The algorithm has no room: it works or it doesn't.

The practical difficulty emerges especially in the early stages of learning, when fundamental concepts - variables, types, loops, conditions, functions - seem elementary but require a mental frame change that doesn't always happen immediately. Many ex-lawyers describe the first months as specifically frustrating: "I can already do complex things in my field, why can't I do this simple thing?"

The answer is that it's not simple. It's different. And "different" requires adaptation time, regardless of intelligence level or learning capacity. The lawyer who was frustrated because they "didn't understand recursion" was often setting up the problem incorrectly: they were looking for the legal rule governing the case (there's always a norm that applies) instead of building a mechanism that calls itself. These are two fundamentally different types of reasoning.

The wrong credential in the wrong context

A lawyer looking for work as a developer finds themselves in a paradoxical position: they have a strong credential - the law degree - which in the tech job market is almost irrelevant as a technical signal. Indeed, it can be counterproductive in some contexts, because the selector wonders "why does a lawyer want to be a developer?" before even evaluating technical skills.

Pratap addressed this situation directly: he built his portfolio before applying, contributed to open source projects, and used his story as a differentiator instead of hiding it. But this requires a quantity of preparatory work that those from a CS background don't have to do in the same measure.

The legal credential is not useless in the tech market: it's poorly positioned if used in the wrong context. In a startup building generic software, the law degree is essentially irrelevant. In a LegalTech startup, in a bank's compliance team, or in a company developing automated contract tools, it becomes a differentiating asset. The effective strategy is not to hide the background, but to position yourself in contexts where that background has value.

The weight of perceived opportunity costs

Leaving an established legal career - with its status, professional network, and often an above-average salary - to restart as a junior developer with a lower salary is a trade-off that many lawyers struggle to make even when the motivation is real. This isn't irrationality: it's the correct evaluation of a concrete opportunity cost.

Pratap didn't leave immediately. He studied in parallel for years before making the leap. This is one of the most documented strategies among those who have made this transition successfully: reducing financial risk by studying overlapping with existing work, instead of leaving everything on day one.

There is also a professional identity aspect tied to the perceived opportunity cost. A corporate lawyer with ten years of experience restarting as a junior developer doesn't lose only salary: they lose status, they lose the professional network that matters for that role, they lose the security that comes from being competent in a recognized way. These costs are real and must be accounted for before deciding. But they are also temporary: after three years of technical work, seniority rebuilds - and often on stronger foundations, because the person brings domain understanding they didn't have before.

The technical interview as a specific obstacle

Technical interviews for entry-level positions in software engineering often evaluate skills in algorithms and data structures that are not part of the natural curriculum of non-CS self-taught people. Pratap failed multiple technical interviews during his journey - he says so explicitly in his article. The response he gave was to invest specific time in preparing for technical interviews as a domain separate from learning programming in general.

This distinction is important: being able to program and being able to pass a technical interview are correlated but not identical skills. Ignoring this distinction leads to long periods of failed applications even with real technical skills. Preparation for technical interviews - LeetCode, basic algorithms, classic data structures - requires specific study that must be done in parallel with building the portfolio, not after.

An ex-lawyer approaching technical interview preparation brings a specific advantage: the ability to structure arguments logically and to communicate their reasoning while solving a problem. This capability - which CS developers have often not developed explicitly - can make a difference in "algorithm + explanation" interviews between a candidate who can do it but can't communicate it, and one who can do it and can explain why.

What Worked (Zubin Pratap)

Pratap documented in detail what worked in his path. The practices that emerge from his testimony are organized around a few consistent principles - not isolated strategies but a learning philosophy that proved effective in the long term.

1. Continuous, non-intensive learning

Pratap didn't do an intensive three-month bootcamp. He learned continuously, every day, for years, in parallel with his lawyer work. This choice wasn't necessarily the fastest - a full-time bootcamp would probably have compressed learning time. It was the most sustainable for his financial and professional situation.

The pattern of continuous daily learning - even just 1-2 hours a day - has proven to produce more solid results over the long term compared to intensive learning followed by periods of inactivity. This is because programming requires sedimentation: concepts that seem clear immediately often need to be applied multiple times in different contexts before becoming part of the way you think.

For a lawyer working full-time, this means: find the time of day when you're freshest - early morning, lunch break, late evening depending on personal rhythm - and protect it as learning time. Not "whenever I have free time" but "every day at this time." Regularity is worth more than volume.

2. Building real things as soon as possible

Pratap started building real projects - small, imperfect, but functional - long before feeling "ready." This choice accelerated his learning significantly, because building real things exposes you to real problems that tutorials and online courses don't cover: debugging, deployment, dependencies, versioning, integration with existing systems.

The temptation for many self-taught people - to study one more course before building something - is one of the most documented traps in technical career switching. Pratap names it explicitly: at a certain point he stopped studying to study and started studying to build. The difference in learning pace was significant.

For an ex-lawyer, the first real project can be something directly connected to their professional background: a tool that automates the generation of standard documents, an aggregator of rulings on a specific topic, a script that analyzes the structure of PDF contracts. It doesn't need to be sophisticated - it needs to be real, solve a real problem, and require facing problems that tutorials don't cover.

3. Using legal background as contextual advantage

Pratap works today on technical problems that intersect with the legal domain. He didn't have to invent a domain from scratch: his legal background made him capable of reasoning about problems of compliance, privacy, digital contracts, and technical governance in ways that many CS developers don't have. This "domain expertise" was a differentiating factor in his journey.

The generalizable lesson is that the legal background is not only an obstacle to overcome in the career switch. It's also a resource that, in the right context, becomes a competitive advantage. LegalTech, RegTech, compliance automation, privacy engineering: these are areas where the legal background is directly applicable as technical expertise.

4. Managing failure as data, not as judgment

Pratap failed multiple technical interviews. He started over on stronger foundations more than once. He documented these failures not as crisis moments but as informative data: "this interview told me I don't know enough about sorting algorithms. The answer is to study sorting algorithms."

This approach - treating failure as feedback rather than as a judgment on adequacy - is consistent with what Cal Newport calls "deliberate practice": intentional learning in areas of specific weakness, guided by feedback rather than comfort zone.

5. Building progressive visibility

Pratap wrote about his own transition, contributed to open source projects, built a public portfolio. This progressive visibility served two functions: on one hand, it created concrete evidence of competence that he could show to selectors; on the other, it created a form of public commitment that made it harder to quit in moments of difficulty.

For a lawyer, the ability to write clearly and in a structured way - developed in years of drafting documents and briefs - is a direct advantage in building technical visibility: a technical article written by an ex-lawyer tends to be more readable and better structured than one written by someone without that training.

Cognitive Framework

Pratap's journey is not only a story of perseverance. It's also the empirical proof of a theoretical framework that the literature on technical career changes has identified fairly precisely.

Career capital and non-linear paths (Newport)

Cal Newport in So Good They Can't Ignore You (ISBN 978-1455509126) distinguishes between "passion" and "career capital." Passion - the idea that naturally predisposed people exist - is a useful metaphor for course marketing but a mediocre guide for career decisions. Career capital is different: it's the set of rare and valuable skills you've built over time through deliberate practice.

Pratap had significant legal career capital - twelve years of practice in corporate law. This wasn't useless in the transition: it was the starting point from which to build technical career capital. The transition wasn't a reset; it was an addition to something that already existed.

The domain expertise advantage in technical specialization

Stack Overflow Developer Survey 2023 data shows that 40-45% of professional developers don't have a degree in computer science or computer engineering. What is rare, and therefore valuable, is the combination of technical competence with expertise in a specific domain. A developer who truly understands contract law - genuinely, not superficially - is a different candidate from a CS developer who has to learn law on the job. The strategy is not "become the best CS developer" - that's terrain where competitive advantage is hard to build starting from scratch at 35. The strategy is "become the best legal developer" - a much less crowded field, with supply-demand imbalance in favor of those with both competencies.

Reading List and Resources

• Zubin Pratap, "From Lawyer to Google Engineer" (freeCodeCamp, 2021) - The first-person account of the entire transition. Honest about difficulties, precise about practices, without motivational filters. The mandatory starting point for anyone considering a similar path.
• Cal Newport, So Good They Can't Ignore You (ISBN 978-1455509126) - The career capital framework applied to non-linear paths. Essential for calibrating long-term strategy.
• roadmap.sh - Visual map of learning paths for different technical specializations.
• Stack Overflow Developer Survey 2023 - Annual public dataset with statistics on the tech job market.

If you're building your portfolio and CV to apply as a developer coming from law, the CV template I've prepared includes three concrete examples - one specifically designed for those coming from a legal background and wanting to position themselves in the LegalTech market or general tech with the legal background as a differentiator rather than an obstacle. You can download it for free above.

Next Step in the Series

This article told the story of Zubin Pratap and the practices that worked in his path from lawyer to software engineer at Google. It's a case of a long journey - about five years from the first line of code to the Google contract - and continuous learning that never stopped.

The next article in the series explores a different but complementary case: that of Fernanda Penna Ribeiro, a Brazilian lawyer who faced professional burnout in 2018 and rebuilt her technical career in Europe as a backend engineer at STRV.

Return to the series cornerstone for the complete view of all 20 planned articles and the career matrix with 12 paths.

What I Learned Writing This

Writing about Zubin Pratap forced me to confront the difference between stories that inspire and stories that inform. Stories that inspire work through emotion: the turning point, the sacrifice, the happy ending. Stories that inform work through details: how long it really took, what failed, which skills were necessary, which weren't.

Pratap wrote a story that informs - and this is rare. In the vast majority of "career change stories" online, the uncomfortable details get smoothed away: the actual time gets compressed, failures get minimized, financial difficulties get erased. What remains is a story that seems feasible but doesn't really explain how. Pratap made the opposite choice: he wrote about five years, not six months; he wrote about failed interviews, not only what worked; he wrote about second thoughts, not only linear determination.

If you come from law and are considering this transition - or are already in the middle of the path - I'd like to know where you are. Write to me at federico@federicocalo.dev.

I'll reply. Always.