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.
I recently became aware of the great discussion around whether or not lawyers should learn to code. Some think so, and others do not. Naturally, there are a variety of smart viewpoints and I encourage you to read up.
Code can be beautiful and daunting.
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 this way).
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.
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).
All of that can be done without learning to code. There are a ton of good books out there that break it down, so if you are an innovative lawyer your time might be better spent learning how to do something like product/customer development. Or you might actually enjoy coding.
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.
All of this leads to a deeper issue: why does legal innovation come so slowly? It’s not that lawyers are opposed to innovation or that they are risk averse or addicted to the billable hour. All that’s a load of crap; lawyers are as tech phobic and as risk averse as the general population.
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!
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!