Hacker News Reader

His real belief was not exactly that the PR broke it, it's that the root cause of the break was isolated to his code changes. This is evident from the debugging procedure he described. And that distinction is very important, because that detail, and not some abstract piece of philosophy, is also the real source of the challenges that motivated describing the situation in a blog post in the first place.

What I'm really trying to say is that the article isn't describing a situation that relates to Gettier's idea at all. Gettier was talking about situations where you can be right for the wrong reasons. The author was describing a situation where he was simply wrong.

> His real belief was not exactly that the PR broke it, it's that the root cause of the break was isolated to his code changes. This is evident from the debugging procedure he described. And that distinction is very important, because that detail, and not some abstract piece of philosophy, is also the real source of the challenges that motivated describing the situation in a blog post in the first place.

Yes, but the exact same point can be made about the Gettier case. The problem is inappropriately specified beliefs. The problem with that is that it's impossible ex-ante to know how to correctly specify your beliefs.

For instance, you could just say that the problem with the Gettier case is that the person really just believed there was a "cow-like object" out there. Voila, problem solved! But the fact of the matter is that the person believes there is a cow - just like this person believes that their PR broke the app.

I think I agree with the parent. While this can be made into a Gettier case by messing with the scope of the JTB (pull request broke it vs change broke it) I don't think it really works as intended by the author, and it feels like a poor example in a field teeming with much more straight forwards instances.

I can't simplify the explicit examples I have in my head enough to be worth typing up, but the gist is that I can be correct about the end behavior of a of a piece of code, but can be completely wrong about the code path that it takes to get there. I have good reasons to believe it takes that code path. But I don't know about signal handler or interrupt perhaps, that leads to the same behavior, but does not actually use the code path I traced out.

This happens to me reasonably often while debugging.

I think you're interpreting the author's belief in a way that you want rather than what he actually says. I read the belief based on this statement from the article:

"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."

That's it. That's the belief - he broke autofocusing when he released the new version. This was true. The later digging in to find the root cause is merely related to this belief. And yes I agree that Gettier's cases were meant to show that correct belief for the wrong reasons (maintaining the three criteria essentially), but this case meets that intent as well. The author is correct that he broke autofocus via his pull request, and thus JTB holds, but the actual reason for it is not his personal code and thus the Knowledge is incorrect.

Agreed. This is not some unusual philosophy case. This is a case of a programmer who should know better (rebase is not exactly a no-op change!) ignoring one of the most obvious possibilities.

I think this is accurate, and not at all pedantic.

The idea that software has 'gettiers' seems accurate and meaningful. To some degree, making and maintaining gettiers is in fact the point of black-boxing. Something like a well-implemented connection pool is designed to let you reason and code as though the proxy didn't exist. If you form beliefs around the underlying system you'll lack knowledge, but your beliefs will be justified and ideally also true.

(One might argue that if you know about the layer of abstraction your belief is no longer justified. I'd argue that it's instead justified by knowing someone tried to replicate the existing behavior - but one form of expertise is noticing when justified beliefs like that have ceased to be true.)

And yet this story isn't about facades breaking down, it's just a common debugging error. Perhaps the precise statement the author quotes is a true and justified, but the logic employed isn't. And it's an important difference: being aware of environment changes you didn't make is a useful programming skill, while being aware of broken abstractions and other gettier problems is a separate useful skill.

Typically, philosophers would not consider a belief about a formal system justified unless that belief is backed by a proof.

In software, for known behavioral specs, you don't have a real justification until you write a formal proof. Just because formal proofs are uneconomical doesn't mean there's some fundamental philosophical barrier preventing you from verifying your UI code. Doing so is not just possible, there are even tools for doing it.

So really, this is not a Gettier case, because in formal systems a true justification is possible to construct in the form of a mathematical proof.

An example of a Gettier case in a software system would be formally verifying something with respect to a model/spec that is a Gettierian correct-but-incorrect model of the actual system.

There are almost no software systems where we have true JTB (proofs), so there are almost none where Gettier cases really apply.

Uncertainty in software is more about the economics of QA than it is about epistemology or Gettier style problems, and that will remain true until we start writing proofs about all our code, which will probably never happen.

Maybe I am arguing the same point as you here, but I am uncomfortable that you are painting the justification criteria as being debatable in these situations.

In particular, I think your criteria for justification is too low. The standard for justification is - however much is necessary to close off the possibility of something being not-wrong.

I find the JTB concept to be useful to reminder us (1) that the concept of knowledge is an ideal and (2) how vulnerable we are to deception.

As an idea survives rounds of falsification, we grow confidence that it is knowledge. But, as Descartes explained in the evil demon scenario, there is room for doubt in virtually everything we think we know. The best we can do is to strive for the ideal.

> however much is necessary to close off the possibility of something being not-wrong.

This is borderline self-referential with respect to the whole Knowledge definition, though. If you have enough information to remove the possibility of a belief being not-wrong then there's no point in defining Knowledge at all. The whole debate around the definition is that humans have to deal with imperfect information all the time, and deciding what constitutes Knowledge in that environment is a challenge.

> Truth: The pull request did break it. There was an additional reason beyond the pull request unknown to the author,

Nope:

> At some point, I did a routine rebase on top of this change (and many other unrelated changes).

> [...]

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