If you read the next couple of paragraphs, the author addresses this:

> That said, Steam's policy has been recently updated to exclude dev tools used for "efficiency gains", but which are not used to generate content presented to players.

I only quoted the first paragraph, but there is more.

If you squash your PR before merging, then this alternative worked really well for me:

  git fetch --prune && git branch -vv | awk '/: gone]/{print $1}' | xargs git branch -D

Almost identical to mine, but you've got smarter awk use: `git prune origin && git branch -vv | grep 'origin/.*: gone]' | awk '{print $1}' | xargs git branch -D`

I think I probably copied this from Stack Overflow close to a decade ago. Seems like a lot of people have very similar variations.

i was initially confused because i couldn’t find it in the article, but then i found what you quoted here: https://martinfowler.com/articles/expert-generalist.html

Yeah, sorry my head got dizzy I didn't realize I clicked away from the linked article.

Is „Dyehoe“ in the title a typo? Otherwise I don’t get it

It's a pun, look up Alan Dye :)

What I liked about GraphQL was the fact that I only have to add a field in one place (where it belongs in the schema) and then any client can just query it. No more requests from Frontend developers like „Hey, can you also add that field to this endpoint? Then I don’t have to make multiple requests“. It just cuts that discussion short.

I also really liked that you can create a snapshot of the whole schema for integration test purposes, which makes it very easy to detect breaking changes in the API, e.g. if a nullable field becomes not-nullable.

But I also agree with lots of the points of the article. I guess I am just not super in love with REST. In my experience, REST APIs were often quite messy and inconsistent in comparison to GraphQL. But of course that’s only anecdotal evidence.

But the first point is also its demise. I have object A, and want to know something from a related object E. Since I can ask for A-B-C-D-E myself, I just do it, even though the performance or spaghettiness takes a hit. Then ends up with frontend that's tightly coupled to the representation at the time as well, when "in the context of A I also need to know E" could've been a specialized type hiding those details.

> Then ends up with frontend that's tightly coupled to the representation at the time as well, when "in the context of A I also need to know E" could've been a specialized type hiding those details.

GraphQL clients are built to do exactly that, Relay originally and Apollo in the last year, if I’m understanding what you’re saying: any component that touches E doesn’t have to care about how you got to it, fragment masking makes short work

> No more requests from Frontend developers like „Hey, can you also add that field to this endpoint? Then I don’t have to make multiple requests“.

Do people actually work like this is 2025? I mean sure, I guess when you're having entire teams just for frontends and backends then yea, but your average corporate web app development? It's all full stack these days. It's often expected that you can handle both worlds (client and server) and increasingly its even TypeScript "shared universe" when you don't even leave the TS ecosystem (React w/ something like RR plus TS BFF w/ SQL). This last point, where frontend and backend meet, is clearly the way things are going in general. I mean these days React doesn't even beat around the bush and literally tells you to install it with a framework, no more create-react-app, server side rendering is a staple now and server side components are going to be a core concept of React within a few years tops.

Javascript has conquered the client side of the internet, but not the server side. Typescript is going to unify the two.

> It's all full stack these days. It's often expected that you can handle both worlds (client and server)

Full stack is common for simple web apps, where the backend is almost a thin layer over the database.

But a lot of the products I’ve worked with have had backends that are far more complex than something you could expect the front end devs to just jump into and modify.

I think you are misreading the parent comment here.

never used the web app, but never noticed any sluggishness with the desktop app.

now my company „forces“ me to us Microsoft Teams and i’m thinking back to the good old days with Slack.

I run the desktop app also, but since it's just the electron packaged webapp, I expect no real difference between the two.

this maybe? https://liveswebench.ai/

I don't think you really want to boil this down to a number; there's a whole lot of feature and workflow differences to capture:

* BYO model or not

* CLI, UI, VSC-plugin or web

* async/sync

* MCP support

* context size

* indexed or live grep-style search

There's probably like 10 more.

I don't think it's being kept up to date. I believe for the IDEs, it requires manual testing to get the numbers. Since things change so quickly, it's mostly just a historical artifact. Hopefully some future version is automated.

Never heard SWE-agent until now, and seems to beat Aider (the tool I use) consistently.

Does anyone know if it's GitHub-only or can it be used as a CLI (i.e., Aider replacement)?

Heh, the irony doesn't escape me https://github.com/SWE-agent/SWE-agent/tree/v1.1.0/.cursor/r...

Anyway https://github.com/SWE-agent/SWE-agent/blob/v1.1.0/docs/usag... and https://github.com/SWE-agent/SWE-agent/blob/v1.1.0/docs/conf...

looks useful. thanks

If you are curious, here is how you can integrate it into a Jetbrains IDE: https://glyphy.com/a/2022/structural-diff-with-difftastic-an...

I tried it, but unfortunately it's not as seamless as it could be, so I reverted back to Jetbrain's native diffing, which is quite good anyway.