Well this is a roundabout way of justified thinking about a belief that just happens to align with some actual facts..
Gettiers in software engineering (2019)
11–20 of 222 posts
Re: Gettiers in software engineering (2019)
#12Well this is a roundabout way of justified thinking about a belief that just happens to align with some actual facts..
On a more serious note: populist politicians seem to like making gettier claims; they cost a lot of time to refute and are free publicity. Aka the worst kind of fake news.
Re: Gettiers in software engineering (2019)
#13I always come back to this saying:
“Debugging is the art of figuring out which of your assumptions are wrong.”
(Attribution unknown)
Re: Gettiers in software engineering (2019)
#14I wasn’t aware there was a term for this or that this was not common knowledge - for me I refer to them as “if I fix this, it will break EVERYTHING” cases that come up in my particular line of work frequently, and my peers generally tend to understand as well. Cause/effect in complex symptoms is of course itself complex, which is why the first thing I typically do in any environment is set up metrics and monitoring.…
This is horrifying, and needs a trigger warning lol. It gave me a sense of panic to read it. It’s always bad when you get so lost in the codebase that it’s just a dark forest of hidden horrors. When this kind of thing tries to surface, it’s a warning that you need to 10x your understanding of the problem space you are adjacent to.
I guess I’ve worked in a lot of ancient legacy systems that develop over multiple decades - there’s always haunted forests and swaths of arcane or forgotten knowledge. One time I inherited a kubernetes cluster in an account no one knew how to access and when finally hacking into it discovered troves of crypto mining malware shit. It had been serving prod traffic quietly untouched for years. This kind of thing is crazy common, I find disentangling these types of projects to be fun, personally, depending on how much agency I have. But I’m not really a software developer.
Re: Gettiers in software engineering (2019)
#15The "programmer's model" is their mental model of what's happening. You're senior and useful when you not only understand the system, but can diagnose based on a symptom/bug what aspect of the system is implicated.
But you're staff and above when you can understand when your programming model is broken, and how to experiment to find out what it really is. That almost always goes beyond the specified and tested behaviors (which might be incidentally correct) to how the system should behave in untested and unanticipated situations.
Not surprisingly, problems here typically stem from gaps in the programming model between developers or between departments, who have their own perspective on the elephant, and their incidence in production is an inverse function of how well people work together.
Re: Gettiers in software engineering (2019)
#16Hmm, are there better cases that disprove JTB? Couldn't one argue that the reliance on a view that can't tell papermache from a cow is simply not a justified belief? Is the crux of the argument that justification is an arbitrary line and ultimately insufficient?
I was thinking that one solution might be to specify that the "justification" also has to be a justified true belief. In this case, the justification that you see a cow isn't true, so it isn't a JTB.
Of course that devolves rapidly into trying to find the "base case" of knowledge that are inherent
Re: Gettiers in software engineering (2019)
#17I wasn’t aware there was a term for this or that this was not common knowledge - for me I refer to them as “if I fix this, it will break EVERYTHING” cases that come up in my particular line of work frequently, and my peers generally tend to understand as well. Cause/effect in complex symptoms is of course itself complex, which is why the first thing I typically do in any environment is set up metrics and monitoring.…
I’ve come across (possibly written) code that upon close examination seems to only work accidentally — that there are real failures which are somehow hidden by behavior of other systems.
The classic and oft heard “How did this ever work?”
Re: Gettiers in software engineering (2019)
#18Hmm, are there better cases that disprove JTB? Couldn't one argue that the reliance on a view that can't tell papermache from a cow is simply not a justified belief? Is the crux of the argument that justification is an arbitrary line and ultimately insufficient?
Yes, the paper itself is much more unambiguous (and very short): https://courses.physics.illinois.edu/phys419/sp2019/Gettier....
These are correct but contrived and unrealistic, so later examples are more plausible (e.g. being misled by a mislabelled television program from a station with a strong track record of accuracy).
The point is not disproving justified true belief so much as showing the inadequacy of any one formal definition: at some point we have to elevate evidence to assumption and there's not a one-size-fits-all way to do that correctly. And, similarly to the software engineering problems, a common theme is the ways you can get bitten by looking at simple and seemingly true "slices" of a problem which don't see a complex whole.
It is worth noting that Gettier himself was cynical and dismissive of this paper, claiming he only wrote it to get tenure, and he never wrote anything else on the topic. I suspect he didn't find this stuff very interesting, though it was fashionable.
Re: Gettiers in software engineering (2019)
#19I wasn’t aware there was a term for this or that this was not common knowledge - for me I refer to them as “if I fix this, it will break EVERYTHING” cases that come up in my particular line of work frequently, and my peers generally tend to understand as well. Cause/effect in complex symptoms is of course itself complex, which is why the first thing I typically do in any environment is set up metrics and monitoring.…
This is horrifying, and needs a trigger warning lol. It gave me a sense of panic to read it. It’s always bad when you get so lost in the codebase that it’s just a dark forest of hidden horrors. When this kind of thing tries to surface, it’s a warning that you need to 10x your understanding of the problem space you are adjacent to.
The surest way to get yourself into a mess like this is to assume that a sufficiently complex codebase can be deeply understood in the first place.
By all means you can gain a lot by making things easier to understand, but only in service of shortcuts while developing or debugging. But this kind of understanding is not the foundation your application can safely stand on. You need detailed visibility into what the system is genuinely doing, and our mushy brains do a poor job of emulating any codebase, no matter how elegant.
Re: Gettiers in software engineering (2019)
#20The "programmer's model" is their mental model of what's happening. You're senior and useful when you not only understand the system, but can diagnose based on a symptom/bug what aspect of the system is implicated. But you're staff and above when you can understand when your programming model is broken, and how to experiment to find out what it really is. That almost always goes beyond the specified and tested behavi…
You are defining valid steps in understanding of software, but attaching them to job titles is just going to lead to very deceptive perspectives. If your labeling was accurate, every organization I've ever worked at would at least triple the number of staff engineers than it does.