I did this yesterday. I was writing a variation on a function to draw some stuff in the terminal. When I ran it, it worked fine, no crash or anything like that.
Turns out I wasn't running the new version of the function.
I once progressively commented out more and more of a file, trying to find the bit with a bug, until the whole thing was commented out and no source was being compiled yet the original buggy behavior was still there and only THEN did I figure out I was editing a different file than I was compiling.
Echoes of this original sin have shown up repeatedly throughout my life, to be point where it's one of the first things I check when my corrective measure has no effect on problematic behavior.
Half the reason for them is to provide an abstraction that maps a spacelike addressable quality to data to be operated on. It's an extension on the more general concept of namespaces. What's the difference between data HERE and data THERE. different path.
Even with stuff like git or other VCS's where you fudge the spacelike mapping with an extra layer of time-like addressing...
This is the content HERE from 3 revision's ago vs. the content HERE now vs the content over THERE either now that or 3 revisions ago...
I have to train people to break them of the habit/hubris of thinking they are "smarter" or more "accurate" at computation than the computer is. If you take the meaning of compute to be "creatively navigating to a solution in a problem space, humans win hand down.
If you define it as reliably doing the same thing over and over again, give up. The silicon has you beat. Always check your assumptions against what the machine is actually doing. Checklist if necessary. That puts you on a footing where you can actually outdo the computer in both realms.
Or don't and be reminded once again of why being human is the most pitiable form of cognitive logic, where it takes hard work just to ensure a consistent response to similar classes of stimulus over time, and where remembering and recalling things is totally non-trivial. In the quest for staying alive in a dynamic world doing it's best to kill us, our brain does great. In a world in which it'd be nice not to be reminded by my equipment of my own idiocy on a regular basis, not do much.
Getting control means making the system do something of your choosing. It’s not the thing you really want (until you’re done), but it’s something you decided. In your case, printing.
Extend control means make it do something else you want. This should be a small step. It’s surprising how few small steps you need to get a pretty complex system going. Here you might print from the function you’re fixing.
Sometimes when you go to extend control, the system won’t do what you want. You’re surprised. This means you’ve lost control. The good thing is because you took a small step (right?) the problem is now in a narrow space.
Get control again. Either go back to what you did before, or take the smallest possible step forward from there.
You will spend all your time with a system you either can control or nearly can. This ways of debugging is slower than how most people do it in the median case, but much faster in the mean. Debugging time is dominated by the worst cases, and this real cuts down on those. Especially the ones that make you feel dumb.
A critical thing is to not just “check” but “do”. If you have a computer that won’t power up, you don’t just check it’s plugged in, that’s not controlling anything. You plug in another computer or electric heater.
This way of working is rather peaceful. Much less frustrating than how most people do it. The most frustrating part is when someone asks for your help and tells you not to bother checking that thing, they know it works. And that part, and that part, and that part. But somehow this system they have complete confidence in as parts doesn’t do what they want in the whole. Best phrase for this situation:
“Well, let’s just try it for fun.”
> Make originated with a visit from Steve Johnson (author of yacc, etc.), storming into my office, cursing the Fates that had caused him to waste a morning debugging a correct program (bug had been fixed, file hadn't been compiled, cc *.o was therefore unaffected). As I had spent a part of the previous evening coping with the same disaster on a project I was working on, the idea of a tool to solve it came up. - Stuart Feldman
But yeah, I guess the predecessor it replaced must have been even worse. Today we can have higher expectations.
Most of the time it's unnecessary, but when it catches such issues it saves countless hours of frustration.
[1] https://github.com/scottlamb/moonfire-nvr/issues/209#issueco...
(Next was something to snapshot the VM, followed by "apt-get install ext4magic". It worked!)
This used to happen to me all the time too. The solution I ended up going with was to standardize all my build scripts on `./build run` as the way to (build and) run the program, with the actual binary getting shoved in ./bin/ or something to discourage running it directly (which also reduces clutter). Basically, get rid of the "run without building" command entirely.
Sometimes I forget to check that my test fails the first time, so I’ll go back and deliberately break the function under test just to see it fail.
> I did this yesterday. I was writing a variation on a function to draw some stuff in the terminal. When I ran it, it worked fine, no crash or anything like that.
Either way, it’s just confirmation bias.