Degorath

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.

The IDE experience on Linux doesn't make it any better either.

Oh how I wish I could have a working Swift :(.

My guy, obviously I tell the person they're pulling a dick move first.

We're not talking some entry level staffers here, it's senior engineer FTEs who are employed at a tech company who are doing this.

I've decided to fight it the same way I fight tactical tornadoes - by leaving those people negative reviews at mid-year review.

(I also find the people who simply paste LLM output to you in chat are the much bigger evil)

(Yeah, I'd say your messaging was reasonably clear, but in the context of the whole thread it wasn't obvious whether the poster was putting themselves in that skill bucket.)

I think there's also quite a big spectrum of skill, even when we're talking about compiler optimization and highly skilled software developers. I'd put myself up there, but still I'm no Lars Bak (for whom Google allegedly created an office in Denmark).

Unfortunately, in 95% cases location IS a factor with bigger companies.

I'm in a similar position where I'd like to do something a lot more interesting, but intersection between where the interesting companies have offices and where I'd be willing to live do not really overlap enough justify rooting up my life.

(Unless we're talking about "too good to ignore", that's a different story.)

Not the person you were discussing with, but I have to add that to me the main benefit of using Stubby et al. was exactly the schema that was so nicely searchable.

I currently work in a place where the server-server API clients are generated based on TypeScript API method return types, and it's.. not great. The reality of this situation quickly devolves the types using "extends" from a lot of internal types that are often difficult to reason about.

I know that it's possible for the ProtoBuf types to also push their tendrils quite deep into business code, but my personal experience has been a lot less frustrating with that than the TypeScript return type being generated into an API client.

Living in a place is quite a bit different to travelling there.

I really _want_ to like Swift, but the development experience was so abysmal that it turned me off the language entirely.

I have been entertaining the thought of writing an LLVM frontend for Gleam, though. (I don't know what I'm doing, I don't know if this is doable, etc.)

I agree with the OP that it sort of is. Moving around in the EU is a lot more difficult than moving around the US, so a lot of great talent just doesn't want to.

In my opinion they need to invest a lot more time and money into it for that. The development experience on VSCode was pretty bad (I think the LSP has a memory leak), and some important (for me) libraries aren't tuned very well yet (a Vapor webserver can sit around 100 MiB memory, whereas putting a bunch of load on the grpc implementation balloons the memory usage to >1 GiB).

Swift on Linux has been a fairly horrible experience, but the language looks promising.

Nowhere in this quote are these fresh grads equated to "lousy programmers", though (which the flamebaity comment did).

And interpreting the quote charitably I'm going to have to agree with it - I don't think many of my coworkers care enough to get to the point where they'd appreciate everything something like Haskell can do for them.

Can't say anything about perforce as I've never used it, but I'd give my left nut to get Google's Piper instead of git at work :)

Actually curious - where have they? Zuck's claim didn't seem to be true. I'd imagine a few places that have low technical acumen have tried, but I'll want to see how much they pay for SWEs willing to clean that codebase after they let LLMs run amok on it.

Stubby calls (at least in Java) just use something called a GenericServiceMocker which is akin to a more specialised mockito.

Bit late to the party, but it looks like the author created a "framework" that allows for extremely rapid development of the simplest kind of CRUD app. Everything is fine and dandy as long as nothing needs to change, or if it needs to be changed, then the changer is the author themselves.

I applaud the author for their intellectual pursuit, but I don't think it's fair to compare this to codebases where one does not simply pass the POST request body into the database.

That's not necessarily the case, depending on how their pipeline was set up and what their VCS supports.

For example, you can always `git mv` the Java file to the Kotlin file and only then transform it, which keeps your history.