Refreshingly written. And like wading into the ocean on a surprisingly hot spring day, bracing.
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.
- 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
A team manager once called and asked me if anything changed in the hypervisor (I used to support and make local modifications to some virtualization software) because her team's daily data processing job failed, which previously had run with no issues and nothing changed at their end.
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.
Something I've noticed a lot is the how quickly people jump to complicated answers.
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.
Refreshingly written. And like wading into the ocean on a surprisingly hot spring day, bracing.
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
A team manager once called and asked me if anything changed in the hypervisor (I used to support and make local modifications to some virtualization software) because her team's daily data processing job failed, which previously had run with no issues and nothing changed at their end.
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.
Something I've noticed a lot is the how quickly people jump to complicated answers.
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.
No YOU may not have changed anything. Your colleagues might have. The system might have. The network might have. Windows/Linux updates might have.
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.
I mean, you can have nothing change on your side, but guess what, your customers didn't talk to you but they are changing things all the time.