Write About Science Like Justice Breyer
Write About Science Like Justice Breyer
Google v. Oracle, Technical Topics, and Brief Writing
Justice Breyer is (affectionately) known for his long, and sometimes zany, hypotheticals at oral argument. But he is also the member of the Court most likely to get deeply interested in a complex intellectual property case. (After all, he did write an introduction to the Reference Manual on Scientific Evidence.) So it should come as no surprise that he was the author of the Court’s recent opinion in Google v. Oracle.
But this post isn’t about the merits of that case—at least not directly. It’s actually about legal writing, and how to handle scientific topics. Because what jumped out the most to me about Breyer’s Google opinion was not necessarily the result. It was that despite combining two intensely technical fields (law and computer programming) anyone can pick it up and understand it.
And as anyone who has ever tried to write about scientific or technical topics knows, that’s deceptively hard to accomplish. So how did Justice Breyer do it?
Three features of the opinion stand out.
Analogies
Though you’ll rarely find them in legal briefs, analogies are a great way to explain a complex process or concept. By comparing something familiar to something new, the writer can help the reader form a picture in their mind.
Breyer employs analogies throughout the Google opinion, beginning on the third page:
“One might think of a software platform as a kind of factory floor where computer programmers (analogous to autoworkers, designers, or manufacturers) might come, use sets of tools found there, and create new applications for use in, say, smartphones.”
Notice how he takes something esoteric (software platforms) and turns it into something concrete (a factory floor). The analogy allows readers to intuitively grasp something that most have never worked with.
Or consider later, after spending a great deal of time defining technical concepts relevant to the case, the Justice pauses to clarify one with two analogies in quick succession:
In this sense, the declaring code performs an organizational function. It determines the structure of the task library that Java’s creators have decided to build. To understand this organizational system, think of the Dewey Decimal System that categorizes books into an accessible system or a travel guide that arranges a city’s attractions into different categories.
Without them, a reader might ponder over this paragraph, trying to form a picture of an “organizational system,” an abstract concept that most people don’t think about often. But travel guides and the Dewey Decimal System? I get that. And now I see what Justice Breyer is trying to say about declaring codes: they are a way of labeling tasks.
Or, finally, the extended analogy near the end of the opinion’s facts section that draws everything together:
“Consider a comprehensive, albeit farfetched, analogy that illustrates how the API is actually used by a programmer. Imagine you can, via certain keystrokes, instruct a robot to move to a particular file cabinet, to open a certain drawer, and to pick out a specific recipe. With the proper recipe in hand, the robot then moves to your kitchen and gives it to a cook to prepare the dish. This example mirrors the API’s task-related organizational system. Through your simple command, the robot locates the right recipe and hands it off to the cook. In the same way, typing in a method call prompts the API to locate the correct implementing code and hand it off to your computer. And importantly, to select the dish you want for your meal, you do not need to know the recipe’s contents, just as a programer using API does not need to learn the implementing code. In both situations, learning the simple command is enough.
Now let us consider the example that the District Court used to explain the precise technology here. A programmer wishes, as part of her program, to determine which of two integers is the larger. To do so in the Java language, she will first write java.lang. Those words (which we have put in bold type) refer to the ‘package’ (or by analogy the file cabinet). She will then write Math. That word refers to the “class” (or by analogy to the drawer). She will then write max. That word refers to the ‘method’ (or by analogy to the recipe). …”
Simple? Of course not, but imagine reading those two paragraphs without the analogies built in.
Notice one other thing, too. Each of Justice Breyer’s analogy is fresh, not a stale cliche (e.g., needle in a haystack, fish out of water, wolf in sheep’s clothing). Readers skip over cliches. And they don’t create an image in the mind.
Conversational
If you read the full opinion (which you should), you’ll also notice that Justice Breyer’s opinions reads as if he is explaining the concepts to an intelligent friend. Sure, he uses longer words than many writing gurus prefer (like “particularly”), but it still seems natural—probably because Justice Breyer would use those words if he were talking to a friend.
He does not write an opinion that sounds like it belongs in a technical journal. This isn’t how a computer programer would describe the process. It is written for a person who is interested, but new to the topic.
Too often we (writers, and especially lawyers) are tempted to write for the “initiated.” Using jargon (or latin), or “impressive” words, when simpler ones would do. Justice Breyer’s Google opinion is a good reminder that good writing is clear writing, and we don’t need all that noise to make a point.
Fun
Lastly, you can just tell that Justice Breyer enjoyed writing this opinion. From the creative analogies to the warm tone to the willingness to get into the weeds, his enthusiasm bleeds through on the page.
We spend a lot of our time writing about technical topics. Statutes. Expert testimony. Technology assisted review. Google shows how your effort to get interested in them and make them interesting will shine through in the final draft—and also help your readers understand (and hopefully agree with) your point.
Conclusion
I’ll close with a couple book recommendations. If you’re looking for other examples of writers tackling technical topics with verve to enjoy and emulate, here are few suggestions you might enjoy:
Walter Isaacson, The Code Breaker
Charles Mann, The Wizard and the Prophet
Matthew Butterick, Typography for Lawyers
And with that, I’m signing off for the week. Enjoy your weekend!
Any opinions expressed here are my own. This article is not legal advice; if you have a legal issue, you should consult an attorney.
If you liked this article or have thoughts about it, please like or comment below (or email me at breese@flannerygeorgalis.com) and consider sharing it with your friends and network.
