[650]

Meta, and other large companies have been encouraging PMs to code, while I've seen many negative responses from engineers having to code review, debug, deal with production issues, etc. stemming from crappy code they don't understand. Metrics and KPIs are being gamed into stupid incentives like lines of code, commits, and tickets closed. Leadership claims they are aware of Goodhart's Law, but their actions show otherwise.

Overall the rise of business types in tech company leadership has led to a drop in engineering quality, a rise in short term metrics, and fiascos like the COVID overhiring into multiple rounds of layoffs.

[purrcat259]

An easy correction is to only merge PRs from folks who are on the on call rota.

Those not on rota can either join or have their PR receive heavy scrutiny

[carschno]

There are various technical corrections, with arguable pros and cons. However, they do not match the underlying problem stated above:

> the rise of business types in tech company leadership

[justonceokay]

The fact that they are PMs is a tragedy of circumstance, not a moral failing. If they are willing to go on-call for their work they will lose that childlike innocence and become engineers very quickly.

[steve1977]

> they will lose that childlike innocence and become engineers very quickly.

I don't think so. Not everyone has an engineer mindset (or a PM mindset, for that matter). There's a reason these people ended up where they ended up.

[badgersnake]

Nah, the rota is large enough that it will likely be somebody else’s problem anyway and the chances are even if it does land on them they just won’t answer the phone.

Punishing mistakes with unpaid overtime has never been a good approach to quality. It just teaches management that they can get away with low quality because the engineers will pick up the pieces in their own time.

[gray_-_wolf]

> unpaid overtime

Through European lenses this part seems insane. It is work, so pay me for it :) Every oncall rotation I was part of ever was paid, is the "unpaid" part a US thing, or was I just lucky?

[titanomachy]

Working as a SWE at Meta in the US pays 3-5x more than a European tech job (outside of Switzerland). They are paid for it.

Paid oncall in US big tech is the exception rather than the norm (notably, Google has paid oncall)

[gzread]

How does it work out with cost of living?

[titanomachy]

This is of course a complicated question. The US has many tax jurisdictions and widely variable cost of living, and jobs vary a lot. But I could compare, say, a Google engineer in Paris vs Seattle.

A Google senior software engineer in Paris earns €168k per year (according to levels.fyi) and takes home €96k after a 43% effective tax rate. A Google senior engineer in Seattle earns €336k and takes home €239k after 29% taxes, a 2.5x increase in take-home pay. According to Numbeo, cost of living in Seattle is 15-25% higher.

Of course, in America you have to fund your own retirement. As long as the pensions plans remain solvent, "savings" are a lot less important in Europe.

Anecdotally, I know people who were able to opt out of working altogether after 10-15 years in a large tech company in the US. I don't think this is common in Europe.

[closewith]

Unpaid overtime is common across the continent for salaried positions. There's only a handful of jurisdictions where it's not the norm.

[bravetraveler]

In the US it's common to either negotiate 'differential' pay for the responsibility, or as one might see in this thread, get suckered into it for free.

[snypher]

I think they meant to say that if the person isn't on the A-team call list, they aren't entitled to contribute without scrutiny.

[pwagland]

This "receive heavy scrutiny" is part of the problem that is raised in the article though:

> You are friends with all the senior TLs, so can get them to review your code, but this is not a high-leverage use of time.

And then, tying back to ops comment, the engineer gets pinged for their bad metric, because of this additional review.

[duskdozer]

If 24/7 availability is required, the company should simply hire someone to work those hours, perhaps in a different timezone if needed. Many mistakes are going to be the result of management pressures to "ship" too quickly, incentivizing cutting corners, which someone will have to deal with at some point, even if it's during their regular working hours.

[dmckinno]

Funny story: I work at Meta and posted a version of this internally in response the bizarre pressure and support for PMs landing prod diffs (the response was very positive FWIW).

[medi8r]

Quick everyone, create decoy repos for them to vibe in. When the feature doesn't appear "oh feature gate system has an incident try tomorrow". Even better make the decoy repo have an insufferable pipeline that always breaks and get them in a loop trying to fix it. An adveserial "red team" LLM can keep it broken! But tantalizingly with different problems so progress is felt.

[ivantop]

which workplace group did you post it to?

[dmckinno]

I don't remember the exact name, but the one about AI productivity. It should be trivial to find my name from my handle, so just look at my profile.

[game_the0ry]

> Leadership claims they are aware of Goodhart's Law, but their actions show otherwise.

Leadership will cherry pick metrics that are easy to game so they can make the next promo, and do say at the expense of company resources. This is a problem in every big corp not just tech.

[theshrike79]

We're solving this with two different tracks for Vibed stuff and Actual Code.

Vibed stuff can do whatever it wants, with some basic CI checks and Agent instructions

BUT if any of that crosses specific thresholds (writes to dangerous APIs, reads from unvetted sources, is deployed on the public internet), an actual developer MUST review the code - with the associated costs billed to the creator's BU.

Works fine, zero projects have been made public yet, but we have a bunch of Vibed internal tools in use that can't be accessed outside our internal network (or VPN) that are actually helping people do their work more efficiently.

[mountainriver]

Good business types can massively improve a tech company. The issue is there aren’t many good ones