> This is my first time really reading a legal opinion I enjoy reading SCOTUS opinions. Here are a couple meta things to keep in mind when reading high court o

> This is my first time really reading a legal opinion I enjoy reading SCOTUS opinions. Here are a couple meta things to keep in mind when reading high court opinions. First, SCOTUS is mostly focused on issues where lower courts have disagreed on a case or issue. The goal is that courts should be consistent because their job is to interpret the law. Juries are (mostly) responsible for interpreting facts. Elected legislatures are responsible for creating the laws. So, at the SCOTUS level they want to provide clarity about how to interpret fundamental issues of law and the constitution when lower courts interpret things in different ways. They usually are not primarily concerned with the specific outcome of some case. They want to fix potential 'bugs' in the system. In software programming terms, they want to fix problems with the language interpreter or parser, not so much the debug the program. When two supposedly compatible interpreters get different results from the same program code, they want to disambiguate the language rules. In fact, their opinions sometimes essentially concede, "We don't like the result of correctly interpreting this law (ie "program code") but the interpreter is running correctly. The legislature needs to fix the law. (ie write less ambiguous code)." Obviously, this sometimes clashes with the public's everyday understanding of courts pursuing 'justice.' A surprising number of laws have ambiguous wording, so it's interesting when I read a SCOTUS case where I hate the net effect of the decision but agree that it's correct. In a sense, writing laws shares much in common with software programming. Sometimes the code isn't doing what the programmer intended but it is running as written, or: bad legislators often blame the courts in the same way bad programmers blame the compiler or CPU.