For the past six years, the main course I have been teaching - at various places - is an introduction to Python for legal data analysis. I created it entirely, as a self-taught coder, on the model of my (likewise self-taught) colleague Wolfgang Alschner’s similar course based on R (and his website: data science for lawyers).
The course is designed to cover all basics of coding as applied to text data (not necessarily legal - we start with this marvelous poem by Mervyn Peake), and in particular data collection and cleaning (we do a lot of scraping). Students are graded on a final group project that requires the constitution and analysis of a novel legal dataset.
All told, a few hundred students have now taken the course, and some might have even learned something from it.1 But I certainly did, and I thought it’d be worth sharing these insights.
(Teaching this subject has obviously changed a lot now with LLMs, but this will be the subject of a future post.)
When introducing the course to another institution or to the students themselves, I generally frame it around three main purposes:
Making the students conversant in the language of technology;
Performing actual “legal data analyses”; and
Facilitating automation.
A few more words on each of these goals.
The digital fracture is not where you expect
There is a common preconception that younger generations are “digital natives”, adepts of new technologies, able to use these to their fullest and achieve great things at the stroke of a keyboard. And this proficiency presumably comes from a deep knowledge of these new technologies.
This might be true for some, but I found2 this idea wide of the mark: in general, your average 20-something years old is not more tech-aware than older generations. In some respects, he or she is in fact markedly worse at dealing with technology.
My favourite example here is the folder-file system or architecture, the idea (and I find it weird to even have to spell it out) that one works on a computer on the basis of files that are organised through a hierarchical structure of folders, subfolders, etc. This sounds basic, right ?
Wrong. I can vouch for the accuracy of what’s reported in this 2021 article from The Verge:
Garland thought it would be an easy fix. She asked each student where they’d saved their project. Could they be on the desktop? Perhaps in the shared drive? But over and over, she was met with confusion. “What are you talking about?” multiple students inquired. Not only did they not know where their files were saved — they didn’t understand the question.
A typical introduction to Python has to teach about file-folder navigation - this is critical to then progress to data saving and fetching, and an excellent introduction to structured content extraction (since .xml, .html, etc. structures are hierarchical as well). Yet, every year, I find that a third of my student batch is in the same situation: to my dismay, they have simply no clue about the existence of folders. Even “files” is sometimes a nebulous concept to them.
This extends to many different facets of day-to-day tech life: there is very little understanding of what a server does, how wifi work, what happens when you input a URL in a browser, let alone what’s “binary”.
I am not laying any blame here: this makes perfect sense given the cycles of technology, where tech artefacts do, indeed, become indistinguishable from magic, but a magic that one uses every day without a single hiccup. Aside from curiosity, learning “how things work” is often downstream of things breaking (e.g., manually fiddling with the IP addresses on a router), and a lot of things do not break anymore3 - if anything, they have become more convenient (e.g., MacOS’s Finder might explain why younger generations don’t know about folders).
That’s why learning to code is also an introduction to “how these things you use every day in fact work”. This is often necessary to then build an understanding of what can and cannot be done with computers, which then allows - hopefully - my students to converse with engineers or legal tech providers on a better basis, not only to understand their offerings, but to seek out new products as well.
The law is a dataset
Empirical legal analysis is a weird part of legal academia, as it challenges a key tenet of what jurists hold dear: their assumption that only a legal education provide you with a distinct way of approaching the “legal” matter, and that this distinct way is primarily qualitative - what you would call “close reading”. This sits badly with approaches that are interested in “distant reading”, and most scholars still look dimly at borrowing from the tool stack of political scientists or - horresco referens - economists.
To this day, every academic paper I author in this field requires the necessary throat-clearing paragraphs along the lines of “of course, quantitative research is bad and shameful, full of bias and neoliberalism, unable to match the empyrean heights of critical close reading, but I tried to do it anyway in the hope I could confirm what qualitative scholars already know and have demonstrated so well in the past”.
All this to say, it’s not necessarily easy to go in front of students, taught to think in terms of “case studies”, and convince them that a holistic view of the legal domain, based on a properly-collected dataset, has merits.
And yet it does, and increasingly so, for a few reasons.
First, the increase in legal material, such that it is insufficient to just know the one big case, or the super-authoritative doctrinal commentary. They are now a dime a dozen, and you are missing out on some possible legal input if you just focus on the obvious candidates.
Second, the added value of empirical legal arguments. Saying “this court did X” is good; arguing that “Y% of all courts on this subject did X” is also good, and we now have the means to invoke the latter argument.
Third, the exploration (legal research) - exploitation (legal drafting) tradeoff has shifted in favour of exploration, made easier by better databases and legal search tools, and of course AI agents.
I frequently introduce this point with an example: years ago I was asked to compile “best practices” in the field of investment facilitation for an African Regional Economic Community, for a 40-page report. Traditionally, lawyers would have (at most) read the dozen top academic or policy papers in this field, skimmed through the few recent treaties or national laws, and in general echoed the same tired examples invoked by everyone else.4 I went about it differently: I scraped all possible norms on the subject, labelled them through machine learning, and looked at outliers (computationally-defined) to find new ideas. The resulting report had the strength of being exhaustive, and came with a 600-page compendium of all relevant norms and languages, for immediate action should they decide to draft a new instrument. (Whether the client preferred this approach or would have been fine with the standard one is a different question.5)
More broadly, I see an increasing number of examples where law-as-data approaches are gaining ground and taking a spot in the range of legal arguments, from corpus linguistics to citation networks and predictive modelling. The key move in these examples is similar: changing the unit of analysis from the document to the corpus.
But getting there requires exactly what I teach: the first step of thinking that the law is, in some ways, a dataset.
Opening up potentials
The most important part of the course is about automation.
It is also the hardest to explain to students: many have an (extremely) wrong notion of what legal professionals do, and in particular junior legal professionals, and thus my insight that “robots can do a lot of stupid tasks better than you” often hits a dead wall: what stupid tasks ? Surely no one will ever ask us to rename thousands of file names over a sleepless night, right ?6
And yet, ultimately, this is the best part about knowing how to code. My own practice has been transformed by the many automations I have developed along the way, and especially since AI has made coding all the easier.
And for that, you often need to know that you can code things, and to adopt a “software vision”; as put by Jasmine Sun:
If you tell a friend they can now instantly create any app, they’ll probably say “Cool! Now I need to think of an idea.” Then they will forget about it, and never build a thing. The problem is not that your friend is horribly uncreative. It’s that most people’s problems are not software-shaped, and most won’t notice even when they are.
A lot of what I am trying to do is to prepare my students to see that some problems are exactly software-shaped - hopefully so that they can build the software themselves.
I also generally try to convey the fact that coding has its own way to bring happiness: legal research is - generally - never truly over: there are more arguments you could have considered, further lines of inquiry, comparative approaches, etc. - many stones left unturned before you decide to submit a legal brief. Whereas an automation tool, when it works, works. You can stop, and enjoy having achieved success (and then start thinking of additional features, but still). And if it works well, you don’t have to change it ever again (some of my scraper bots have now been running for over five years with limited maintenance).
This is a very particular type of contentment that I wish everyone to feel.
I was particularly struck by this interview with Jamie Tso, a senior associate at Clifford Chance, explaining how and why he started coding internal tools for his firm,7 and notably his mention of:
a world with more just-in-time, disposable software, tools built to solve a specific pain point for a specific workflow, then replaced or disposed when the workflow changes. In that world, long-term maintenance matters less.
The same goes for scalability. Lawyers don’t all work the same way – teams and practice groups have their own habits and workflows – so many internal tools don’t actually need to scale to 1,000 people globally. They just need to work well for the users who need them.
And for that to happen, you’ll need lawyers either able to describe very well and precisely their needs to an engineer (and the best way to do that is to know technology), or to do it themselves. Teaching is not only (or even at all) about conveying information, but it is often about allowing recognition, being able to discern patterns in data and experience.
Of course, this is where AI will be the most useful: in making that even more achievable for lawyers. But to do this, you still need the rudiments of coding. As put by Dean Ball:
Learning the basics of why computers work is extremely useful for making the most of coding agents; it will make you a better “prompter.” Learning the foundational aspects of programming languages similarly seems important. Understand how to think computationally now matters more.
(I’ll have more to say on this subject.)
Conclusion
Why do I keep teaching this course, and why do I keep rebuilding it year after year ?
Because learning to code is not about turning law students into engineers, nor even about making them “technical” in any fashionable sense. It is about acquiring a working mental model of what computers can and cannot do, of what it means to structure information, and of how much of legal work consists in repeatable operations that can (and sometimes should) be automated away.
In that sense, teaching Python to law students is not a vocational bet on any particular technology. It is a bet on intellectual autonomy and curiosity. That should age well.
A short note: most of the students elect to take my course, which means that they were eager (or at least professed to be eager) to learn about coding from scratch. The one time we experimented with making it a compulsory subject, however, I had to face the difficulty of convincing law students to take on a technical project, their idea being that they went to law school precisely to avoid engineering school.
Of course, sample bias, etc. - I mostly teach to French law students.
Note that this is also why I argue that people should learn how LLMs work now - because of all the times they don’t generate a proper output - but I don’t rule out that this will go the way of, say, emails, where it serves little purpose for most people to understand or even be aware of the TCP/IP protocol.
And I know this because, as often with these kinds of international consulting assignments, past reports on the exact same subject and been compiled for the same client and were sitting in a drawer.
See previous footnote.
My favorite example here, and I’ll probably discuss it in more detail in a future post, is the student telling me that AI will help liberate time for junior lawyers to meet the clients and participate in the strategy of their future Big Law firms. I had to break it to them that, probably, the client does not want to meet them.
One thing that resonated here is Jamie’s point that he started building tools for his colleagues. This was also my experience: I built my first “bot” after taking over from a colleague on vacation, and finding out that some of her work could be very happily automated.
Bang on! Most lawyers aren't that good at IT or code. Apart maybe tax lawyers (they know maths etc.).