thinking like a lawyer vs. thinking like an engineer

Coppertop asked me yesterday what it means to "think like a lawyer" and how it's different from thinking like an engineer. There's a good start on what it means to think like a lawyer here, but it doesn't make clear how the precise thinking a lawyer does is different from the precise thinking an engineer does. It's taken a day of pondering and sleeping on the question, but I think I have the answer. From what I've been able to tell so far, in law, it's more important to keep the peace than it is to reach an ultimately just result, while in engineering it's more important to reach a "good enough" result than it is to get there the "correct" way. Everything else follows from that difference.

Let's start with law. That's a pretty controversial assertion: justice isn't what it's all about? Consider the idea of precedent, that one court will often defer to the decision of an earlier one, even if it disagrees in this particular case.[1] One important reason for doing that is predictability. You can't have the Rule of Law unless people know what the law is, and you can't know what the law is if it changes every time a new court looks at it. So we're willing to accept results that might not be perfectly equitable in a particular case so as to keep the peace in general.

If law is more about keeping the peace than about justice, what does that mean for legal reasoning? It means legal reasoning is not a search for the truth, it's a form of persuasion designed to convince the reader that a particular result is the proper one. Lawyers for both sides look at essentially the same facts and cases and write "tightly reasoned" legal briefs coming to completely opposite conclusions in order to convince the judge their conclusion is the right one. Similarly, judges write opinions designed to convince other judges, and ultimately the public, that their conclusions are correct.

How does legal reasoning work to convince people? Every argument proceeds in steps. Between the steps, there's some play in the joints. The more joints, the more play you have, and by adding just a little bit of adjustment at each joint, or by adding or removing a joint here or there, you can shift where the argument ends up. In general, it's very process oriented. I believe that's also why lawyers are so in love with citations, not because they help to reach a more correct result, but because they lend credibility to the reasoning process if other people have reasoned the same way at the point in the argument.

Thinking like an engineer is different. Engineers care about reaching the ultimate result. Does the spar carry the design load? Does the software run quickly enough? Their goal is to meet the design criteria for a problem--the wing must lift an X pound airplane while weighing no more than Y pounds itself--with an additional safety margin. It's much less important how you get there. Years ago, I was working with an applied physicist in an electronics lab building an amplifier. He'd calculated exactly the resistance value we needed and was going through an entire drawer of resistors, one by one, measuring the slight variations of each to find one that would match the value he'd calculated. My answer was to find a variable resistor, drop it in the circuit, hook up an oscilloscope, and adjust the resistor until it looked about right. It was a cheap kludge, but it got us to a working amplifier that met the spec and let us go home for the weekend. And that's a common engineering approach: use the theory, which is often only approximate, to get you close, then use your instincts to fudge things from there until the universe says you have it about right.

That's not to say that an engineer doesn't have to think precisely. Like a lawyer, a software engineer must decompose a problem into smaller and smaller pieces until the individual pieces are small enough to solve. In a piece of software the size of an operating system, that decomposition can proceed mighty far indeed, and a single misplaced character can bring the whole edifice crashing down. The difference is the focus: the engineer lets the goal drive the decomposition[2], while for the lawyer the decomposition itself must persuade the reader that the end result is the correct one.

[1] Apologies to the lawyerly types for being horribly sloppy here, rolling binding precedent, persuasive precedent, stare decisis, standards of review, and various forms of estoppel into one big ball. Suffice to say it's something that discourages one court from distinguishing, overruling, or reversing the decision of another.

[2] And here's where the software engineers get upset. There are other constrains on the decomposition, the most important being that it must be "maintainable", which is a fancy way of saying legible enough for another engineer to understand, and well enough organized that it's possible to make changes without introducing a whole bunch of bugs.