Alex Macgillivray, late of google and now of twitter, has a good post just now that might help hackers understand what transactional attorneys (aka corporate attorneys, aka ‘the people who write contracts rather than sue over contracts’, aka ‘me right now’) actually do on a day to day basis:
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.” … 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.
But as they say, read the whole thing.
Heh, nice analogy for one who writes contracts occasionally, (but not for the US legal system) nice comparison.
{{Sofixit}} — this is a strong argument for developing the field of legal compilers. Law deserves to be an art and a science, not just a trade; until it becomes both, lawyers with experience in fields that have those properties should feel compelled to fix the field.
[…] for engineering students frustrated and befuddled by those annoying “contract” things: what writing a contract feels like, explained in coding metaphors (analogy actually from Alex Macgillivray, but following Luis’s […]
[…] I’ve mentioned before, there are a lot of analogies between programming and legal […]
[…] I’ve mentioned before, there are a lot of analogies between programming and legal […]
[…] I’ve mentioned before, there are a lot of analogies between programming and legal […]
[…] writers have no equivalent of RFC 2119, mostly because contract drafting is hard. MSCD is a good try – defining terms and demanding consistency, just like the compiler […]
[…] writers have no equivalent of RFC 2119, mostly because contract drafting is hard. MSCD is a good try – defining terms and demanding consistency, just like the compiler lawyers […]
[…] writers have no equivalent of RFC 2119, mostly because contract drafting is hard. MSCD is a good try – defining terms and demanding consistency, just like the compiler lawyers […]