What I Learned About Innovation From Learning How to Code

I recently completed Harvard’s CS50: Introduction to Computer Science, offered online though edX. Given my role as a Legal Tech and Innovation Specialist, I work with a lot of technology. Gaining a deeper understanding of computer science seemed like an enjoyable side-project. I was partially correct.

(Sample code from one of my projects)

While learning about concepts like data structures, memory, and arrays is incredibly helpful, I was not prepared for how challenging it would be to apply these concepts into workable programs. Things that programmers can do without effort took me hours: iterating across a linked list of nodes, querying a SQL database from within a Python program, generating HTML dynamically.

Yet beyond the content itself, the course helped me notice broader lessons that apply to my work as a legal innovator. A software program, after all, is an attempt to create a better way to do something. Programmers regularly tackle difficult problems that do not have clear answers. With this in mind, it makes sense that I could learn a few things about innovation from how they approach their work.

Collaboration is encouraged

I was surprised by how often the instructors encouraged the students to look for answers outside of the course material. At first, I was concerned that viewing others’ code and searching for answers on forums might be cheating. Thankfully, a developer friend helped me realize that this sort of collaboration is fundamental to becoming a good programmer.

It is not uncommon to start a new program or function by copying and pasting pre-existing code – my own or someone else’s. Being able to leverage other code for one’s starting point is a skill in itself. It requires understanding my project and current code well enough to zero in on the issue (e.g. searching a full solution like “DNA analysis algorithm” would not be that useful). I had to precisely articulate my problem if I had any hope of finding an answer online (e.g. “python csv.DictReader”). And once I found a useful snippet, I then needed to understand that code and how it fit into the broader context of my situation. Copying and pasting someone else’s code is not necessarily cheating, it is efficient.

Once I got used to it, the process of finding precedent code that I would apply to my current issue began to feel strangely familiar to how legal research often leverages the firm’s institutional knowledge. As anyone familiar with Knowledge Management knows: you only need to invent the wheel once. And like legal work, starting with a precedent does not lessen the value of the work required to apply that information to solving one’s specific problem.

As a legal innovator, I am often faced with situations that are new to me but probably not new to others. Instead of searching for a legal precedent, though, I can speak to those in related roles – account executives, IT professionals, or entrepreneurs – to see if their experiences could apply to my context. If others have already solved problems, I want to reuse that information as much as I can.

The deeper you understand something, the more possibilities open up

The computer science course began with learning the nuts and bolts of how a computer allocates memory using 1s and 0s. While this seemed interesting in theory, I was doubtful that I would actually need to apply this information.

That doubt changed when an assignment asked us to recover deleted files from a camera’s memory card. If you had asked me before the course, I would have told you that deleting files from a memory card means only one thing: the files are no more. But I now understood that file deletion is often the mere freeing up of memory so it can be reassigned – not overwriting it. Knowing this, I built a program to scan through a memory card for certain “file signatures” and recover once deleted files. Going that little bit further “under the hood” of computers opened up a great deal more possibilities.

Becoming deeply knowledgeable about legal tech is more than answering users’ questions about how to use a piece of software. Obviously, it is crucial that I master the software the firm uses so I can quickly interpret someone’s concern and find a solution or a workaround. But more than that, understanding the underlying technologies allows me to make more informed decisions about technology – not just the benefits and risks generally, but which of those risks are indeed probable and which are specious or outdated. For example, while there are some concerns about cloud-based software, traditional concerns about security no longer hold much water.

As change agents, we must have “one foot in each of two worlds”. As an innovator, the more knowledgeable I am about both the technology and the related legal issues the better I can act as a bridge between the firm’s tech and legal experts. The stronger an understanding one builds of each side, the more effective one can be.

The freedom of constraint

I was surprised by how much time I spent writing in constraints on user behavior. Basic programs, for example, might force users provide a single type of input like a positive integer. Without these constraints a program would be vulnerable to crashing whenever a user inputted something unaccounted for by the code. Thus, a key part of learning how to code is learning how to constrain your user’s behavior.

If even basic software constrains a user’s options, you can imagine that complex legal software must necessarily do the same in myriad ways if it is to be useful. Complaints such as “that’s not how I do it” can be a hurdle to adoption, but it would often be worse if the software had fewer constraints. Flexibility comes at a cost: increasing features and functions introduces new complexity. Having the discipline to perform low-value tasks in the way best suited for a computer can free one up to focus on higher-value tasks.

While I accept sifting through some highly-customizable tools with no clear workflow as part of my job, I know that most lawyers and staff just want a simple explanation of how to use the software – even if that means leaving out some nuances for alternative approaches.

Build competence through careful onboarding

Most code does not work on the first try. Trial-and-error is built into the development process – but it is insulated from the end client. You have to give someone a chance to make mistakes before they feel comfortable.

Lawyers are correctly risk averse about testing out a tool with a client on a matter before they feel competent with it. If law firms are truly going to take advantage of the opportunities that new innovations promise, they must figure out how lawyers and staff can go through the unavoidable learning process before applying it to a client matter. It is a tricky problem that requires active support from leadership. Without a safe and reliable onboarding process, the ability to scale usage of a tool – and its corresponding benefits – is inherently limited.

One way forward might be to uncouple competence from whether something is an external success or failure. A software product or feature can be poorly-received by the market and still be well-built by the programmers. This separation of product success and user competence is what Harvard Professor Gary Pisano identifies as one of the paradoxes of truly innovative companies: “tolerance for failure but not for incompetence.”

How do we evaluate the quality of legal services? For example, if we compare two proposed contracts for a commercial agreement, how do we determine which contract is of higher quality? Unlike code, where feedback can be immediate and binary, law struggles to provide standard measures for a lawyer’s deliverables. Any articling student will undoubtedly relate to the feeling of submitting a research memo while full of concern about whether it meets a lawyer’s vague expectations. If lawyers have more objective ground to stand on regarding the quality of their work, they might be more open to experimenting with supplemental technology.

Everything is harder than you think

After every lecture I felt like I had a strong understanding of the concepts discussed. Given the lectures were all recordings, I could even re-watch sections to ensure I understood everything. Making it all work together in the real world, however, was significantly more difficult than anticipated. How do I know if I should use a while-loop instead of a for-loop? What condition do I use? Can I nest an if/then statement into the while-loop? Can I nest a for-loop inside that? When do I create a dictionary, a list, or a list of dictionaries? Week after week, the humbling questions went on.

When I first started working as a legal innovator, the assumption seemed a given: there is amazing technology out there and lawyers just don’t “get it”. While there is amazing technology out there, I now realize things are more complicated. What about cybersecurity concerns? We want a tool in this category, but is this the “right” one? How does increasing adoption of technology lead to a more prosperous law firm? In both programming and legal innovation I have experienced the Dunning-Kruger effect more times than I can count.

Conclusion

While I don’t think it is worth my time to become the best programmer I can be, I am more curious than ever about what lessons from other disciplines I can apply to my work. The above lessons are not new, but discovering how other they work in fields leads to a deeper understanding. For instance, “T-shaped” professionals, now a hot buzzword in legal circles, derives from computer science circa 1991. Who knows what additional lessons are out there in other fields?