From Lawyer to Programmer
erincodes.wordpress.com
erincodes.wordpress.com
I would say the two professions are more alike than credit is given, and working as a programmer in a lawyer-heavy firm, I've often been told by those in the legal profession that programmers have the ability to think logically stepwise through law more clearly than others.
I think it is for this reason that many on HN enjoy discussing the law (of course it does have many other practical consequences as well). And although OP did the opposite, I would encourage many technical minded people to consider law as an option - much of the reason that laws suck for technology is because the people who work with the law on a daily basis do not understand the technology, and it would be great if we had more general tech literacy in the legal profession.
I'm a programmer and I have a law degree, but I don't quite agree with your assessment. Practicing law (as opposed to the study of it) isn't usually about applying the law to facts; most of the time, it's representing the facts in a way that is favorable to your party under a given set of rules. It's a lot more soul-crushing than I thought it would be (I still like the theoretical, academic aspects, so I stick to those areas now)
"I think it is for this reason that many on HN enjoy discussing the law"
Well now we're getting near a pet peeve of mine - the absolute cluelessness about law that most technologists have. Most take one or two paragraphs, read it literally in a way that is beneficial to their prejudices, and call themselves lawyers, using the 'law = algorithm' analogy. I see very little nuanced legal reasoning when it comes to topics nerds like to discuss (look no further than all the nonsense written about the Aaron Swartz case a few months ago, and the idiotic responses when people like Orin Kerr write an actually informed piece about it).
but that's another topic, it was as you said at least more informed than the average person (but disappointing for a law professor and former CAFA prosecutor/defender).
and just to add to this conversation, I will have my law degree in a month and I'm just now starting to learn programming. I plan to use it in conjunction with things like Latex for building better briefs, building a robust issue bank, etc... - things that will enable me to be a better lawyer in practice.
The purpose of testing, though oft missed due to the name we have given it, is to document your code. The tests explain intent, usage, etc. that can often not be conveyed by the code alone. Verification that the documentation does what it claims comes as an added bonus, of course, and is why we recommend testing over writing comments. Though comments can also be useful in certain situations – right tool for the job and all that.
I feel like law could benefit greatly from something that mirrors TDD, not only to help convey intent of the law, which is information often lost as years pass, but also to help third-parties better understand what the law says. The exact same reasons why we write tests for code. Starting to write that documentation after the code is already in production, so to speak, seems too late.
In common law countries, the entire process of law is actually a black box functional test. And again: that's the only test that counts. Everything else might be wrong.
I went through something similar. Quit finance, hacked my ass off for a year then Google gave me a chance. Everything has been amazing ever since :)
(This is a less dramatic situation in Australia because law is an undergraduate degree in this country).
Nevertheless, I greatly value the habits of thought that law school taught. I find the legal way of thinking illuminates a lot of the work I do, and the practice in writing brief upon opinion upon statement upon tutorial paper is an education in itself.
It makes me really happy to see other women become programmers after other careers. We aren't alone!
Add to that the fact that schools are always really slow to change, requiring you to fight for anything remotely progressive (the school I was teaching in graded multiple choice entrance exams by hand); it's really easy to get sucked into the traditional educational model even if you don't believe in it; and teaching doesn't allow for the creativity I want in my life.
I suddenly realized that I wanted to be creating not evaluating — to be always learning and building on what I know. Programming does seem to offer that.
Sad thing is, most people don't think about what makes them happy. They simply try to live up to societal norms & expectations.
Here's one of my favorite quotes from John Lennon:
"When I was 5 years old, my mother always told me that happiness was the key to life. When I went to school, they asked me what I wanted to be when I grew up. I wrote down ‘happy’. They told me I didn’t understand the assignment, and I told them they didn’t understand life."
Sidenote: Charles Stross explores the intersection of computation and law (and many other ideas) in Accelerando (think, as the Singularity takes hold, sentient business plans with Turing complete articles of incorporation rule the ball of mostly dust that used to be the solar system). It's a free and enjoyable ebook:
http://www.antipope.org/charlie/blog-static/fiction/accelera...
It's always interesting to see these types of posts on HN. I disliked the whole 'law thing' so much that after graduating from law school and passing the bar, I never applied for a single legal job but instead went into tech (which has been my true passion since I was 9 years old). In my case, I learned that it's always a bad idea to live out someone else's dreams instead of your own. In other words: don't go to law school simply because your parents/spouse/etc want you to.
I've done both.
Law teaches how to bring rigour to fuzziness. In software we can set boundaries and push the fuzziness back into the problem domain. Lawyers can't do that, they must address the world as it is.
Let me explain what I mean.
Suppose you use constants with values for HOT, WARM, COOL and COLD. In a normal computing system you will need to define these precisely -- you'll need to give float or decimal values to the thresholds between them.
By setting those thresholds, we simply make the complexity go away. Users wind up carrying the bag for any paradoxes that arise.
Lawyers can't do that, they deal with linguistic variables:
The reasonable person similarly circumstanced.
The buyer at arm's length without notice.
Offer and acceptance.
Reasonably foreseeable.
You can't give any of these a hard value (though the general features of each are pretty clear for almost all cases). They are fuzzy sets.
Dealing with fuzzy sets without destructively reducing it to ordinary logic is almost unique to law. About the only other people doing it are some control engineers and the attendant theoreticians.
edit:
I'd also add that the experience of extremely careful examination of facts and teasing out subtle distinctions are useful skills. So too the learned ability to do that with buckets of documents, quickly, and then having to draft reasonably straightforward briefs or case notes.
I find that skill particularly useful when discussing requirements / user stories.
At the top of the list I'd put "the learned ability to do that with buckets of documents, quickly, and then having to draft reasonably straightforward briefs or case notes."
One's goggles in going through the rooms of buckets of documents are tuned to those "fuzzy sets" of legal issues. An ancient lawyer once said that lawyering is the art of finding the relevant.
Or as Edmund Burke put it: "Law sharpens the mind, by narrowing it."
But don't lawyers deal with this fuzziness to some extent by putting the question to a jury? For instance, suppose we were writing a software application to decide when to shut down a machine because it got "too hot". We could go ahead and assign a specific temperature, or perhaps set up an equation with a few different readings.
Now suppose there was some litigation because a tennis player collapsed during a tournament that was "too hot". Would the lawyer define "too hot", or would the jury? You could have a situation where all parties agree on the law, and that it turns on whether it was "too hot", and the legal system would treat the jury's definition almost as definitively as a temperature reading input into an algorithm, right?
On the other hand, if the player were to sue for negligence, then the question of whether it was "too hot" is a factual question that the jury would decide, after the lawyers present evidence for their preferred answer (and possibly evidence against the undesired answer).
The jury's finding would be a finding of "fact" as to whether it was "too hot" would apply only to that case, because their finding would necessarily depend on the specific facts of that case. Juries cannot make findings of "law", which are general principles/rules that can be applied to other cases.
The jury.
> the legal system would treat the jury's definition almost as definitively as a temperature reading input into an algorithm, right?
For this case, yes. For all time, no. The fuzzy set of "too hot" would become the legal precedent (the stare decisis). The actual temperature would remain a question of fact and not law.
If you read up on how fuzzy logic is applied in control systems, you'll see that there's always steps to take non-fuzzy inputs and "fuzzify" them before performing the fuzzy logic itself. Afterwards you de-fuzzify to get a crisp output.
Courts work very much like that: the law retains fuzziness because no crisply algorithmic system can encompass the total complexity of the human world. That's how equity arose ... which is a law history lesson for another day.
There are a bunch of papers on what counts. My take away was that many courses of study say they have a way of reasoning, but at the end of 4 years (or an additional 3), most students perform no better on abstract tests of whatever metric was selected for that major (e.g. law, analogic reasoning