"open mouth" as an open container is already a stretch.

"open mouth all the way down the lungs" as an open container is just bullshit. Rule of Cool definitely does not apply. That is not creative or cool in any way.

I agree with the general sentiment that there are limits to what should be possible even with the rule of cool.

In this specific case we don't even need to go into the territory of undefined stuff that the DM decides on the fly, the rules as written already explicitly say "You create up to 10 gallons of clean water within range in an open container."

You could always argue that humor does not equal jokes I guess, but these were just my 2 cents

That was exactly my main point; but thanks for sharing your 2 cents anyway, they were still interesting.

I would argue that:

1. This is not actually a joke in the strict sense of the word. There is no punchline. The humor is entirely in the context.
2. Your friend does not understand any of this and is just repeating the "joke" because other people laughed about it at some point. It has nothing to do with the Windows operating system, so if that was part of his explanation he is probably just making shit up to cover his own ignorance.

catering to gamers who wait at least 12 months after release to play a game

How is a game that did not even enter open beta yet relevant to this comunity?

Nowhere in that text does it say "managers are the real software architects". What it does say is "what managers do affects software architecture". Sure you can extrapolate that to delusions of grandeur, but if you take into account the explicit call for collaboration it is much more likely what was meant is more along the lines of "we can mess things up if we ignore the architecture, so let's talk to the real software architects before making org decisions".

About the comic: That one does have the line "management designs software architecture", much closer to the negative interpretation; but that too can be interpreted in a more positive way as "... and we are not good at that, so let's make sure to bring in the people who are good at it at important points".

That is pretty much a given. Why else write about it at all?

I read it similar, but also kind of from the other side: If your organization is set up in a way that ignores the technical requirements of the product, your are going to have a bad time.

And yes, of course this is more often on the bad side than on the good side in practice. If everything was already fine most of the time, there would be no point in discussing this topic.

The original post advocates for a holistic, collaborative approach; management and technical experts should be working together to align technical and organizational structure. I fully agree with that view (and I'm not a manager).

There is more than enough "shit managers say" material out there, but this is not it.

"being weird, rude and cringy is their whole thing" does not make that thing any less weird, rude and cringy.

Please don't mix executables and data created by applications, even if the application happens to be a game. Those are supposed to be separate. That being said, "Documents" is obviously the wrong place for save game files.

Link to full list: https://sanctions.nazk.gov.ua/en/boycott/

With Unilever, Mondelez and Procter & Gamble on that list, shopping for groceries and hygiene products might get complicated if you actually want to boycott all of them.

Feels weird to not see Nestlé on a list of big (food) companies doing questionable things.

Would you mind elaborating on that thought?

it’s really useful to comment functions/methods, because otherwise you never know if something’s a bug or a non-obvious feature. Comments act as a parity check to the code, since they tell you what the dev who wrote the code wanted the code to do.

Unit tests should be the parity check for other code. Those don't get outdated with the next refactoring where someone didn't remember to also adjust all the comments.

Also, everone thinks they write good, clean and obvious code. Hardly anyone purpously writes bad, hacky code. Yet if you look at code you wrote a year ago, or code someone else on your team wrote, it’s full of non-obvious hacks. That means, people constantly misjudge the obviousnes of their code. Comments should be put on anything that could maybe be non-obvious.

Why would people be better at judging if something needs a comment than at judging if something needs a better name or refactoring? Asking people to skip that judgement step and comment everything just gives you a bunch of useless boilerplate comments. That trains everyone reading that codebase to ignore comments because they are almost always useless anyway.

putting documentation of the code anywhere else than in a comment (e.g. Confluence) is a total waste of time

At least this we can 100 % agree on. Documentation should be as close as possible to the code. (I just think most of the time that place is in the name of things, not in an actual comment.)

To save you a click:

“No, there are no in-game purchases in our game. We believe in providing a complete and immersive gaming experience without the need for additional purchases. Enjoy the game to its fullest without any additional costs or microtransactions.”

About comments:

Please please please, do not always write comments. Try to write code that does not need comments whenever possible. Proper variable, class and method names go a long way. If you think a block of code needs a comment, turn it into a method and give it a proper name instead.

Comments should be a last resort for cases where making the code self explanatory is not possible, and those should be rare.

About optimization:

Optimal code is code that fulfills it's purpose without observable issues.

If you try to make something faster without any prior complaints or measurements indicating that it being slow is an actual issue, you are not optimizing, you are just engaging in mental masturbation.

There is nothing unhealthy about being annoyed when someone forces you to always come to them no matter what it is about again and again and again, instead of at least sometimes actively coming to you when they want to interact.

Both, both is good.

In the SHED survey, the gravity of this situation becomes more evident. The survey equates the displeasure of shifting from a flexible work model to a traditional one to that of experiencing a 2% to 3% pay cut.

Those number seem way too low to me. Just picking some semi-random numbers, let's assume a 40 hour work week and an average travel time to work and back of 1 hour per day, so 5 hours per week. Being forced to come to the office would then be equivalent to 12.5% more of your time spent to earn the same amount of money. Of course that scales depending on how far away from the workplace you live, but for 3% or 2% to be realistic you would basically have to live right next door.