I have recently been relearning a lot of programming. My focus has mostly been on Javascript because it gets results for what I am building (I am working with AngularJS, NodeJS and LoopBackIO if you are interested). In revisiting programming best practices, I have come to realize that there are many, many parallels between writing good code and writing good contracts.

Organization is Key

Just like you need to think through the architecture of your software before you start coding, a contract also requires a good roadmap to help guide you as you draft the legal language. I find that writing the words is much easier than the planning that goes into it. The roadmap also helps you understand exactly what you are drafting, so that you can think through the clauses and other moving pieces. There is hardly a greater waste of time than to be halfway through a paragraph and then to realize you need to restructure the entire document because you did not fully flesh a detail out in the roadmap.

DRY – Don’t Repeat Yourself

I think this principle is possibly more important in law than software. With a software project, you can end up with an unmaintainable, unupgradable mess, but with a contract, repeating yourself can have interesting legal consequences. First is the question of why you repeated something. Is clause A the exact same as clause B? Did you intend the former to have a slightly different meaning than the latter (this can be particularly problematic if the wording is slightly different)? Further, in addition to making the contract longer and harder to read, when you get into negotiations and start changing things, duplicate clauses can be disastrous. At least with software, something, somewhere breaks or throws an error (hopefully!). With a contract, you may not realize that there are different terms than what the parties intended until months or years down the line.

Make it Readable

This is probably more of a software issue because at least contracts are written in legal English so maybe other lawyers can understand them. There is no such guarantee (I think) with complex, poorly written and/or documented software. It is still terrible what some lawyers draft. I have had many, ‘it’s written in English but doesn’t say anything,’ moments with all kinds of legal documents. At the end of the day, you can generally write contracts in plain, American English, but for whatever reasons, lawyers love to use the unintelligible jargon they are (in)famous for.

Slight Differences

The biggest difference between coding and drafting is the base nature of the work. Both use a form of English, but programming is a mathematical language expressed with words as proxies while law is a legal language based on the intricate grammatical depths of word relationships. The former governs the actions of computers while the latter covers people and their various dealings. The other big difference is with the people themselves. Programmers can be assholes, yes, but I rarely wish god would strike one from the face of the earth. Lawyers, meanwhile, can be the some of the most saintly, kind-hearted people you will ever meet or literally some the evilest, vile, manipulative scum to walk the planet.

Programming and law are both exceptionally useful tools for the knowledgeable, both remarkably dangerous for the uninformed. Though, I think coders are somewhat beloved by society, and lawyers, sometimes justly, are rather disliked to say the least.