Every time I teach Computer Programming for Lawyers, I start with the same first line, “This is an argument in the form of a course.”
The argument, I explain, is that every single lawyer–regardless of area of substantive speciality or style of practice–could become a more efficient lawyer if they learned some rudimentary computer programming skills.
The argument builds on the observation that every lawyer processes information as a part of their job. This information often comes in the form of text–cases, statutes, contracts, regulations, and memoranda–but increasingly lawyers also process other forms of data–accounting information, scientific data, government reports, etc. Yet lawyers use an impoverished set of tools for obtaining, cleaning, and organizing all of this information: primarily word processors and search engines (westlaw, lexis, and google). Sophisticated lawyers–including those at high-paying law firms–might supplement these tools and skills with spreadsheets and document management systems. But few lawyers use anything more powerful or sophisticated than these.
Basic programming skills allow any lawyer to become more efficient at processing information. These skills allow them to:
Automate the Boring Stuff*: Every lawyer is asked at some point to do something mind numbingly dull. Crawl through this box of documents for due diligence or discovery. Read every one of these two hundred cases. Read every page of this two thousand page record. To be clear, our students do not learn to do any of these tasks in whole with code. But they will learn how to automate some of the most boring pieces, freeing them up to tackle higher-order, more interesting parts of the work.
Work at Scale: Sometimes, with a little programming know-how, you can scale up the amount of work you can accomplish. The partner asked you to look at every admiralty case decided in the first decade of the U.S. Supreme Court for citations to foreign law? Why not build a bespoke set of regular expressions that can search every citation to foreign law in every case the Supreme Court decided in the first forty years of the Court instead?†
Have More Fun at Work!: I like to quip to students considering the class, “A boring, manual task that would take you five hours to do without code will take you ten hours to do with code!” I mean two things by this: first, when you’re not an experienced programmer, programming can sometimes slow you down, not speed you up. But for many people, programming is much more entertaining than doing things the long way, as each program is like a little puzzle box, which can be quite enjoyable to try to open. Oh, and the next time you’re asked to do that boring, manual task, you can adapt your old code to do it in much less time.
This course is not designed to teach lawyers how to build apps, conduct scientific experiments, or develop machine learning models. I hope some of my students become inspired to continue their education to learn how to do some of that, someday. Graduates of this course will be able to build small, single-purpose tools that do little more than automate a small part of a much larger task. This is, at once, the modest goal and the grand challenge of what we’re trying to accomplish.
In other words, I am trying to systemize and spread the way I used to practice law, building little scripts that made me a tiny bit more efficient. And not just me, but every practicing lawyer who already knows a little bit of code builds tools like these in their professional and personal lives. It seems as second-nature to us as using a word processor or search engine seems to other lawyers. I hope to bring these instincts and toolkits to a much larger number of lawyers.
* The name of the book we used the first time we taught the course. For more detail, click here.
† This example is inspired loosely by Chapter 4 of Dan Katz’s Ph.D dissertation.