I started coding at age eight, sitting in a Chicago basement with a Texas Instruments TI-99/4A. I would spend all days programming little games in BASIC. In high school, I made graphics for the then-burgeoning CD-ROM industry (Internet had not yet blown up). Instead of college, I opted to write web software for startups and public companies in the late 1990s. I did that for nearly fifteen years. Now I am a lawyer.
Code can be beautiful and daunting.
Should A Lawyer Learn To Code?
I already know how to code, and I am glad that I do. It actually helps with the transactional/structuring work that I do for my legal clients — the simplicity and elegance demanded by code translates well to document drafting.
But it may or may not make sense for every lawyer
to learn how to code. I have no idea what any given lawyer should do, but I can add some dimension to the discussion so that lawyers
can make their own decision on how to proceed.
Coding is not easy. Sure, the basics are pretty easy, but to get to a point where you are marketable takes a ton of dedication. As with anything, my advice would be to learn how to code only if you love it and you can see yourself dedicating hours to the craft. Don’t do it out of obligation.
If you are a lawyer interested in expanding your technical chops, your time might be better served by starting small and understanding the conceptual foundations of software design (Rule 1: “Laziness is a virtue”).
To do that, spend time with a tool like Zapier
to develop an understanding of how different systems can communicate with one another via an API. You can also delve into database tools like Knack
. Honestly, with those two you can make a ton of new and useful things — without having to actually code (I actually built the first version of my firm’s legal subscription program
Once you start to hit limitations with those tools, then figure out what you need to learn in order to improve your product. And that might mean learning to code. By then you will be comfortable enough with the broader concepts so that coding won’t be so intimidating and you can focus on learning the bits that you need to learn to solve the current problem at hand.
Instead, Learn How To Create A Product
Did you know that when developing a new technology
product, coding is only a part of the equation? The real game is to build a product and then find the right customers for that product. And that goes far beyond coding.
It means getting potential customers in front of your product and then getting feedback to test your ideas. Then it means rapidly modifying and iterating your product to serve your customers needs. Then repeating, while probing for weakness in your offering (that’s what “fail faster” means).
Also, understanding technology basics helps when you want to communicate your ideas to programmers or other engineering people. It allows you to have more accurate and higher-bandwidth conversations and see opportunities.
The Real Barrier To Legal Innovation
The real reason that legal innovation seems slow is because non-lawyers cannot own a stake in a law firm. That means that if you find a rad coder that you want to bring on board, you can’t compensate him or her with a stake in the company. It also means that if you have an investor excited about funding your idea, they can’t do it.
Obviously, this creates huge inefficiencies for law firms who want to innovate and leaves legal innovators with the option of making tools that support current business models or having lawyers learn to code.
Did you find this article interesting/helpful? If you did, can you help others find it by clicking on and holding the “Clap” button (below). Thank you!