Degorath

There's high level boss encounters and such, they're quite difficult and fun.

As a vaguely related example I can recommend Settled's "Nightmare mode" player-invented game mode. I don't want to spoil it ahead of time, but he fights some cool endgame content with the caveat that if he takes even a single point of damage, his account is automatically deleted.

Well, stacking is one thing, doing it well is another (see github) ;)

But that's good to hear.

As someone trying to compete in this space: will ERSC make the change/commit their unit of code review? It's one of the pet peeves I have with GitHub et al.

Thought I saw that announcement on LinkedIn a few weeks back already!

Unfortunately I wouldn't know how to do that.

But just saying that I would probably argue against any new forge at my workplace if it didn't adopt the jujutsu model for changes. While agents can wrangle git better than 90% of developers, jujutsu just works much better for both.

Does it support jujutsu natively?

There's simply a ton of teams that also never updated. My previous team was not using RTK and our redux setup was extremely confusing to me (a backend engineer).

Ah, that's a shame to hear. I would only like to add that at least for Android apps that I've been "hanging around" (my team never really worked on them), the teaching materials that are provided have generally made them a lot more pleasant compared to the RN stuff.

While all of the points you brought up are valid, I've hated every react native app I've ever had to work on. Not because of react native itself, but because they usually take random react developers to work on these apps and the structure they create is absolutely horrible to work with (compared to, for example, native apps).

What was your experience on that aspect with Flutter?

Bit late to the thread, but I'm building a EU native jujutsu forge that optimises for productivity and ability to deliver your features faster.

I saw that tons of companies are still on GitHub, using their unproductive tools that have no vision to how they work together and I want to do something about it.

The landing page will be up soon, but for now I am actually looking for a cofounder with a technical product management or engineering management background (the multitasker hustlers that know tech), so do reach out if that sounds interesting to you!

That's really cool! I tried getting on board with ERSC, but the timezone difference proved too much :(. At least it gave me the kick to try and build my own company, though!

Already working on that!

My experience is that in companies that rely on this flow, these assumptions are generally hashed out during design doc review/discussions. I have never had it happen to me that I need to discard the rest of the stack for an assumption that did not hold. From another angle, if I fear that this might be the case, I hold off on sending parts of the stack to review until I am sure of the assumption holding OR I instead have a "workspace ball of mud" from which I can `split` out well-formed commits. I found this to be an incredibly productive workflow.

Not sure if it makes you feel better, but it seems there's at least a few startups trying to get a jujutsu-native forge going, by people who have seen and used the way Google's (and other big tech's) systems work.

Jujutsu makes the author-side of it all fairly nice, indeed. But the reviewer-side has been so horribly abandoned by github that it has been frustrating me for a long while now.

I would like to add that CachyOS also supports Niri, a scrolling tiling WM. As someone who long had "papercuts" from floating WMs I've had great success with it and even prefer it to something fully tiling like hyprland.

Depending on the country, it's not even that difficult to fire in the EU... (e.g. Estonia and Poland)

Well, they are wishing to lock you into their ecosystem, so that switching would be a high-friction decision. And then they can simply raise prices without you leaving.

Do you folks also hire outside the US?

Not anymore they don't (usual caveats apply: no longer work there; big company so YMMV). It was an option for a while, but getting it to work with the remote filesystems for the monorepo was a bit annoying (e.g. you'd create a new project in IDEA where you'd have to pick what parts of the monorepo you wanted to have in there, but it all happened up front).

I just want to mention that in my personal anecdotal experience, every codebase I have ever worked on, except 1, was underengineered and not overengineered. The last one was just "engineered".

Fairly certain they do something like Anthropic does, they count the acceptance rate or something else that is fairly "optimistic" (my org has a code acceptance rate of 98,5% per the platform dashboard). So, to clarify, me accepting the suggestion and then correcting it by hand still counts as N LoC accepted.

I'm building a new version control forge around Jujutsu :). I think GitHub is pretty bad in its UX and I want to build something that is a) more opinionated than raw git; b) optimised more around team usage than GitHub is; c) uses nicer algorithms for diffing, merges; d) can be scaled slightly better than Git (in the context of entire teams of developers).

Essentially taking a lot of the good ideas already out there and turning it into a coherent product.

My experience has so far been similar to the root commenter - at the stage where you need to have a long cycle with planning it's just slower than doing the writing + theory building on my own.

It's an okay mental energy saver for simpler things, but for me the self review in an actual production code context is much more draining than writing is.

I guess we're seeing the split of people for whom reviewing is easy and writing is difficult and vice versa.

I was really taken in by this premise a while back so I tried building some side projects with server side swift on my windows machine inside WSL.

I really wanted to like it, but the experience was terrible, from the editing side (with vscode) all the way to the performance of existing frameworks (tried both Vapor and grpc-swift-2).

No, but it is a European leader that has ~recently enjoyed that situation, but is no longer in it. Sorry, but I don't want to spell it out too obviously, for my own privacy.

I understand what you mean, but at this point I don't find it ironic at all. It's been quite similar in my corner of the world, where a leader enjoys great support and visibility externally, but is fairly unpopular internally.

But if you just want a nicely typed interface for your APIs, in my experience gRPC is much more useful, because of all of the other downsides the blog author mentioned.

Could you please elaborate on "patterns for your interfaces"?

Not the person you asked, but I hate how it screws up keyboard shortcuts. It overrode the delete line shortcut with its own inline chat one, for example.

Decided to ditch it for claude code right after that, since I cannot be bothered to go over the entire list of keyboard shortcuts and see what else it overrode/broke.