Except there is a saying in aviation, "All the flight regulations and rules are written in blood."
Meaning that, over the past century, there was actually a ton of "testing in prod" in aviation. The industry learned many, many valuable lessons only after the billions and billions of hours of flight time exposed issues that weren't caught in preflight testing.
Your comment begins with "except", but the content agrees with the GP.
GP would like aviation users ("passengers") to not be the ones doing the testing. You state aviation users historically tested -- it's why flight regulations and rules are written in blood. I suspect the blood of passengers is exactly what the GP would like to avoid.
I can't tell if you didn't make the connection, or if your commenting style is just to naturally start negatively. My suspicion is the former, given the throwaway account.
Nope, that’s not the same thing at all. Those regulations are for required test coverage before things make it to prod. And they only happened in prod before the regulation because it was an unforeseen possibility.
You’re deluding yourself if you think the aviation industry just sells directly to customers new aircraft without testing them.
“Testing in prod” means, “I’m gonna try this thing and I’m not sure if it will work and my test environments don’t cover that so I’ll go straight to prod and see if it breaks.”
The software industry is the only place where that works because shipping to prod is literally faster than test suites in lots of cases and the stakes are so low on failure.
Unexpected catastrophic failures in prod != testing in prod.
It's quite clear the author of the article doesn't at all think that "testing in prod" means how you define it here. I'm not making any argument over what "testing in prod" should mean, but given how the author goes to great lengths explaining that he is not using it to mean "just throw stuff out in prod and let my users deal with it", I don't think it's fair to then say "Oh, keep this guy away from aviation because he tests in prod."
I think the snarkiness of this comment (and the replies, to be fair - I'm not just picking on you) gloss over an actually important point that you're making: testing strategies and infrastructure involve a hidden cost-benefit analysis that we could all benefit from being a little more cognizant of. Writing some internal tool or need to ship tomorrow? Maybe you can skip that test. Building an airplane? Maybe not.
Quite the opposite. That philosophy is even more important in critical industries.
Because the article very clearly says that you should still test before going to prod, but that it's just as important to treat going to prod as another testing stage where you will find problems you couldn't find before - and that you need to be prepared for that so you can find them early.
Doing so is very much an important best practice in aviation - you monitor planes in production, and you try to make sure that problems which almost lead to disaster are reported and investigated, rather than hidden.
Even aviation does test in prod. They just do it after a large amount of testing beforehand. The point of the article is not that you shouldn't test before exposing new changes to production, but you should also test, monitor, and validate in production too. Understanding how things are performing in production is critical to identifying when things misbehave, and there's no getting around that for any large-scale system.
And what a great philosophy. Just don't apply for jobs in aviation, or anywhere critical.