No, generally speaking. But sometimes yes.

I would say that myself and most programmers appreciate there is always some logical root cause for why things work or don't, and its very unsatisfying to have thigs work without knowing why. It's also problematic, because if you don't know why then it might break again in future and you can't fix it.

That said, programming is different from pure science. The explicit point of science is to uncover the truth and understand and make it replicable. The point of programming is to have a software product that functions.

So realistically we may as programmers occasionally let something slide without knowing the full detail, because we are working to different goals.

This is especially true based on the category/criticality.

Something "magically" starts working in the core backend payments API code? Not good enough, we need to know exactly what the cause was and cover it in tests.

Something "magically" fixes the UI bug that caused a weird but inconsequential margin padding that affected Samsung Galaxy S21 devices ONLY and no other phone? Hallelujah, it's a miracle.

I can't find a source for this now, but this is the last part of the intro sequence of Doom 2016 (NSFW due to a dead guy, some blood, and earlier in the clip a lot more gore). After they got the sequence audio perfectly synced up for the console platforms and (I believe) the more popular graphics configurations at the time, the director said no one was to touch that part of the code at all, under any circumstances. It's not that they didn't have version control, it was just that it was so finicky that they didn't want to have to go through that trouble again. For reference, this is what it's like off-sync, with the shotgun lagging a bit behind the end.

The scary one is where you complete your code and give the test suite it's first full run.

...and it passes...

[Cue scary dramatic music]

Damn. Must have missed a test case, there's no way that was correct first time...

Don't you guys have version control systems?

The thing that wasn't working was something the previous junior programmer made just before leaving the company, and it never really worked right. The junior programmer in the picture was trying to fix it without understanding how it worked and broke 3 other things, so he's been urgently trying to get all the things working together. The senior programmer doesn't care if it was fixed the best way because he knows the whole system should be redone but he'll be retiring before that happens.

"Praise The Omnissiah!"

Now we need to figure out how and why

You're missing the part where you try over and over again to replicate the result and it keep failing. Looks like the first time was the only time, too bad. Then, as you clean out the freezer six months later, you find a leftover vial from the experiment in the back that randomly formed perfect single crystals that you excitedly diffract only to be disappointed because despite everything it's somehow triphenylphosphine oxide because it's always triphenylphosphine oxide. Even though there was supposedly no phosphorus of any kind in the original experiment. Turns out, the undergrad intern has been double-dipping pipettes in your special personal cache of NaK-dried THF and cross-contaminated it, and that contaminant TPP stabilized your experiment---phosphine stabilization is well known, after all, which is why you were trying something new and different without phosphine to begin with. Oh well, sucks to be you, the undergrad graduated already and is gone.

coconut.jpg

I remember a while back seeing some commented segments of code from TF2 and one was about:

"I have no fucking idea who put this here, but when I deleted it the game wouldn't start. Words cannot describe my fucking confusion."

Referring to an image in the game files of just a coconut.

And then you're a programmer who's also a scientist.

yes, absolutely