Legal Geek is compiling a ‘hack-book’ of lawyers and legaltechies who code. If you code, or are learning to code, we would love to include you in our ‘hack-book’. Drop us a line via [email protected] [yes it is .co].
The Hon. Mr Justice Birss has the job title of Judge of the Patents Court and Supervising Judge for the Business and Property Courts of the Midlands, Wales and Western Circuits. Enough said.
How many years have you been able to code?
“I have been able to code since I was a young teenager. I wrote my first programs in BASIC in the late 1970s. At the same time I was playing around with logic circuits. I built two computers – a Sinclair ZX80 (pictured, below) from a kit, and later a more sophisticated 6809 based system. I did some coding while working as a student in the nuclear industry, then at university when studying for a degree in Natural Sciences, and then professionally at what is now Accenture.
“Since becoming a lawyer I have written code for fun. While at the Bar I created what was in effect the bare bones of a Word Macro virus as an experiment. It did not do anything bad, the experiment was to see if I could make a self replicating package of code which would jump from computer to computer and take control without being detected. It was not released into the wild but it was soberingly easy to make such a thing and it was not detected by what was then my commercial anti-virus software.”
The Sinclair ZX80 was launched in 1980 and cost under £100 at the time. The kit version was £20 cheaper but required soldering together hardware at home.
What languages can you code in?
“Over the years I have coded in a few languages: BASIC (including its modern incarnations), Z80 and 6809 assembler, FORTRAN, FOCAL, COBOL and PL/1. More recently I have played around in HTML, Python and a bit of JAVA. More obscure coding has been in IBM mainframe Job Control Language, DEC PDP8 machine code and a DEC Vax/VMS scripting language I can’t remember the name of (DCL?).”
What kick-started your interest in coding?
“I am a geek.”
What obstacles did you encounter when learning to code?
“When I started it was hard to find materials to help but the best way to learn was by doing it, seeing what works, making mistakes and learning from them. The training I received in the 1980s was effective. Having mentors who can help you made a big difference, but coding is pretty solitary work.”
From your experience, do you think lawyers gain an advantage by being able to code?
“Being able to code can give lawyers an advantage for two reasons. The first reason may be less significant today than it was a few years ago but being a coder allows you to really understand what technology is capable of and what the people involved in technology can do with it.
“The other reason is that there are aspects of good coding which apply to legal practice too. The training I received at Arthur’s identified three things – (i) how to produce good code, (ii) the utility of good project management and (iii) the value of proper systems analysis. Taking them in reverse order:
“You can do all the coding you like but if you are working to a flawed functional specification you are storing up trouble. The best software is produced when the coders and the users (or potential users) work together to identify what the problem they are trying to solve actually is. The same is true in the law.
“As for project management, the software industry has used those techniques for years. In the legal world, bringing a case from conception to trial is a project just like the ones in the IT world. The skills of good project management apply to litigation too but many lawyers do not see it that way.
“It terms of producing good code, I learned the value of code structure, good documentation, change control and designing appropriate tests. All of that translates into legal practice.
“Structuring legal arguments is vital. Good documentation is also surprisingly useful. Many times in litigation the team has forgotten why they did something a year before and such decisions are often not well documented. Change control is similar. A party whose case keeps changing can leave a unconvincing impression on the court. As for testing, a good coder knows that everything has to be questioned and tested. The same applies in litigation.
“As a specific example, I spent a year in the City as the maintenance man for a fiendishly clever FORTRAN based package which many financial institutions used to set the level of payments under finance leases. Some very high value contracts defined the amount of the payment due as being the result produced by this package. That was in the 1980s and just goes to show that the idea of contracts defined by software is not new.
“As the maintenance man you would turn up at short notice when a problem had occurred and try to fix it. That involved delving into some quite unstructured code and often involved working out what someone else had done before you. The lack of structure and poor documentation made it particularly challenging. The main thing you learn is that clients simply want a solution to their problem and they want it now and at minimal cost. They are not interested in the details of how elegant your solution may be. The same is true in the law.”
