Counterpoint: No, Lawyers Should Not Learn to Code

computer-security-guide-cover-2nd-ed

4-Step Computer Security Upgrade

Learn to encrypt your files, secure your computer when using public Wi-Fi, enable two-factor authentication, and use good passwords.

Guest post by Edward Hartman, Co-Founder and Chief Product Officer of LegalZoom, in response to David Colarusso’s Learning to Code series.

I am what is euphemistically called a “life-long learner.” There is nothing on Udemy, EdX or Coursera so obscure that I will not enroll. I have called the Learning Annex at our local community college so often that the operator knows the sound of my voice. So it may seem strange that I am so opposed to the idea of lawyers learning to code, especially as I am a Lawyer Who Codes, having been the Chief Technical Officer of more than one company, including LegalZoom, and now a member of the California Bar.

The debate around this issue is heating up. David Colarusso has recently taken the “pro” position in these pages, with V. David Zvenyach joining him in the ABA Journal, and countless others on Twitter. No less a mind than Tanina Rostain teaches a “coding for lawyers” class at Georgetown, and it is always oversubscribed. Clearly, interest is strong.

It is not that law is not starved for better technology. It has been well documented that law is in crisis and technology could help. The ABA’s own legal futures report talked about the profession’s “delayed adoption of, if not outright resistance to, innovations in technology, systems process improvement, and other developments that could benefit consumers of legal service.”

How do you solve such a crisis? The “lawyers should code” camp would respond with an army of enthusiastic JDs, modestly trained in programming, self-educated whenever they can find time—on weekends, over coffee breaks, while watching Mr. Robot, and so on. I see the appeal. Lawyers are smart people, and many are underemployed, but the problem deserves a better answer.

To consider the question properly, we must be clear about the terms. First, who do we mean by “lawyers”? I define this as “licensed, practicing attorneys.” (Law students, if they are interested, should absolutely learn to code—it may convince them not to become lawyers.)

Next, what do we mean by “learn to code”? This is worth thinking about. As Colarusso notes in his piece, there are at least three different positions. Each raises its own issues.

Group 1: “Lawyers Should Become Coders”

First, let’s consider what I’ll call the “all in” position. These advocates believe that lawyers should become professional-grade coders, full stop. They should be able to author and release code for the use of others. Perhaps they might sell an app through the App Store.

To understand the logical objections to the “all in” position, try reversing the phrase. Instead of “lawyers should become coders” try “coders should become lawyers.” No sane programmer would want to undertake this challenge—three years out of one’s life, tens of thousands of debt—unless they were contemplating a career change.

Is this what the “pro” camp is looking for? Do they want lawyers to stop practicing law, defect en masse from the bar, and start new lives as coders? Clearly not. They want lawyers who stay lawyers but who can also release production-ready code.

So how hard is it, really, to release production-ready code? To get some perspective, consider the number of security breaches that happen to big companies: Sony, Target, Yahoo, and the hundreds that go unreported. Those violated systems were not written by newbies. These were massive code structures carefully constructed and maintained by teams of experienced technologists, working with professional automated testing suites, in environments designed for the proper inspection and deployment of bullet-proof code.

Yet they got hacked.

Code breaks. It fails to cross devices. It won’t play well with other code, won’t interop with other systems and technologies. It ages poorly, requiring heroic efforts just to keep current. Tech debt is a real thing with which nearly every coding organization struggles. And that’s when the code in question is built by people who have made technology their lives.

There are exceptions. There is William Palin, there is David Colarusso himself, and there are a handful of others who really can do it all. But those people are just that—exceptions. How do you solve a crisis? The answer is not with a handful of exceptional people, but with an army. It takes time, and it takes a team, and even then things fail.

Group 2: Coding Is A Neat Tool To Have

What about the “tool belt” argument, which goes something like this: Coding is becoming as basic a skill as typing. Every child in school is taught to code. Knowing how to code gives you an edge.

Let’s follow this logic. If skill in coding is a tool, then it follows you intend to employ it to produce something useful. Maybe you think you might use it to help you code up a widget on your website where prospective clients can leave confidential information. Or perhaps you plan to create code that will help you in discovery, or in constructing documents.

How does this fit with the duty we owe our clients—namely the duty of competence? It’s hard to maintain that integrating what is essentially your hobby into your professional legal work product is a competent or even responsible thing to do.

In all the “Let’s Learn To Code” articles, there is little about unit testing, or automated inspection, or documentation, or architectural patterns. But that’s a lot of what real coders do to make sure their work is reliable. As Alexander Hamilton (of Radiant Law, not the one from the musical) notes: Coding is to application development as drafting is to legal practice—just one part of the picture. And again, even with these safeguards in place, things fail.

Group 3: Knowing How to Code Helps Me Talk to Coders

The third group of advocates want to learn coding the way you might learn a foreign language. It will help them speak to the natives. They will be a regular Doctor Doolittles, talking to the animals. This may seem to like a perfectly reasonable thing to do, but consider what it implies.

This position recognizes that coders and lawyers have a communication problem, or more correctly, an integration problem. Coders are not used in law firms the way they are in most businesses. They are seen as tools to get things done, not as an integral and necessary part of law firm operations, let alone management.

Unless they are also lawyers, they cannot receive equity in the law firm. Is equity important? Our profession certainly seems to think so, otherwise the partnership track would not be the primary way we attract, retain, and motivate our best talent. We do not extend such an opportunity to coders, which implies that we are not as interested in attracting strong tech talent, retaining them in solid career paths, or motivating them to do their best work.

Since we have deprived them of equity, technologists are not a voting part of a law firm’s management. We should correct this problem by giving technologists the influence they would need to make a difference. Instead, we decide we are going to be the technologists ourselves, or at least manage them.

The ABA Commission on the Future of Legal Services said that “[a]llmembers of the legal profession should keep abreast of relevant technologies.” Consider, for a moment, how sweeping that statement is. There are hundreds of coding languages, thousands of technologies that may be relevant, from blockchain to crypto to whatever wizardry makes a surveillance drone work.

Instead of this stance, we might consider what serious people in other industries do, such as the management of Fortune 500 corporations. These extremely smart and accomplished people do not spend their valuable time keeping themselves abreast of all relevant technologies. They do not learn to code.

But they do benefit greatly from technology. They do this by employing great technologists—teams of them. They listen to their advice and include them in the top rank of management. Anything less would fall below the standard required of them by their shareholders, or, put another way, anything less would be negligent.

Summary

There is a difference between solution and distraction. At best, lawyers learning to code will slow adoption of a more effective approach. At worst, encouraging amateurs to tackle issues involving client confidentiality and more invites failure and mistrust. There is a way to cure this crisis, and technology will play a part. But we must take a deliberate approach to technology, following the best examples from other professions and industries, rather than fooling ourselves that we can close this divide with information gleaned from “21 Days To Mastering JavaScript.”

Subscribe

Get Lawyerist in Your Inbox, Daily

Current Articles
Current Lab Discussions
  • Enginerd

    “As Colarusso notes in his piece, there are at least three different positions.”

    I’d say this is a straw man, except there’s an actual man. But these positions somehow miss the obvious one. I’ll call it Group 4: learn it for the same reason you had to take a foreign language in college, even though they know you’ll never speak Italian in your career. You learn it to see a new way of looking at the world.

    I’ve seen far, far too many people (including lawyers) who think that “technology” is just magic, straight out of the Harry Potter world. In fact, data is just a sequence of bits, and programs are just instructions for how a CPU can manipulate these bits really quickly. Learning to program, even a little, drives this home in a way that just reading about it does not. You don’t have to be a cryptographer to understand the absurdity of positions like: “Let’s make encryption that only the good guys can break”.

    “These were massive code structures carefully constructed and maintained by teams of experienced technologists, working with professional automated testing suites, in environments designed for the proper inspection and deployment of bullet-proof code.”

    I think you drastically overestimate these companies — and most companies. Yahoo, Sony, and Target are not where I’d look for any of these things you list. (NASA or Google, maybe. And I don’t recall ever hearing about them being broken into.) Perhaps even more valuable than learning to write a program is seeing what software engineers do in a typical day.

    If I had a dollar for every time I had a manager tell me “No, we’re not going to worry about that bug, because we have to ship this feature today”…