You’re right, it’s not. But in this case it was specifically the “lucky” feature that came into play. Getting the better result through sheer dumb luck is exactly what was supposed to happen.

Also, I strongly disagree with your barbarian hitting a machine example. Rolling a nat 20 attack roll against a machine damages or outright destroys it. I’m not rewarding players for choosing literally the opposite course of action from one that might resolve the problem, no matter what they roll.

If the barbarian wants to try a hail Mary tool proficiency check with their lack of proficiency and -1 intelligence penalty and lucks into a nat 20 for a result of 19 on a DC 17 check then I’ll happily flavour it as “percussive maintenance”, but an attack roll just destroys the machine because that’s what attacks do.

Does the extra fuel you used hauling around your entire launch vehicle not count as waste?

There are groups that actually play FATAL? Terrifying.

I mean, sure, if the writers wanted to put the chip in something else they could write different lore about what it does, granted. In the same spirit of “How do you kill a vampire? However you want.”

The chip specifically interacts with human brains on a biological level. It’s not a “normal” AI.

I don’t think they could. The chip isn’t a normal program that any old computer can run.

Ugh. Literally refactored multiple factories into straightforward functions in the most recent sprint where I work.

Someone saw a public factory method which was a factory for a reason and just cargo culted multiple private methods using the same pattern.

There a progress bar in an application I wrote that has a one in twenty chance of saying “Reticulating Splines” instead of its usual label.

I have a few hundred users so there are definitely people who have seen it, but so far no one has mentioned it.

Was about to say this looks like ahdok’s work, then I noticed who posted it. :D

Oh, true. It had slipped my mind that see invisibility allowed you to see things that were innately invisible and not just things magically made invisible.

Well now I just look foolish!

In order for the specific circumstance called out by the disintegrate spell description to be possible it requires a violation of the general case, yes. That is literally the point of the “specific overrides general” rule.

One of two things must be true for disintegrate to be able to destroy a wall of force:

1: The Wall is targetable by disintegrate.

2: Objects on the far side of the wall are targetable by disintegrate and the wall gets in the way.

For “specific overrides general” to hold a DM must rule that one of these is the case, otherwise the extremely specific interaction called out in the disintegrate spell description is impossible.

Of course as DM you can rule that this is not the case and disintegrate does not destroy a wall of force, such is the prerogative of a DM, but I am firmly of the opinion that such a ruling is not RAW.

“Specific overrides general” is RAW though, and the spell description of Wall of Force calls out that exact spell interaction as a way to destroy it.

Even if you don’t count desktop applications like VSCode or Discord or whatever that are written in primarily JavaScript due to those arguably just being packed inside their own little browser engine that they ship with, still yes.

Node.js is an extremely widely used JavaScript runtime environment that people are using to write server back ends and command line utilities and god knows what else in JavaScript.

I cannot express how pleased I am that the company I work for went all-in on remote work during the pandemic and allowed the lease to lapse on most of their office space while sub-letting the rest. RTO is a literal impossibility for us now. We simply don’t all fit in the remaining office space we have, and assuming new leases on more office space obviously looks terrible on quarterly reports.

There are many other ways that the company I work for is miserable, but I take the small victories where I can.

Isn’t the blue glow only present under water (or other transparent medium with a similarly high index of refraction)?

I would be ashamed of myself and be tempted to leave the industry in disgrace if setting up DDNS and allowing a single port through a firewall took me 45 minutes.

The place I work says they do this and will claim with a straight face that our sprints are budgeted to allow approximately 20% slack time.

This is of course not even remotely true in any practical sense. I have not received an explanation for how it’s even possible when sprint targets are intentionally set at slightly more than was done in the previous sprint, every sprint.

Xerox did that ages ago.

https://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning

Yes, rogue could have a 100% chance of success. Obviously their chance isn’t going to get any better than that, seems like an odd thing to bring up as a counter point though.

As for your suggested explanations for the assistance, none of that lines up with it being at worst non-impactful to do a paired group check. The rogue is completely unimpeded by helping the paladin, and in situations where their chance isn’t already 100% they might even have a better chance, since any possibility for success from the paladin could potentially cover a failure from the rogue. If the rogue only fails on a 3 or less and the paladin needs a 19, that raises the success rate from 85% alone to 86.5% with the paladin tagging along.

Even it was a group comprised entirely of equally skilled rogues I don’t think it makes sense to make them more stealthy in groups, which is what this rule does, for the simple fact that larger groups of people are enormously easier to spot.

If the simple fact that literally any pairing of two people is more stealthy then either of them alone isn’t enough reason to not use this rule for stealth then I don’t know what is.

So what, exactly, is the justification for how a rogue “covers for” a plate wearing paladin with no dex bonus? Keep in mind that that “half must succeed” rule means the rogue is very slightly more likely to succeed with a noisy partner than alone, assuming that success and failure are possible outcomes for both participants. Even if it’s impossible for the other to succeed the rogue is at worst unimpeded.