Hear Ye! Since 1998.
Please note: This post is at least 3 years old. Links may be broken, information may be out of date, and the views expressed in the post may no longer be held.
4
May 10
Tue

Transactional attorneys as coders

Alex Macgillivray, Twitter’s GC, has a post on what makes a transactional attorney’s job difficult. Glad I’m not the only one who has compared drafting contracts to writing code (people look at me funny when I draw that analogy). Law is, after all, codified in “codes”.

There is a lot of joy in making a deal work and thinking of creative solutions to disagreements but the job is also VERY tough. To put it in computer terms, imagine the contract as a computer program. In each the object is to be able to interpret the words and have that interpretation drive a result. Now imagine that there is no compiler for your program and that you can’t run any tests. All debugging must be done only theoretically and in your head. Imagine that you are coding with another person that is likely to be trying to develop a program that does something significantly different from what you want it to do. You and the other programmer may have different time constraints and, even though you are trying to do different things, you have to be on good terms with the other person because she could just as easily decide to stop working on your project. You and the other person take turns editing the code but without a common coding environment or standard tools to figure out whether the other person (or you) goofed it up. Then imagine that the code you are writing has a high probability of only ever being “run” through two different interpreters with significantly conflicting points of view about desirable outcomes and you likely won’t get to see the result of any of these “runs.” Or you may be asked to interpret the code in light of complete changes in context. Include a small chance that your code will be “run” by a relatively unbiased interpreter but the outcome of that one interpretation will be at extremely high stakes, often millions of dollars. Finally, know that you will likely get little credit for writing good code but will be crucified if the one time your code is run it doesn’t work flawlessly. Now you are beginning to understand how hard the job of a good transactional attorney is.

I can safely bet that those developers across the room from me don’t think of me as writing code when I’m hammering out a licensing contract…

Microsoft Word is my IDE. We have spell check, which is our rudimentary syntax checker, but no automatic semantic analysis tools, no way of test running it through an interpreter to pick up runtime errors. And no instant gratification from hitting the “run” button and watching it just work. (But it is pretty nice putting pen to paper and signing an agreement. Incidentally, we also call it “executing” an agreement… in much the same way that .exe files are compiled, executable files.)

  11:12pm  •  Law  •   •  Tweet This  •  Comments (1)

This post has a single comment

1.  Roger

Very insightful.
I always feel it so demanding to ‘interpret’ sentences in a contract documents. I hope my brain could be as fast as a Java virtual machine to find problems ‘just in time’.

Add a Comment

You must be logged in to post a comment.