But some of the worst experiences I’ve had with coworkers were with those who made programming part of their identity. Every technical disagreement on a PR became a threat to identity or principles, and ceased being about making the right decision in that moment. Identity means: there’s us, and them, and they don’t get it.

‘Programmer’ is much better off as a description of one who does an activity. Not an identity.

There’s simply no advantage to crediting work to someone who’d left the team.

We love to blame those who are misfortunate. It’s called just world syndrome. It’s deeply uncomfortable to realize that this kind of thing is the norm, and justice is the exception. I’ve been extremely fortunate in my career, but not due to any special savviness of my own.

At my workplace now, there’s a senior staff engineer taking credit for work that was done by someone 3 levels below him. And the senior staff engineer still thinks he is not getting enough credit for his work. The senior staff engineer’s manager has been crediting him for the work the less senior engineer had done, since the less senior engineer is no longer at that team, in forums where the less senior engineer has no access to.

The less senior engineer is plenty likeable. As is the senior staff engineer. But the less senior engineer had left that team, and the senior staff engineer and his manager are unscrupulous, and do what they’d like to their advantage.

This is called “just world syndrome.”

Just write a press release and let the tech press publish it. Don't host it yourself. The legalistic language belongs in a filing, not a user-facing blog.

I'm suspecting that once these models hit 'good enough' for ~90% of users and use cases, the providers started optimizing for cost instead of quality, but still benchmark and advertise for quality.

I think for some who are excited about AI programming, they're happy they can build a lot more things. I think for others, they're excited they can build the same amount of things, but with a lot less thinking. The agent and their code reviewers can do the thinking for them.

It's rhetoric. You're making it about manipulation. Should the world consist of bloodless lists of facts without significance or commentary?

The submitter should understand how it works and be able to 'own' and review modifications to it. That's cognitive work submitters ipso facto don't do by offloading the understanding to an LLM. That's the actual hard work reviewers and future programmers have to do instead.

In my mind, they're hardly making any money compared to how much they're spending, and are relying on future modeling and efficiency gains to be able to reduce their costs but are pursuing user growth and engagement almost fully -- the more queries they get, the more data they get, the bigger a data moat they can build.

It's like reading the solution to a math proof instead of proving it yourself. Or writing a summary of a book compared to reading one. The effort towards seeing the design space and choosing a particular solution doesn't exist; you only see the result, not the other ways it could've been. You don't get a feedback loop to learn from either, since that'll be AI generated too.

It's true there's nothing stopping someone from going back and trying to solve it themselves to get the same kind of learning, but learning the bugfix (or whatever change) by studying it once in place just isn't the same.

And things don't work like that in practice any more than things like "we'll add tests later" end up being followed through with with any regularity. If you fix a bug, the next thing for you to do is to fix another bug, or build another feature, write another doc, etc., not dwell on work that was already 'done'.

This really isn't the case from what I've seen. It's that they use Cursor or other code generation tools integrated into their development environment to generate code, and if it's functional and looks from a fuzzy distance like 'good' code (in the 'code in the small' sense), they send an oversized PR, and it's up to the reviewer to actually do the thinking.

I also gave the feedback to my manager that I don't think he's handled this well. I brought up that he's, each time, mentioned another excuse for the difficult engineer. He agreed, and apologized to me. He was sincere, and apologized more than once. Meanwhile, I apologized for bringing this up again.

It's discouraging that he didn't have as many other people talking about the guy to him as they have to me. It makes me think I may just have way more problems with him than me, and that I've overestimated how problematic he is; though I also think the other engineers who've complained about him to me are conflict-averse and wouldn't want to raise this to a manager who may pass it on to the difficult engineer. I was also disappointed that my manager said that he doesn't think it's personal, and that that's just how the difficult engineer is to everyone; it's clear to me that that's not the case since I'm living it first-hand.

It was also hard to get to a concrete, specific, actionable behavior change to request the difficult engineer to commit to. It's easy to say "don't condescend to your teammates". It's hard to say what behaviors that entails.