the jsomers.net blog.

In 1963, the philosopher Edmund Gettier published a three-page paper in the journal Analysis that quickly became a classic in the field. Epistemologists going back to the Greeks had debated what it meant to know something, and in the Enlightenment, a definition was settled upon: to know something is to have a justified true belief about it:

• justified in the sense of deriving from evidence
• true, because it doesn't make sense to "know" a falsehoood
• belief, i.e., a proposition in your head

Gettier, in his tiny paper, upended the consensus. He asked "Is Justified True Belief Knowledge?" and offered three cases---soon to be known as "the Gettier cases"---that suggested you could have a JTB about something and yet still we would want to say you didn't know it. For that, he earned lasting fame, and his paper generated a literature all its own.

A Gettier case

Supppose you're standing in a field and off in the distance you see a cow. But suppose that what you're actually looking at isn't a cow, it's just a convincingly lifelike model of a cow made out of papier-mâché. You're not seeing a cow, you're seeing the model. But then finally suppose that right behind the papier-mâché cow is a real cow!

On the one hand, you have a justified true belief that "there is a cow in the field": (1) you believe there's a cow in the field; (2) that belief didn't come from nowhere, but is justified by your seeing something that looks exactly like a cow; (3) and there is, in fact, a cow in the field. Still, we wouldn't want to say that you know there's a cow in the field, because in a sense you got lucky: by a strange coincidence, there happened to be a real cow there---a cow you knew nothing about.

In software engineering

At my old company, Genius, the CTO---who'd studied philosophy as an undergrad---was obsessed with these Gettier cases. He called them "gettiers" for short. So we used to talk about gettiers all the time, no doubt in part just because it felt clever to talk about them, but also because when you're a programmer, you run into things that feel like Gettier cases with unusual frequency. And once you have a name for them, you start seeing them everywhere.

Here's a recent example. I was working on a web application that used a client-side framework that had been developed in-house. My app was a little search engine, and in my latest pull request, I'd made it so that when you hit Enter in the search field, the field lost focus, so that folks who like to browse the web via their keyboard wouldn't have to manually escape from the input box.

When I released the new version, I noticed that I'd broken the autofocusing of the search field that was supposed to happen on pageload. I started poking around, only to discover that I couldn't seem to get the correct behavior back. No matter what code I changed, which lines I commented out, how many times I hard-refreshed the browser, etc., I couldn't get the autofocus to work.

What had actually happened is that a coworker of mine had made a change to the framework itself, which changed how certain events were bound to the root DOM element, and as a result broke the "autofocus" attribute. At some point, I did a routine rebase on top of this change (and many other unrelated changes). Which meant that when I deployed my little pull request, I was also deploying a bug I had nothing to do with---one that ended up breaking autofocus. It only appeared as though my changes caused the problem, because I'd edited some code having to do with focus in the search field.

Note that I had a justified belief that "the pull request I just deployed broke autofocus on the production site," and in fact my change did break it---making the belief true. But the break actually happened for a completely different reason!

(Yes, I should have caught the bug in testing, and in fact I did notice some odd behavior. But making software is hard!)

Here's another example. (This one's from a long time ago, so the details might be a bit off.) A user once reported that on-site messages were no longer generating email notifications, and I was asked to investigate. Soon, I discovered that someone had recently pushed a change to the code that handled emails in our web app; the change seemed to introduce a bug that was responsible for the broken behavior. But---gettier!---the email service that the code relied on had itself gone down, at almost the exact same time that the change was released. I could have had a JTB that the code change had caused the emails to stop delivering, but still we wouldn't want to say I "knew" this was the cause, because it was actually the service outage that was directly responsible.

A new term of art

A philosopher might say that these aren't bona fide Gettier cases. True gettiers are rare. But it's still a useful idea, and it became something of a term of art at Genius---and has stuck with me since---because it's a good name for one of the trickiest situations you can get into as a programmer: a problem has multiple potential causes, and you have every reason to believe in one of them, even though another is secretly responsible.

Having a term for these tricky cases allows you, I think, to be ever-so-slightly more alert to them. You can be a better developer this way. As I've spent more time writing software, I've gotten better at sensing when my assumptions are probably wrong---when something gettieresque might be going on: have I forgotten to clear the cache? Am I working off the wrong branch? Am I even hitting this code path?

Software is a complex and ephemeral business. More than most people, developers are daily faced with bizarre epistemological problems. It helps to be able to distinguish a cow in the field from, well, a gettier.