At most any given scope, "most" systems you interact with aren't under your own control. For this, consider: because that's true, the fault is yours for not grappling with that reality.

This has been written about before:

https://ruggedsoftware.org

But even that was missing a bullet:

- recognize that my code will interact with systems I cannot anticipate, that change in ways I cannot control, and become coupled more than ever intended

I commented back, maybe with a little too much confidence, that if their input file changes daily, then their program changes daily. That is, from one day to the next, it may take different paths (or a different combination of paths) through the code's logic. In that way, I claimed, her program was like a language interpreter, and her input files were like programs.

She didn't seem completely convinced, but apparently they got the job running again because there was no follow up on that particular issue.

I've seen this a lot.

A few examples:-

- this code isn't logging -> is logging broke -> code was never deployed - 500s are being thrown -> it's definitely not my code -> revert code 500s cliff face

Literally, every week there is a version of that. I have no idea why or how to tackle it but it is highly prevalent across skill set and roles.

Many of those are automated and usually escape proper review. And they can be minor or catastrophic.

I always try to look at "what changed that causes this failure?"

And do so blamelessly. Pointing fingers only gets disdain and blame.