what writing a contract feels like

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.