Thursday, November 17, 2016
This is a "wouldn't fit in 140 characters" overflow blogpost from a twitter discussion of software developers learning in law school. I'll attempt to explain just why law school, and thinking about legal "balancing" and "multi factor" tests can be so frustrating when you're trained as a software developer.
Computer science trains developers to expect logical proofs, and compilers give you a definitive immediate feedback of "yes this is at least one kind of correct because it compiles," which is something you can't do in a legal world. But it's more than that. Programming is a step by small step process, where the computer takes you literally. You're probably saying "yes, I know that," but I mean that quite literally, the computer does exactly what you tell it to do. A programming language is a set of tools you can use to construct a solution to a problem that you've broken down into tiny manageable steps. My first time I figured out that there's a logical system to solving problems, where being at state "A" meant you applied one of a known set of possible next steps, and again and it would lead you to a solution, was amazing. It was relaxing and exhilarating and fun all at the same time to process the problems and to see how the logical next step at each stage would get you to the answer. To realize that divide, conquer, apply next step from this toolchain, and repeat would get you somewhere, and it would be fun to do so, is addictive.
In college computer science classes we learned not just a particular language, but that any programming language was just "syntactic sugar" and any non-NP complete problem could have a solution written if you just attacked the problem the right way. It taught us to, again, break down an issue into discrete steps, apply the tools of the programming language, and end up with a working piece of code. A developer becomes pretty good at trying to fit problems into recognizable boxes that are sort of like previous problems, and applying the same pattern of solution to them.
Debugging also teaches developers to be incredibly detail oriented and literal. The computer does not do what you meant, does not do what you thought you typed in, but only explicitly and completely and totally exactly what you actually typed in. The compiler is going to follow the directions you gave it, and execute those, and the outcome is always the same for that same set of directions.
So our software developer who decides to go to law school realizes that law school isn't like software development. Sure, there is no legal compiler. Gotcha, outcomes vary and these are more heuristics. But this is still a brain that's been trained to fit problems into boxes, to be literal about what rules apply, and to follow logical deduction chains. The law usually says one thing, but hey, not in this case- the mental model I've built of what the law says now has an exception to it. The logic branches under this condition. I update my mental model to account for that exception and move on. But I'm still, even if subconsciously, constructing a big logical flowchart in my head that's going to handle all these curve balls in judicial opinions.
Until it doesn't work anymore. My first breakdown came over two torts cases that, to my mind, came out in logically inconsistent ways. My email to my professor was pretty much trying to expand my rules to handle this inconsistency: "How should we reconcile these? Is it just that under battery, particulate matter is considered one way and under the other tort it has a different nature?... The engineer in me is having a bit of trouble with particulate matter being a Schrodinger's cat here, both enough for a tort but not enough for a tort."
The thing is, developers are pretty good at tackling incredibly complex problems and writing up solutions, and so the first curve ball isn't really going to stress your worldview that much. You just add an exception to your mental model and handle it. At some point, this mental model gets stretched too far. It won't handle another contradictory result. Multifactor tests that judges apply come out all over the place, briefs claim to be arguing logically and deducing one part of the argument from the previous one but they're making leaps in inferences, and your poor developer brain will just decide the whole thing is insane.
I had a series of mental freakouts one L year. It's not that the tools you learn in programming are useless in legal analysis; they're actually really helpful. Reading an opinion and constructing a mental model of the relevant law, finding the holding and following how that was applied in this instance are helped by the mental toolkit a developer has. Trying to make peace with the logical-but-not-really logical fuzzy mess of legal reasoning and how the common law really works is kind of a process. Pretty sure my subconscious is still building that exception laden tree, working off "fuzzy logic" precepts now.
Posted by wendy at 5:22 AM