Teaching, Learning, and Coding

One of my reasons for blogging this month was to articulate (more for myself than anything) the parallels between lawyer-like thinking and code-like thinking that I always understood in a macro-sense, but which became even clearer in the micro-sense when I decided to learn some actual code.  Jeremy Telman's response to my response to his post on scholarship in the Other Legal Academy seemed to bear on that (or maybe I'm stretching to see the connection, but whatever....).

In his view, "the differences in teaching in the OLA and the LA drive everything else."  Jeremy thinks he teaches his students contracts differently than he would if he were in what he calls the Legal Academy: focus on bar preparation; intense and frequent written homework assignments; in-class midterm; paternalistic measures such as taking attendance and banning laptops.  

I don't teach that way.  My approach is, I suspect (and to use some modern jargon), metacognitive along the lines of the the lawyering-coding parallels.  Would that work at Jeremy's school? Once again, I suspect there is an "other other legal academy" that is neither Harvard or Stanford (where the 25th percentile LSAT score is 170) nor OCU (where the 75th percentile is 152 and the 25th is 146); our school reported 75/50/25th percentile entering LSAT scores of 158/154/150. We have students who struggle with the curriculum.  But, as Jeremy (and my colleague David Yamada) point out, we have the advantage of being in Boston.  We get students who've chosen Suffolk over Northeastern or Boston College (or even BU), often because of generous financial aid, as well as evening students that usually include a raft of patent agents whose academic credentials include Ph.Ds from places like MIT, Harvard, Princeton, Johns Hopkins, and Michigan (Go Blue!).  

I do believe, with Jeremy, that it's a lot different teaching at a school like Suffolk than at an "elite" school.  Until the phase-out, I taught four classes a year (usually 12 credit hours) without relief for scholarly productivity, despite my logical but completely futile argument to the deans that if I got no relief then colleagues who didn't write really ought to be teaching 24 credit hours.  Oh well.  I don't believe, however, that I teach my subjects any differently than I would at an "elite" school.  Indeed, were an "elite" school to ask me to teach, as a podium visitor, contracts or intro to business associations (feel free to ask, by the way), I would use the same materials and the same approach I use at Suffolk.

It's that approach, and the "aha" moments about it from my summer project of learning computer coding that I'll reflect on below the break.

The parallels between learning how to code versus how to lawyer didn't jump out at me in the first couple lectures on the C language.  They did, and in spades, once I realized I had internalized the basic syntax of coding.  I had a problem to solve, and the trick was finding a piece of code that worked.  After I had moved from C to Python to JavaScript, I discovered that I could do a Google search that would give me code for almost anything I wanted to do.  Sometimes the first attempts worked; sometimes they didn't.  Sometimes the result was elegant; often it was not and I learned later how to make it more so.  What continued coding did was to give me mastery over more, for want of better words, theories and rules for getting the result I wanted.

That is the relationship between syntax and substance in lawyering, and some students pick it up more quickly.  At the very outset, I describe contract lawyering as an exercise in which we have a real life narrative that we need to translate into the logical code of the law, namely a series of "if-then" inferences that taken together generate from the facts of the narrative a legal conclusion that the client wants.  The students who struggle, I think, see it not as lessons in practice but as simply as information to be absorbed and regurgitated.

What you see at the left is the graphic I use when teaching the classic contract law chestnut Lucy v. Zehmer.  That is the case in which two guys, at a restaurant/bar and maybe having had a couple too many, agree on the sale of a piece of property, documented on the back of a restaurant check, but sophisticated enough to call for a clean title condition.  And the principle from the case is the one in the red rectangle - we'll decide whether the conditions of a binding promise exist not by what you stored subjectively in your head, but by the objective interpretation of what you said and did.

What the graphic is saying is that there is a way of getting to the issue that is code-like, using Restatement (Second) of Contract rules as functions.  What I want is a program that returns an answer to the question "is there a contract?"  Both §1 and §17 give you functions.  Under §1, it's a contract if there's a promise for the breach of which the law gives a remedy.  To resolve the question under §1, you'd need to run the "promise" function, which is §2, and then figure out that you'd need to run three different "enforceability" functions - §17 consideration, §90(1) promissory estoppel, or §86(1) promissory restitution. To resolve the question under §17, you need to show a bargain in which there has been a manifestation to a mutual exchange and a consideration (or one of the other "non-consideration" binding conditions in §§82-94).  In a wonderful demonstration of circularity, you go to §3 which tells that an agreement is a manifestation of mutual assent and that a bargain is an agreement to exchange promises and/or performances for each other.  Which takes you back to the promise function under §2 and the core of the Lucy v. Zehmer problem, which is whether Lucy's particular manifestation justified Zehmer in understanding that a commitment had been made (because if it did, all the other pieces fall into line to spit out the answer "yes, there is a contract").

That is the syntax in a nutshell.  Once you have it, learning more rules simply gives you more options, more theories, more efficiencies, more flexibility.  Assume somebody appeared (as perhaps in Lucy) to be drunk.  You could construct a theory that the drunkenness is evidence that Zehmer was not justified in understanding a commitment had been made.  It turns out there may be an even more elegant solution if you turn to the code offered by §16, which specifically addresses whether contract duties are created when somebody appears to be intoxicated.

When I coded my accounting exercise, I had a similar experience.  I set up a table in HTML that was to contain the income statement and balance sheet.  The point was to have those documents update with the correct bookkeeping entries over time as the narrative continued and the student answered the Q&A correctly.  When I started, I thought that I need to have data in the table cells from the get-go, which I would then use JavaScript to change.  There is a function in JavaScript for replacing a string of characters within a table cell.  For reasons I won't elaborate on now, it worked but it was balky.  I mentioned it to David Colarusso, featured in the video above, who knows a ton more about coding than I do, and his response was "Why are you using the replace function?  If you have the cells created, you can just insert data into them."  Sure enough, I did what he said, eliminated dozens of lines of code, made the presentation far more elegant, and ended the balkiness.  

The commonality between the lawyering and the coding is the meta-understanding.  To see that there is a more direct or elegant solution in each case, you first have to understand the syntax by which any theory or solution gets created. (I just went through the same thing figuring out how to put "padding" around the Colarusso video above, float it to the left, and reduce its size relative to the text. It involved going to the HTML version of this post in TypePad and altering the embed code that I got from YouTube.).  The other commonality is the aspect of creativity or pattern recognition that gets you from narrative to a rule or a theory or a piece of code that is useful in solving the problem (otherwise known in law school as "issue-spotting" or determining the "I" in "IRAC").

Based on student feedback over the years, I am positive that my approach resonates with students.  I have no idea whether that correlates with their success in the class or in law school. Nevertheless, I observe the common student clamor for determinate answers to their "but what if" questions - as though there were a clear outcome with a slight change in the facts of the hypothetical.  My response is invariably along these somewhat metacognitive lines:  you need to return to the original modus ponens logic of the rule used in the first hypothetical and then decide once again if the new narrative supplies facts that satisfy the "if"conditions of the rule.  When I get feedback to the effect that I don't answer their questions, I know that they didn't like that response.

The bottom line is that I think my approach works with enough students where I teach (and where there is significant support for students who the school believes based on past data are likely to struggle with the bar exam).  I think there's enough theory (indeed, students consider me "theoretical") to satisfy the best students at the most competitive schools.  I do not know if it would work for Jeremy.