Yeah, makes sense, context is important, indeed

It was Dark Souls before Dark Souls was mainstream made

Exactly this, both is the best choice, especially if it’s not marketing bullshit

For people on reddit everyone on reddit knows what reddit is

Except not all people are on reddit, and this same approach is often used because one assumes that everyone is.

Haven’t read the article yet, but when I find something described in terms of similarities to something else I can check what that else is to get a better idea. Having a detailed description would still be of use, too

Being able to add them to the library as “play later”

If only the demo doesn’t turn into pumpkin, as often happens with demos of yet unreleased games after release. Which is a shame

Oh, but communication

No, not this time, at least

it’s for the French locale

True, there is a spectrum of options, and some will work much better than what we have now. It’s just that when I read about holding people accountable I don’t quite imagine it’s going to be implemented in the optimal way, not in the first hundred years or so

That’s just covering up, like a disclaimer that your software is intended to only be used on 29ᵗʰ of February. You don’t expect anyone to follow that rule, but you expect the court to rule that the user is at fault.

Luckily, it doesn’t always work that way, but we will see how it turns out this time

with billions of dollars in losses

But the real question we should be asking ourselves is “how much did tops saved over the course of the years without proper testing”

It probably is what they are concerned about, and I really wish I knew the answer to this question.

I think, this is absolutely not the way to do business, but maybe that’s because I don’t have one ¯\_(ツ)_/¯

This might help in some regard, but this will also create a bottleneck of highly skilled highly expensive Engineers with the accountability certificate. I’ve seen what happens when this is cornerstone even without the accountability that would make everything even more expensive: the company wants to cut expenses so there’s only one high level engineer per five or so projects. Said engineer has no time and no resources to dig into what the fuck actually happens on the projects. Changes are either under reviewed or never released because they are forever stuck in review.

On the other hand, maybe we do move a tad bit too fast, and some industries could do with a bit of thinking before doing. Not every software company should do that, though. To continue on the bridge analogy, most of software developers are more akin to carpenters even if they think about themselves as of architects of buildings and bridges. If a table fails, nothing good is going to happen, and some damage is likely to occur, but the scale is very different from what happens if a condo fails

Lol, that would feel like world-scale schizophrenia¹, you know something happens, but there’s no proof it’s real

Well, you can make daily a torture, too

But really, feels good when there’s time to actually work instead of just talk

No, that was what I meant, I thought they didn’t, I was wrong, it turned out

Made easier to use like in when their codebase was leaked and no one had successfully built a game from it?

in-house tools often encourage making a mess heavily reliant on those tools or working around their limitations, in my experience

Merge requests should be rather small to make it easier to review.

With this I wholeheartedly agree

if your work warrants multiple commits, then it probably also warrants multiple merge requests.

With this not so much, but if you keep your merge requests so small, squashing them is no big deal, that’s a good counterexample for my previous point.

another good thing is that when we decide to release, we can easily look through the commit history for a change log. No more sifting through minor fixes commits.

That still requires you to write meaningful messages, just a bit rarer. We do have trouble with change logs, but we had exact same problems when people squashed left and right. Maybe squashing helps self-discipline, though, I haven’t thought about it that way

I agree that stash gets lost easier than a branch, but

It can be difficult to know which stash belongs to which branch

you know, stash also has a message to it, and afaik it remembers what branch you were on when stashed

How about WIP: <description of what you wanted but did not achieve yet>?

Also, squashing is a pretty bad practice as it is. I can understand that it may make sense sometimes, but most of the time if you don’t commit every other character you input, you’re better off leaving some history of how your code evolved and what changes were coming together