Coding for lawyers

In a couple of weeks I, along with a number of colleagues, will be embarking on a new journey – learning to code. We are piloting a course which has been specifically designed for lawyers in conjunction with CodeClan. CodeClan is Scotland’s first digital skills academy. I have advised them on legal issues since their establishment in 2015. As such, it seemed only fair to give them a chance to turn the tables and teach us, so in October our first steps in coding will begin.

An obvious question is – why are we doing this?

First, it is our desire as advisors to get a better understanding of what it is our clients actually do. More and more companies are, in effect, becoming technology businesses. We want to have practical experience rather than just theoretical knowledge of the fundamental building blocks of these businesses.

Secondly, I am hoping it will validate a long-held belief of mine – that there is common ground between the ways in which lawyers and coders think. The basic concept of “If x, then y” underpins what both professions do. Lawyers use language to capture these concepts (albeit a special form of language, which depending on your viewpoint is either formulated to reduce ambiguities or else designed to make things more complicated than they need to be…), whereas coders of course use a range of different coding languages. The end result in either case is the same: a solution to a problem. No doubt there will be nuances which emerge, but doing this course will allow us to see beyond the “language divide” and find out how much we share.

This leads to the third reason for learning to code, and, for me, the most important. As more processes become automated, I believe the contracts which govern how these processes work will themselves come to be written in code. Contracts will be governing relationships, not just between humans, but between software, systems and machines. For instance, the performance regime for a cloud computing contract might govern how two computer systems interact with each other. A data protection processing agreement might control how customer data is handled between two robo-advisers. A price change formula could link directly to information on exchange rates or inflation. As a result, it will increasingly make sense to write these contracts in a way that can be directly understood by the systems in question, rather than in a way that needs translation by humans at both ends.

Overall, I think that lawyers being able to understand code, work with coders, and ultimately deliver contracts in code is what clients will soon come to expect. So that’s why we are taking this first step.


This article was also published on LinkedIn by John McKinlay and is re-published here with the permission of the author. The information and views set out in this article are those of the author alone.

The author is  head of DLA Piper’s Scottish Technology and Intellectual Property practice, advising a range of businesses and public sector organisations on contractual, technology and intellectual property matters.

Image credit: https://techdaily.ca/