A three-page paper that shook philosophy, with lessons for software engineers
&gt; A philosopher might say that these aren’t bona fide Gettier cases. True gettiers are rare. But it’s still a useful idea...<p>At least as presented, I see the idea being used to do more harm than good.<p>Take the first example, with the form not autofocusing. We&#x27;re already not in a Gettier case, because the author didn&#x27;t have JTB. The belief that he caused the bug obviously wasn&#x27;t true. But it wasn&#x27;t justified, either. The fact that he had rebased before committing means that he knew that there were more changes than just what he was working on between the last known state and the one in which he observed the defect. So all he had was a belief - an unjustified, untrue belief.<p>I realize this may sound like an unnecessarily pedantic and harsh criticism, but I think it&#x27;s actually fairly important in practice. If you frame this as a Gettier problem, you&#x27;re sort of implying that there&#x27;s not much you can do to avoid these sorts of snafus, because philosophy. At which point you&#x27;re on a track toward the ultimate conclusion the author was implying, that you just have to rely on instinct to steer clear of these situations. If you frame it as a failure to isolate the source of the bug before trying to fix it, then there&#x27;s one simple thing you can do: take a moment to <i>find and understand</i> the bug rather than just making assumptions and trying to debug by guess and check.<p>tl; dr: Never send philosophy when a forehead slap will do.