Gyroplast

Wow.. I.. I did not expect such density of triggers in a single panel. Trolling truly is a art. The more you look, the worse it gets. I love it.

They were holding it wrong, obviously.

What AI-generated, non-working, obviously incorrect garbage is this? Also, you want to define this as an alias to type the command 33% faster, too!

alias fc='ffmpeg -c copy -map 0:0 -f data - 2>/dev/null -i '

Amateurs.

In some retirement homes, we hear feeble cries for justice, lamenting "source tarballs are even cross-platform, just build yourself already as intended", but nobody received that suggestion from their AI assistant, just a list of packaging services you should subscribe to instead.

NaCl (Technical Grade)

"I'm not alone here. Gotta setup a k-line to this surfer's cyberjack and ice his codes before he cracks my firewalls!"

TL;DR: You're getting different results for negative or otherwise invalid/unexpected input arguments.

A non-equivalence appears when passing a negative value as arg0 or arg1, which will always result in averageBets == 0 in the example, but >=0 with your code. The reason for this happening basically hides in your conditional incrementing of games, which allows for unintended "extra loops" if your conditions desiredGain <= 0 or stake < 1 are not met.

Also, the condition desiredGain = goal - stake; (desiredGain <= 0) ⬄ (goal - stake <= 0) ⬄ (goal <= stake) in your "win branch" is not equivalent to cash < goal, returning different results for all arg0 >= arg1.

The simpler example implementation handles these edge cases implicitly with cash > 0 and cash < goal, skipping the main work, but still running exactly all tries. It'd be fine, and actually preferable, IMHO, to add explicit input validation to your code to basically abort early, if the input values are out of bounds, but there's always a case to be made for keeping loops and conditions as simple, local, and immutable as possible, to avoid creating sneaky edge cases.

Unfortunately, it is very common for many examples to lack error checking and/or input validation altogether, just like here.

Consider a key pair, consisting of two brutally large numbers, but otherwise pretty much identical. Magical math exists that makes it so that if you math your data with one of these brutally large numbers, you get the original data back only if you math it with the other large number. That's basically it.

Now we slap convention onto this, and keep one of the paired, large numbers a secret, and call it our private key, the other number is disseminated and called the public key for that reason.

Now everyone can math data with your public key, so that only the paired private key, which only you know, can de-math it. This is encryption/decryption.

Signing is very similar, but now you use your private key, which only you know, to math a digest of your data, and all the world can de-math this correctly only with your public key, thus proving it was indeed your private key used to math the data in the first place, and by extension attribute the signature to your public key identity. Your private key is never known to anyone but you, which is an essential difference to "classical" symmetric encryption with a shared secret.

You may realize how easily a code signature can become a liability, if you fail to keep your private key secret for any reason. You can be trivially impersonated, with basically no chance of recourse or deniability with an SSH key, while you can at least invalidate a GPG key publicly and mark it as "stolen" that way. This is potentially very important, if there's any legal meaning attached to your signature, and if not, why bother with code signing in the first place, if "trust me bro" is well enough.

A study on 6 (six!) people? That's not a study, that's less than I get asking around during any lunch break. [this is worthless! meme] Wonderful trolling of some unpleasant cow-orkers, though, chapeau!

Crusty, cynical folks, entirely unlike and unrelated to myself, could be tempted to name it the Beginning of Eternal October for Linux.

Probably molly-guard.

I’ve had so much trouble with tooling

Obvious skill issue. /s

I don’t feel like I can make any impact

Assuming you don't just want to vent, but maybe get some sort of unfounded and useless opinion from a total stranger to go along with your misery, let me oblige. I've never been a cog in a truly large company, but I've been rubbing shoulders with managers and C-level just barely enough to begin seeing "their side", and consider it in my interaction with cOwOrkers and management to effectively act as a conduit or translation layer between camps. It's a metagame you'll have to want to play, but it can be rewarding to finnagle the systems of human psyche to have a positive impact, not only for yourself.

From a manager's perspective, everything has a cost. It's called tech debt for a reason. As long as paying the interest on your tech debt outweighs the perceived cost of paying off the debt, you're doing the right thing from a business perspective. In addition, be keenly aware of the fact that you personally will impossibly know the huge dark-company iceberg that is the existing tooling and its context. I guarantee you that there's so much unknown to you, which makes the proposition "I would fix this in a few days, just let me!" seem rightfully preposterous, and thus actively dangerous, as you obviously don't fathom the full complexity of the larger issue and would necessarily break things for others, despite your best intentions and competence.

Yes, the tooling certainly is utter garbage, and they should never have locked themselves in such a horribly broken situation, but there they are, and you can't just "fix this" without understanding the implications. Many devs, myself certainly included, easily fall into the trap of seeing an obvious and clear way of fixing everything™ in a matter of minutes, and realizing too late that "just one more patch" is an endless pursuit, all while breaking user-space for others on the way. It's a meme old as dirt among hackers.

Assume you don't know all the details, and really nobody does anymore, and you'll live a happier life if you leave this (business) decision of letting code rot to others. It's their money they're wasting.

What you can do, however, is gold-wrapping the pile of shit you need to work with. Find creative ways to wrap byzantine processes into a bunch of scripts for yourself to automate and generalize your tasks specifically, and watch your productivity soar and your mental health rise, and offer that as a working band-aid to your peers and manager. That's not only a better use of your time than seething over how shitty everything is, but also plays very well into a devops mindset and is actually kind of fun. It also comes across way better than being the "new guy who knows everything better, but actually hasn't seen nothing, yet", which leads to people not listening you in the first place. That vibe is an instant turn-off for any lead, and leads to shadow-banning you from interesting, fruitful conversations you seem to look for.

Obviously I'm confabulating all of this, and this may very well not apply to you or your situation at all. This is just a behavioral pattern I've seen way too often, and it's helpful to detect this in oneself to prevent unnecessary frustration all around.

My plan

is possibly your best option. Go ahead. You have no obligations or "loyalty" towards an uncaring entity holding you back.