To Code or Not to Code: should lawyers learn to code?

This question gets asked a lot. We’ll teardown why this question keeps getting asked, whether this is the right question to ask, and the arguments for and against lawyers learning to code.

But first — a disclosure: the author of this article is a lawyer who can and does code, albeit not for their role at a law firm (except to prototype basic ideas).

Why does everyone keep asking this question?

At least 10 reasons:

1. Investment: according to Forbes, investments in legaltech businesses hit $1bn in 2018, up 713% on 2017.
2. Incubators: prominent legaltech incubators / accelerators have sprung up like mushrooms. Notable examples include Allen & Overy’s Fuse (2017), Mischon’s MDR LABs (2017), MDR M:Tech (2019), Slaughter & May’s Collaborate (2019), PWC’s Scale Lawtech (2019), Dentons’ NEXT Law Labs (2017) and Barclays’ Eaglelab (2018) to name a few.
3. Legaltech Training Contracts: several UK firms have launched legaltech training contracts. Leaders in this area include Clifford Chance, Ashurst, A&O and Addleshaw Goddard (for a full breakdown see this article in The Lawyer).
4. Innovation Hours: complementing (3), a small number of firms (e.g. Reed Smith and Mischon de Reya) are experimenting with “Innovation Hours”. These encourage lawyer participation in innovation projects, counting towards their billable hours target. To those who work in FS, consultancy or tech this concept has been around for decades but is something new to law firms.
5. Law Firm Coding Lessons: Clifford Chance and other firms have publicised running sessions to teach their lawyers basic coding skills, upping the ante that lawyers might need to code.
6. Law School Tech Programs: similar to (3) and (5), BPP law school has launched various legaltech initiatives, including a legaltech module as part of its LPC.
7. Events: traditional legaltech events were predominately salesy — drab conference centres lined with vendor kiosks selling to law firm IT directors. Today there are a growing number of conference, meet-ups and similar focused on more collaborative or cross-functional experiences joining together technologists, lawyers, IT directors, vendors and innovation resources.
8. Lawyer Founders: several new wave legaltech start-ups are founded by former lawyers. Examples include Kira Systems (Weil Gotshal & Manges), Avvoka (Slaughter & May and Linklaters), Legatics (Clifford Chance), Workshare Transact (Clifford Chance and Fieldfisher) and Office & Dragons (Kirkland & Ellis). Several of the founders are lawyers who can code. In some cases, such founders coded their early products and / or commit code to on-going product development.
9. Law Society: the Law Society for England & Wales has become an increasingly active voice in the legaltech scene, publishing detailed content regarding legaltech, innovation and adoption barriers. See this great report on the state of UK legaltech in 2019.
10. Robot Lawyer Articles: the nonsense articles about robot lawyers — replete with Terminator-style gavel-wielding robot images — seem never-ending. These articles stoke unfounded fears that junior lawyers are out of a job unless they learn to code. This couldn’t be further from the truth.

But first, why do you want to learn coding?

coding fomo is not a reason

If you are a lawyer considering whether to learn coding, ask yourself a different question: why?

What’s your “why” for learning to code? Chances are you might not have thought this through, and even if you have, you might not have done so in much detail.

In particular consider:

• What are you trying to achieve by learning to code?
• How (if at all) will learning to code benefit you?
• Will learning to code benefit your practice and your legal career?
• Are you looking to change jobs and move out of law?
• Are you looking to demonstrate tech credentials for a job at a legaltech provider?
• Do you wish to start / join a start-up? If so, do you want to code your minimum viable product or talk intelligibly to developers to ensure you don’t get ripped off or have stuff lost in translation?
• Do you simply want a new hobby?
• Do you simply want to sound clever?
• Are you learning to code because everyone else is doing / suggesting it? (i.e. FOMO)
• Do you have time to learn to code?

There’s obviously no objectively right or wrong answer, only the right or wrong answer for you. But whatever you do, ask yourself these types of questions before all else.

Common Coding Myths

Don’t let these stop you

Myth 1: you need a degree

For some time this was true. Traditionally tech companies required a 3–4 year Computer Science degree. Today they increasingly don’t mind so long as you demonstrate and can pass their technical testing.

Further, unlike legal education, the internet has democratised coding education. This has been achieved via vendor documentation / online communities, the open source movement and the rise and rise of Massive Open Online Courses (“MOOCs”) such as Udacity,Coursera, Udemy, EdX, FutureLearn and similar (i.e. highly scalable distance learning platforms).

The end result is you can learn everything you need to learn regarding coding:

• for free / relatively cheaply
• from the comfort of your own home / device
• on-demand
• at your own place

Alternatively, if you can afford the time and cost, intensive “coding bootcamps” exists such as Makers Academy and FlatIron School in London. The author of this article completed a full-time 16-week intensive coding bootcamp at the former in 2016. Online free alternatives also exist, best of all being www.freecodecamp.com.

Myth 2: you need to be a maths whizz

If you want to code, or go further and be a good developer, math fluency isn’t a necessity. You will, however, need to have strong problem-solving skills and the ability to think logically… sound familiar to lawyers? It should sound familiar given these are core competencies for good lawyering.

Of course, for some coding disciplines the more maths you know the better and easier it becomes. For example, machine learning. In machine learning, the core principles are rooted in higher level statistics, probability and optimising mathematical techniques. Understanding these in detail will make you a better machine learning engineer.

Some of the maths (the cost function) behind logistic regression — a machine learning technique for classification problems

Myth 3: you need to be a genius

To outsiders, coders seem like geniuses. Explaining that you can code and write software often elicits this response: “you must be some sort of computer genius!?” or “I could never do that”. Neither is particularly fair.

That’s no exaggeration; it’s the ingrained stereotype that coders = genius geeks.

True, genius geeks exist in coding, just as genius geeks exist in every profession — and especially at the top. But like other professions, these are the exceptions, not the rule.

So with those myths out the way. Are lawyers suited to coding?

Why lawyers might be suited to coding

law is not code, but certainly has some transferable qualities

Problem Solving

Lawyers are primarily problem solvers. Their education and practice of law is all about:

• identifying issues;
• researching solutions, using internal or external knowledge;
• analysing their findings against the issues; and
• designing and applying potential solutions to solve the problem for the client.

Whether this is drafting a contract (a product), negotiating a deal or litigating a dispute (services) it’s all about problem solving and logic.

Added to this, lawyers are great at spotting dependencies and planning for them — this is a great asset to coding. This becomes especially beneficial when it comes to testing and quality control regarding code. Being able to foresee problems before they arise, plan for them and build solutions is prized within coding; it ensures robust and secure software.

There are even best practices in coding and software development that cater to these needs, e.g. test driven development, which requires an aptitude for proactive dependency spotting.

© r-style lab

General Intelligence

Lawyers are generally very bright. Law is a tough degree and a tougher profession. It rewards intellectualism, continual learning, and adaptability. These are all traits necessary for learning to code.

Disciplined

Lawyers work gruelling hours and manage huge workloads to tight timelines. As a result they are necessarily disciplined and excellent at organisation. These skills can help lawyers create and maintain a study plan to work through and level up their coding skills should they choose to learn them.

Research driven

A lot of coding is about knowing what to ask, how to ask it and where to find the answer.

The most popular Q&A research resource for tech is StackOverflow. This is a social platform that allows users to submit questions and answers, whereby the best answers get up-voted and the worst down-voted:

Likewise, Google is always an essential starting point for any coding question.

Lawyers are already good at using similar research tools (including Google and Practical Law’s Q&A function) to dig in and around documentation and information to find answers. Coding is no different with regard to this need.

Attention to Detail

Probably the most important skill for lawyers. For instance, omitting a “not” or a punctuation mark at best creates ambiguity that hinders future interpretation and certainty, or at worst completely alters the meaning of a contract provision from what was intended. In either case, getting it wrong can cost clients serious money and lead to a claim against the instructing law firm.

In coding, attention to detail is similarly critical but often undervalued. For instance, failing to close a set of parentheses used in a coding language’s syntax will break the code, preventing it from running or causing it to crash mid-flow. Being alert to this and similar errors in syntax can massively assist debugging efforts, although it’s also true many code editors have tools built in that check, and in some cases correct, these coding typos.

Overlaps between coding and drafting

Good drafting and good coding share many similar structures and concepts.

With regard to structures, an example is the commonality between defined terms in contracts and variables in code:

• Defined terms in contracts are essentially identical in purpose to variables in code: they each create a labelled container to store a meaning or value, which can be cross-referenced to reduce duplication. For more on this, see our detailed explainer of this law and coding crossover.

Concerning concepts:

• It’s common to good drafting and good coding not to repeat yourself. In other words, whether contract or code, don’t repeat the same syntax or mechanism throughout the document or application. In coding, this is often referred to as “keeping your code DRY” where DRY stands for “don’t repeat yourself”.

Lawyers might be more suitable than they think

In summary it’s fair to say there:

• are not any dealbreakers blocking lawyers from learning to code; and
• are a number of aspects common to lawyers that might make them amenable to code.

So let’s dive into the arguments for and against this effort. Whilst reading the below, bear in mind the strengths and weaknesses of these arguments largely depend on an individual’s rationale for learning to code, i.e. their why? Again, this is why that question is so important.

Arguments For

Why lawyers should learn to code

Suitability

As we described above, many lawyer skills and traits lend themselves to learning to code. In particular, attention to detail, problem-solving, research abilities and a career focused on syntax and structure create a good foundation.

Differentiation

Whether it is a job interview, when you talk to clients (who increasingly demand tech literacy) or career progression, having some technical education can be a differentiator vs. legal colleagues and counterparts who are less technical.

Equally, there may be other areas of legal practice that provide better returns on investment, e.g. being better than the next person in your area of law or having a greater understanding of, and better relationships within, the client’s business.

Even without coding expertise, lawyers who pseudocode — via macros or data manipulation in Excel — are increasingly able to set themselves apart by creating or spearheading innovation projects, working closely with technologists. Even simple things such as custom MS Word macro to split out signature pages and pdf them can save an individual or a team countless hours when counted over the course of the year.

As general tech literacy is patchy in law, knowing a little goes a long way.

Dr. Dolittles

At lawtomated our authors, and many in their network, provide value joining the dots between technical and non-technical folk inside and outside of their legal or vendor organisation.

They do so by:

• talking law to lawyers;
• talking tech to techies; and
• translating between the two tribes to identify and solve shared needs.

Coding isn’t essential to develop this skillset vs. a general understanding of technology, but it certainly helps.

That said, there is a counterpoint here. This need reflects that coders are not used in legal teams the same way they are in most businesses.

In banking, techies are often integral parts of both the machine and its management. At law firms, techies don’t get equity nor often work on the frontline to solve client problems. Instead, there is often an archaic and unhelpful distinction between “fee earners” (lawyers) and “non-fee earners” (everyone else). To different degrees, this is another blocker to innovation and effective use of technology to drive business value vs. keep the lights on.

However, perhaps lawyer-coders can help change this attitude. By being lawyers first and foremost, and as they become more senior and influential in re-shaping the future legal team structure (assuming lawyers continue to hold sway for the short term), perhaps they can redesign the firm structure by reducing distinctions between lawyers and non-lawyers, promoting each in equal value for commensurate contribution and thereby creating business value.

In doing so they might remove the need for lawyer coders!

Due Diligence

Knowing how to code and in general how key technologies work (e.g. OCR, cloud, cybersecurity etc) can help diligence potential solutions, whether presented internally or by external vendors.

Tech is full of jargon, and worse, has a troubling history of overhyping and under-delivering in the short term (e.g. A.I. and blockchain most recently).

Knowing a little goes a long way in this context as well. These skills give you an edge and can allow you to probe what you’re told but also pre-empt which solutions might exist and be most appropriate rather than starting from a blank slate. This will be helpful whether you are buying tech in a legal team context or starting your own tech based start-up.

Problem Solving

Coding involves problem solving, in particular a technique known as divide and conquer.

This simply means breaking down a problem into increasingly smaller parts and working through each of them to find solutions. This is often hyper-logical because this is the way machines think: essentially, if this then that else something different is how computers process information (i.e. conditional logic).

In doing so this often requires mapping systems and processes. This is a key skill yet under-appreciated or missing altogether in lawyers despite their work being heavily procedural, whether they are a litigator or transactional lawyer.

Being able to think like this, and facilitate discussions of this order, can help identify and reorganise processes to make them lean and efficient, with or without technology depending on your needs.

More generally, coding is a complementary set of problem-solving skills that enhance a lawyer’s existing expertise in this area.

Arguments Against

Why lawyers should not learn to code

Coding is like any language: it needs time, consistency and native speakers

Like learning any language you need to invest significant and consistent amounts of time to learn it effectively. Dipping in and out of coding will only lead to disappointment. Doing an hour here or an hour there every week or so will probably be quite demoralising.

This is because your first coding experiences will be much like learning a language. You’ll be able to recite disparate phrases but can’t build and adapt a conversation without several weeks of consistent practice and study. In the same way, early coding experiences will be about playing with esoteric bits of syntax, doing very basic stuff (e.g. making your computer terminal print the words “Hello World”) and not having much to shout about for your efforts in the sense of an app to show off to your friends.

Further, like natural languages, although non-essential (though some would argue the contrary) it certainly helps to be around native speakers. Lawyers are unlikely to be around native speakers when it comes to coding. That said, this is possible via online communities, and indeed the coding community is built around them as is the entire open source software movement.

Against this are the two things lawyers lack:

• availability; and
• consistency of time.

Practising lawyers frequently work long and unpredictable hours, preventing consistency and eliminating the availability of practice. If you don’t have or can’t commit consistent time to learn and practice applying code then you’ll be setting yourself up for a lot of unnecessary stress, particularly if you don’t have an answer to why you are learning to code. This is no different to learning a natural language around your law job: if you failed, or would fail, at that then learning to code will likewise be a non-starter for identical reasons.

Production ready code is hard

Software used in legal contexts (or any real-world context) must be clean (i.e. easy to read), maintainable, reusable, scalable, bug-free and secure.

If this were easy, why do so many software products produced by companies small and large get hacked and require constant updates and patching?

The answer is that it’s bloody hard and often requires an army of experienced technologists, product designers and testers to ship new software, let alone maintain and update it.

A few lawyers learning to code in a law firm isn’t going to deliver much value in this regard. How much production ready software could such people churn out alongside their day jobs as practising lawyers? None, unless the firm structure and goal alignment incentives change accordingly, e.g. allowing such lawyers credit for time traditionally regarded as “non-billable” and making space for that time to happen.

With this, it comes back to why you (an individual or your legal organisation) are learning to code. If you’re learning to talk tech and translate between techies, internal or external, then this argument against isn’t an issue. If you’re expecting to build production-ready apps straight out the gate then you need to reset your expectations.

Legal problems still require legal solutions

Legal solutions depend on lawyers. Clients don’t / won’t come to lawyers asking them to be expert in other domains. Sure, lawyers need to understand the context of a client and their legal challenge against prevailing trends, but it doesn’t mean they have to be expert in that client’s domain.

Similarly, just as lawyers in an M&A need to identify and match specialists to specific issues (e.g. IP lawyers to IP issues, employment lawyers to employment issues and so on) good lawyers should similarly marry up appropriate technologists to the tech problems rather than try and be a jack of all techs on the side.

Again, this comes back to reconsidering and perhaps revising the traditional firm structure. A more appropriate solution might be to break down distinctions between the front office and back office where there’s cross-functional value to be tapped to the benefit of clients.

If not coding, what else can lawyers usefully learn re tech?

Components

Understanding headline technology concepts is probably most useful to lawyers. For instance:

• Cloud computing, e.g. key differences such as single vs. multi-tenanted.
• How the internet and networking works.
• Differences between structured and unstructured data — see here for our explainer in this regard.
• How software is built, i.e. who builds it? How is it tested? How is it project managed?
• The purpose of common hardware components, e.g. serves, modems, routers etc.
• Key protocols, e.g. HTTP, HTTPS.
• Key architectural styles, e.g. REST.
• Difference between open source and closed source software — see here for our take on this, and even its applicability to contracts.
• Key principles of trending tech. For instance with regard to A.I. look to understand the fundamentals, including differences between the major and minor types, possible use cases, the hallmarks and dangers of AI hype, questions to ask of vendors and why .

These are illustrative not exhaustive but why learn them?

Understanding these components, their purpose and impact on law and legaltech help lawyers have productive tech conversations with internal and external technologists.

For instance, understanding these concepts can illuminate concerns and solutions regarding data sharing or security with regard to software procurement. Likewise it can help lawyers understand why certain policies and procedures exist, e.g. cloud policies. Together this helps reduce friction and blockers to tech adoption and solution identification.

Concepts

Core coding concepts and common architectures can be worth a learn. However, you don’t need to learn lots of code, or any code — the concepts will suffice for most interested parties.

Of the former, most useful is probably an understanding of control flow. Control flow is the order in which individual statements, instructions or function calls are executed or evaluated via software to achieve outcomes.

This involves understanding conditional logic such as if / else / then statements and loops. For example:

Lawyers already think like this, they just don’t realise it. A good example is a payment waterfall clause in a credit agreement. These use prose equivalents of conditional logic to determine in what circumstances which parties get paid out what and when.

Understanding how these concepts map to the way machines process information expedites lawyer ability to adopt and create value using workflow automation tools (Neota Logic, Bryter and VisiRule), which are increasingly commonplace. Going further, understanding these concepts will help lawyers map legal mark-up languages and smart contract technologies to their analogue equivalents.

With regard to common architectures, an example might three-tier web architecture popular with most web and mobile apps:

Understanding something like the above helps contextualise how information moves to and from the user through software and hardware and in turn, why and where concerns such as cybersecurity and data sharing become apparent. That understanding might, in turn, reduce friction in conversations between lawyers and technologists and / or demonstrate a clearer understanding of legal issues concerning these items where they impact clients.

Competencies

Legaltech is frequently criticised for having a poor user experience. It’s not uncommon to hear people bemoaning that a piece of legal software seems to have been designed in an engineering vacuum, based on assumptions about how lawyers work and why they do certain things and not others. Worse still, a lot of legaltech looks like it’s from somewhere in the 1980s — 2000s. This is improving, but could be a lot better!

This is an area where lawyers can probably come to the rescue. But there’s a but.

Although lawyers understand very well their own needs, they might be no better at translating them to usable, scalable software. Similarly, they might not be that effective at facilitating discussions with wider user groups to canvas user experience feedback and product feature requests.

Learning about design thinking and UX (user experience) can help develop and ingrain these skill, providing methodologies to standardise capture and creation of useful information and ideas regarding user needs, wants and interfaces. In turn, those can be translated into user stories and designs for products and services.

Having an ability to facilitate such exercises can help uncover real vs. fancied innovation opportunities within a legal organisation.

Related to this, familiarity with established project management tools or techniques can also improve lawyers’ existing skills in these areas, which are often ineffective. For instance, multi-billion dollar legal transactions are often managed via unwieldy MS Word tables vs. using appropriate project / transaction management software which, if used, might provide huge savings to the client and deliver better value.

Concerns

Schooling up on cybersecurity, data sharing, encryption and so on is worthwhile. As with much of the above, it can help contextualise the rationale for policies and procedures — e.g. those surrounding cloud and data sharing — that might otherwise seem unnecessary and overly cumbersome blockers to using tech in a legal organisation.

Equally, it can also nip issues in the bud. For instance, when buying software it’s better to understand whether it is cloud or on premises as early as possible so that an organisation’s cybersecurity team can vet the product / company, and solve issues as early as possible, therefore increasing the speed at which software can be on-streamed into the organisation.

Understanding such concerns and who needs to weigh in can make your innovation ideas easier to get off the ground.

Conclusion

The “should lawyers should learn to code?” debate seems driven by increasing interest, investment and individuals in legaltech. It’s also partly hype driven, feeding off the general legaltech hype.

Undoubtedly lawyers possess many skills and practices making them amenable to coding skills. There’s similarly no deal-breakers blocking their coding education.

There’s good arguments for and against lawyers learning to code. Having a coding skillset is very useful in general (in the same way learning a foreign language might be) and can be a differentiator vs. peers. The strengths and weaknesses of these arguments ultimately depend on the individual or organisation, i.e. why specifically learn to code?

However, there is a misconception that lawyers learning to code will transform law or unlock lots of great software solutions to solve legal and organisational challenges.

It won’t: lawyers still need to practice law, which is a full-time job. Nor will they suddenly be able to churn out production-ready code.

All of this fails to ask why? What’s the problem being solved by lawyers learning to code? Is that an actual need? Is the real problem bigger? Is it actually about greater collaboration, ideation and understanding of processes between teams within legal organisations and tackling those challenges together against appropriately aligned incentives and progression structures that reflect today’s need for cross-functionality in business? Probably!

But back to coding… if lawyers must learn something code related, rather than learning to code it’s better for lawyers to understand core technology concepts, components, concerns and complementary concepts. Yes, coding will teach you some of these, but not all (especially design thinking, UX, project management).

Whether a lawyer learns to code or adopts the approach described in the preceding paragraph, doing so reduces friction between lawyers and technologists, whether internal or external, enabling better conversations and greater collaboration. It might also sew seeds of macro change to the law firm structure. Time will tell.

Originally published at lawtomated.