When Simon Deane-Johns posted a simple question for members of the SCL LinkedIn group I doubt that he expected quite the level of response he received. Simon’s question ‘Are you a lawyer who learned to code? How did it go? Any top tips on how to go about it?’ has provoked a series of detailed responses that suggest a wider interest in coding among SCL members than I had ever envisaged.
If you have the same question in mind then the full discussion and tips can be accessed here, but allow me to share a few perceived highlights:
· Be clear what you want to achieve with coding – what do you want to use it for? However, you may need to experiment first to help define workable goals;
· Consider investing in a Raspberry Pi – it is a small investment and protects you from ruining a main computer while learning;
· Help with coding is widely available on the Web;
· Choose your language carefully – among many suggestions, Python, Perl and PHP seemed popular in the LinkedIn discussion;
· Go for an easy, attainable program first, such as ‘Hello World’;
· Be persistent and accept that it is not going to work first time.
As Charles Drayson points out, ‘It’s not unlike learning to practice law (but more methodical) in that one has to amass quite a lot of knowledge before doing anything actually useful. Unless used, and kept up to date, the knowledge quickly fades.’ Neil Brown also offered a reminder that perseverance was needed:
‘Just as one would not expect to turn up at university and immediately draft a perfect new emoney licensing regime, or a major procurement agreement and understand how it all works and hangs together, neither is it realistic to think that, on the first day, one will be have finished the successor to Firefox. Little steps, making sure that you understand why you are doing what you are doing at each step, and just enjoying the experience.’
But what interested me just as much as the range of considered tips on how to go about coding was the motivation. Is it based on a natural geeky curiosity which few would find surprising in an IT lawyer? Is it driven by a desire to work more efficiently? While few would doubt that knowing how things work is a real advantage to an IT lawyer, is it really necessary to know at the coding level? It is a plus for a road traffic lawyer to know how cars work, in real detail, but building a car may seem like a step too far. One motivation might be the need to keep pace with your children, with some added insight into hands-on IT as a bonus.
One thing is clear from the LinkedIn discussion, a number of the IT lawyers who code came from a computing background and entered into a legal career after an earlier flirtation with, or in some cases a long-lasting marriage to, a computer career. But the urge to code and have control does not seem to have left them.
Simon Deane-Johns explains his motivation:
‘Despite working with and around computers since 1990, I can’t really tell one what to do – at least not in any language it will respond to. But as internet and mobile technology becomes ever more accessible, it’s becoming clear that computer programming is something I should learn. After all, it’s really about writing rules and I write contracts all the time. Since writing the article on Linked Data for Computers & Law, it’s also occured to me that more and more legal contracts should be capable of being acted upon by machines without any human intervention. So I’ve decided to get a Raspberry Pi and give it a whirl. No doubt I’ll struggle to find the time, and maybe the kids will learn faster than me, but so it goes with the guitar and piano. Hopefully it will be as much fun.’
As Simon’s reference to ‘it’s really about writing rules’ highlights, some of the pluses of learning to code seem to go beyond the nitty-gritty. Approaches to coding and approaches to legal work can be complementary and create a synergy that helps with both. As Tanya Layng puts it:
‘I found a lot of the skills were transferable. …, coding is definitely logical (it’s all about the logical 1’s and 0’s – i.e. the yes or the no). If you take a step back to see the bigger picture and where you want to end up (ideally…..i.e. your best case scenario), you can walk through the logical progression (IF this happens, THEN this should happen ELSE this other thing should occur), to get to your finished result. Sometimes, as with law, there are blocks and you can’t move forward, so you have to find the shade of grey and see what is possible and work around that way.’
Dennis Clarke applies programming techniques to law:
‘I drive my staff mad with my programmer’s thinking. It works well however. You have a problem? You break it down to its constituent parts until you reach the most basic issue and then you solve it. It is not something that (I believe) is learned in any other way. It is an essential skill for a programmer and once you have acquired the skill it is applicable to most situations involving a problem and it is automatic and obvious. The ability to see the different parts of a problem and reduce it down to a manageable size is just what the client wants.’
Andrew Moir is clear about the benefits:
There are quite a few reasons why I personally find it useful. I think it depends upon your practice area to some extent.
1) I’m an IP/IT lawyer, and spend a fair amount of my time on patents. A significant proportion of modern hardware is now microprocessor controlled (eg set-top boxes, printers, routers, phones, lifts, microwaves, ticketing systems, automotive engine management systems), which means each has at its heart firmware containing computer code in one form or another. Even CPUs themselves have software (microcode) built into them. When litigating patents, there is no substitute for being able to understand the technology concerned – in most cases this will involve understanding source code at one point or another.
2) I also do a lot of software copyright/misuse of confidential information claims. Again, this will ultimately boil down to whether source code has been copied/translated and so on. Being able to understand the code (particularly where translation is alleged), and ‘speak the same language’ as the expert instructed on the case is invaluable.
3) I also do a lot of IT contractual disputes. While this tends to involve less direct exposure to source code, it helps tremendously to have an understanding of the software development lifecycle and what typically can go wrong when implementing large-scale software projects. You can learn the basics of this to some extent from coding by yourself, but exposure to large-scale projects where multiple development teams are involved helps greatly in understanding how the basic principles scale up to large-scale IT implementation projects and the common problems that befall them. Personally, I’ve found my experience of working on various database/system integration projects before becoming a lawyer has helped me here.
4) I also find myself writing code in a legal context with some regularity. Over the years, this has included software to analyse large volumes of source code to look for similarities, analysing large volumes of data representing potentially infringing hard disc write patterns, countless e-disclosure, custom de-duplication and data conversion related scripts and so on.
So I do think it’s a useful skill to learn.
Clive Freedman cites reasons of his own:
I did not learn to write software at school or at university. I taught myself later when I bought a computer for no particular reason and started looking for ways to use it. I found myself fascinated by the opportunity to automate repetitive or time-consuming tasks. This led to me writing non-legal applications initially, eg a mailing list for a club (before the spreadsheet had yet been invented). Later I wrote programs directly or indirectly related to my legal practice (eg a bar-code library program for Chambers, and the software used by BAILII for converting judgments of the English courts into HTML).
At the same time as I was writing programs in my spare time I found myself being instructed in cases concerning computers and computer software: software project disputes, allegations of copying, disputes about the scope of a software licence, data protection, e-commerce, disputes about infrastructure projects. In many of these cases an understanding of the technical issues is helpful. As Andrew has said, it can be very important in plagiarism cases: for example, an understanding of how relational databases work is certainly helpful in a case concerning an allegation of copying of the structure of a relational database.
Experience of writing software is useful not only when I am instructed as a barrister, but also when I am appointed as arbitrator or mediator.
In short, I write code because I enjoy writing code. The fact that this is relevant to my practice as a barrister is a bonus. I doubt whether any lawyer would get far with writing code unless they find it interesting.
Neil Brown had a similar view and followed a similar route and considers his that his coding experience enriches his practice:
To an extent, my path was not dissimilar to Clive’s — I did not learn to code to be a better lawyer, although I think that is a positive side effect, but because I wanted to make my computer do what I wanted, rather than be a mere user. Perhaps I enjoy being in control, even if just in a small way.
I do think that an ability to code, and the understanding of a computer which comes from that, has helped me immeasurably as a geeky lawyer. Nowadays I spend more time thinking about networking and communications issues than pure code-based issues, but the knowledge base is still incredibly useful. For doing Free / open source software work, even more so. I think there’s also an issue of credibility when talking with a client if you are able to talk the same language, even in the colloquial, if not the programming, sense.
Would learning to code enrich your practice of IT law? Are you tempted to learn more? I would love to know your thoughts. Perhaps that is the next discussion.
Laurence Eastham edits the SCL web site. He would like to thank Simon Deane-Johns for the idea and for starting the ball rolling, and all those who took part in the LinkedIn discussion (which is still open), especially those are quoted extensively above, for giving so generously of their time.
