5 ms·

This is precisely why when dealing with bugs I advise juniors to avoid asking the question, "what changed?" Gettier cases are just one problem that you can face

This is precisely why when dealing with bugs I advise juniors to avoid asking the question, "what changed?" Gettier cases are just one problem that you can face when asking that question. Instead I usually tell them to do it the proper way: start from the bug, and work backwards to understand why that bug is happening. At that point the change that caused the bug becomes obvious, and most of the time we realize that we probably wouldn't have come to that conclusion by looking just at what changed.

RugnirViking 8y ago
This is one of two approaches to the problem of debugging a system. It's advantage is that assuming the programmer can focus on everything they have seen in the debugger for long enough, they can find where the issue arises. It's disadvantage is that as systems get larger, it can get exponentially more time consuming. As programmers we sometimes learn tricks (read: assumptions) to cut down this time, but in the end, the complexity of the system beats all but the very best/most determined. Consider tracing a bug in this manner through the entire code of something as complicated as an operating system. Most of the code you did not write yourself, and you have likely never seen before and no idea what it does. Each new frame the debugger reaches you have to spend time understanding what is happening before determining if this is where the problem occurs, and there are so many frames that it can become difficult to sort through them all.