What it’s Like Learning to Code as a Lawyer (Part 2)

I left my large law firm job to launch my own tech start-up, and unexpectedly found myself learning how to code. 

This is the second article in a two-part series about what it’s been like learning to code as a lawyer. For more background, check out part 1 here.

Trial and error is a thing

You don’t need permission from anybody to learn how to code. Assuming you have access to a computer, you can not only start writing code, but rapidly improve through trial and error in a way that simply isn’t feasible in law. 

As a junior lawyer, you’ll work on a document until it looks good, submit it to your senior, then hold your breath hoping you didn’t mess up too much. As someone learning to code, I can write a few lines and then immediately test that code by running it on my own computer to see if it works or otherwise what the problems might be.

This made me wonder: is it possible to test legal documents in a similar way? Most lawyers perform some degree of thought experiment as they write, evaluating how their drafting would stand up against the most likely hypothetical scenarios or counterarguments. This is necessarily limited to what the lawyer can foresee. Could there be a way to test legal documents more comprehensively? If you could, would this result in tighter drafting, or would it simply tell us that no drafting is ever immune from attack? 

The good, the bad and the ugly of testing

Perhaps what would actually happen is that lawyers would work even longer hours trying to plug every potential problem surfaced by this presumably GPT10-powered quality-control bot, no matter how remote.

The instant feedback available through testing and debugging your code is fantastic. There’s no waiting for the partner to get around to reviewing your work, or wondering what holes are currently being identified by your client or the other side.

The trial and error method has some major drawbacks though. You test one approach; it doesn’t work. You tweak your code; it still doesn’t work. You do more Googling and try again; still nothing. Rinse and repeat, and suddenly it’s 3am. But you keep going because there’s a chance the solution is just around the corner. It can be hard to stop when you think you’re so close.

Always be learning

It’s a fantastic feeling when your code finally does work. You can go to bed, for starters. But similar to legal drafting, just because it works doesn’t mean it’s good. Is it succinct, is it efficient, is it easy to follow, is it user-friendly for others who might need to modify it in the future? These questions are familiar to lawyers and coders alike.

Similarly, what do we do with those chunks of drafting that we don’t truly understand but which were in the sample code or precedent document? Are they to cover some fringe case? Are they hangovers from the base document that aren’t applicable to our situation? Wiser minds surely put them there for a reason…

The learning never stops. You can’t complete an online course and declare you’ve now learnt coding any more than getting your unrestricted legal practising certificate and believing you now know everything there is to know about the law.

So … should lawyers learn to code?

The inevitable question that follows from all of this is whether lawyers should learn to code. Thinking about my own experience, I would say do it if you want to, but it probably won’t make you a better lawyer. Unsurprisingly though, you will understand legal tech products better.

Most lawyers realistically won’t have the time to jump into full-on coding. If you’re still interested in developing technology solutions, you could instead learn to use a no-code tool like Josef or Checkbox. This is how I got started many years ago, together with writing document automations, simple websites, and macros in Office.

I hope you’ve enjoyed reading a bit of what it’s been like learning to code as a lawyer. You can follow my journey on LinkedIn, and please don’t hesitate to DM me if you want to get in touch!

 
Daniel Yim writes and teaches on legal technology and transformation. He is the founder of technology start-ups Sideline and Bumpd, and previously worked worked at Gilbert + Tobin and Axiom.

Also read top viewed Ai Legal article: The Role of AI in Legal Research.