Nope.

Pair programming still results in a code change needing review from another party (or you get increasingly buggy code because the two people have already prejudiced each other during design, discussion and implementation).

Just like "advanced metrics" in team sports (eg. two person lineups in NBA: they can tell you how effective were all lineups with eg. Jokic and Gordon in Nuggets been), nothing would stop management from looking at which person has led to a pair being most effective.

Still, that's beside the point: the goal of metrics is not to judge individual performance (even if it is a signal somewhat), but to be able to tell if we are improving (which you can only do through measurement). I invite you to come up with better metrics which can tell you if you are doing better or not in 3 months time.

If you believe you are being judged on artificial metrics, it's simple: push smaller commits and create smaller tickets. That will make management happy and will make you faster.

the key idea of this seems to be:

> if developers collectively insisted on pair programming [...] they could effectively shield themselves from individual metric tracking. Because there would be no such thing as individual programming effort.

This does not follow. Today, if management wants to measure productivity, they'll see how many points per sprint (or features per month etc..) does programmer do. In pair programming, they could do exactly the same, but only adding half of total ticket's points to each of participants.

This means misguided managers would still be able to calculate per-person points, and harass people if they are not doing enough. But now there will be a new reality: working with slower person means your own performance also decreases. Choosing a pair will be a strategic game, lest you face the management's wraith. But on the other hand, people who are not very fast would be able to scrape by, as long as they are paired with fast performer often enough.