Lawyer and programmer: why I do both

Two worlds, long kept apart

I registered my first business in 2001, while still at school. I had taught myself to code, HTML, CSS, PHP and MySQL, with no course and no degree. The first project turned ring binders full of audits into an intranet. After that came web projects for clients, an online shop, intranet systems and my own web hosting. Alongside all this, I studied law. The two worlds ran side by side for years without ever touching.

It was only in 2014, at the end of my studies, that legal tech arrived in Germany. By then I had more than ten years of digital projects behind me and realised that what I had learned could be transferred to the world of law. I have been a lawyer since 2015 and am now a certified specialist in employment law. And I still write code myself. The reason is simple: each of the two sides makes me better at the other.

What the code teaches the lawyer

If you write code yourself, you know what is technically realistic in a project and what merely sounds good. In day-to-day law firm work, that is worth more than it first appears. Software providers promise a great deal, and if you do not understand the technology behind it, you can hardly judge those promises. I see more quickly whether a feature will hold up in practice or only on the presentation slide.

Programming also forces a way of thinking that lawyers rarely practise. Every step has to be unambiguous, every exception needs a rule, and whatever is not described does not happen. Once you have cast a process in software, you look at your own law firm work differently. You ask which steps repeat themselves and which depend on the individual case. I ask that question at the start of every project, because it determines the effort involved and whether it succeeds.

What the lawyer teaches the code

The reverse also holds: without practice as a lawyer, no good legal tech product emerges. That is why in 2015 I first worked at a commercial law firm, with my own caseload, my own matters and my own signature. If you do not know day-to-day law firm work from doing it yourself, you build software that passes by the very people who are meant to work with it.

As a lawyer, I also know where software has to stop. Litigation, negotiations and strategic advice depend on the individual facts and remain a matter for the lawyer. What can be standardised is what repeats and applies equally to everyone, such as data protection obligations, contracts based on templates, or deadlines and standard letters. A programmer without legal practice will barely recognise that boundary. They then build too much, or the wrong thing.

The gap between the languages

In many legal tech projects, lawyers and developers work alongside each other rather than with each other. One side thinks in statutory provisions, the other in data models. In between, a gap opens up in which time, money and good ideas are lost. The lawyer describes a legal assessment the way they have it in their head. The developer hears something different and builds it the way they understood it. Both only notice the difference once the software is finished.

I close that gap because I speak both languages. I can translate a legal assessment into decision logic and explain to a developer why an exception is a case of its own. And I can explain to a lawyer why their request means several weeks of work, even though it looks like nothing more than an extra field. In both of my companies I have led teams of lawyers and developers, and that translation was needed every single day.

Why I still write code myself

One could object that a lawyer with an understanding of technology is enough and that the coding can be left to others. I see it differently. If you hand the code over, you lose your feel for what it costs. That is why I still write it myself, these days with AI support. I rebuilt my own website that way, including a lean editorial system for this blog.

In doing so, I learned a lesson that applies to law firms too. A first draft text I had the AI write as a test was bloated, barely comprehensible, a piece of nonsense. Out of that came a binding writing guide: invent nothing, no stock phrases, short sections, always a conclusion. AI works fast, but it needs clear rules, and someone has to check the result. That is true in programming as in writing, and in a law firm it is all the more true.

What small law firms can take from this

Hardly any owner of a small law firm is going to start learning PHP now, and nobody needs to. Three things from my experience can still be transferred. First, before buying software it is worth asking which work in the firm really repeats itself. Only there does technology pay off. Second, it helps to describe your own work as precisely as a programmer needs it: step by step, with every exception. The gap between the languages only closes if one side moves.

Third, software is only successful once the people in the firm understand it, can operate it and are happy to use it. I carried out the digitalisation of my own caseload at my former firm myself and wrote a book chapter about it. The most important part of it was acceptance within the team.