Keeping It Real


This past weekend, I took part in the MIT Mystery Hunt. This year's Hunt was especially good (even if it was also brutally long): its Matrix theme was amusing and many of the puzzles were remarkably elegant. My team was scattered across the country, so I took a few puzzles and worked on them largely on my own. The best of the lot were the two invented-language puzzles. One involved some clever mutated genealogy; the other involved making an exhaustive list of a quarter million fictitious road signs and finding the one sign missing from that list.

Nastare suldi gruto ot py magi gruto ot pe mage uyta pe drel mala!

Anyway, faced with this sort of exhaustive enumeration, coding is the only real answer. I wrote a Perl script (it took me about four hours, which was more than I hoped but less than I feared) which cranked out about a hundred megabytes of detailed sign descriptions in roughly two minutes running time. It would have been fun -- and probably more efficient -- to use Prolog, but it's hard to beat Perl for pure pragmatic practicality when the chips are down.

True, I had to ask a few basic Perl questions of my teammates (and of the Internet), but on the whole, it was good to be programming again. It's like exercise; there's a real pleasure in the muscle memory, as it were. I like finding excuses to do some coding, even though I'd only go back to programming professionally under substantial duress. Programming is my way of keeping it real, of staying in touch with my roots. It's a reminder of why I got into law in the first place; it's a way of keeping up my street cred in the law and technology world.

As a law student, I like being a former programmer. There are certain habits of mind that one acquires from computer science, and I find that these habits serve me well.

  • Every protocol was made to be broken.
  • Look for the corner case.
  • A language is only meaningful in a particular context.
  • Precision of expression matters.
  • Design is harder and subtler than it looks.
  • Make a model; draw a picture.
  • Comment your code.
  • Keep your feet on the floor and keep your elbows at ninety-degree angles.
  • The right choice of notation can help you structure your thinking, but notation is ultimately irrelevant to the underlying problem.
  • Look for trouble at boundaries.
  • Keep your interfaces clean.
  • Early design decisions have a way of locking themselves in.
  • Patterns, patterns, patterns.
  • Sometimes you need a quick hack; sometimes you should take the time to do it right. It all depends.
  • If you don't have the tool you need, invent it.

Taken together, these rules form a kind of rough-and-ready characterization of computer science, the most pragmatic intellectual discipline on earth.

Talking about the mental habits of different fields of study is a parlor game, much like discussing whether Russia is a European or Asiatic society, whether Python or Perl is a better scripting language, or what the differences between men and women really are. One shouldn't read too much into the sweeping generalizations that result (another lesson of computer science: beware of sweeping generalizations). All the same, there's a kernel of truth here.

Mathematicians love abstraction and beauty. Physicists want to know how things work. Historians look for narratives; engineers know what happens if you don't dot your is and cross your ts. But computer scientists are the ones who don't have a set methodology. We're mercenaries. Faced with a problem, we do whatever it takes to find a solution, or at least a klugy workaround. True, we mumble various claims about elegance, but it's remarkable how many things have come to be considered "elegant" that started off life as a knife in the back of the genuinely "elegant" solution. Today's bug is tomorrow's feature, and vice-versa.

Of course, this venality has its downsides. The "just ship it" mentality is in large part responsible for the sorry state of software and security today. And computer science, taken as an academic field, is a giant blob of jelly. It has no real structure, no core set of skills, knowledge, or principles to define it. The field is just a mess of overlapping specialties, each organized around a particular complex of problems and their customary solutions. Each Next Big Thing is just another accretion on the tarball.

To some extent, though, the hideous mess that is at the center of computer science is part of its appeal. You have to enjoy the grimy details; you have to have some ability to be amazed by the complex interlockings of rules that almost -- but not quite -- fit together. The pragmatism of computer science is a form of intellectual triage; you learn to size up a failed solution to an intractable problem and spot the parts worth saving, the parts worth revisiting, and the parts worth abandoning entirely. True, you won't solve the problem either, but at least you can do some good in the attempt.