But yeah, my co-founder has a pretty interesting take on gaming the system.
TL;DR: So, can you game the system? Absolutely. The point is to game the system: https://intercom.help/gitprime/general/cant-you-just-game-th...
Adversarial work does seem like it's largely a sign of communication breakdown. I think 'gaming' isn't always as adversarial as it seems, though. I was considering it in terms of Goodhart's Law, where even with good intentions, representative metrics become less representative as you organize around them. The "active days" entry in your link seems like an example; if everyone pushes most days for the sake of pushing, then active days isn't feedback on programmer skill.
Of course, your link touches on that. "Everyone pushes every day" is a great outcome, even if the metric is no longer clear. The common trend is to pick good metrics, then struggle to keep them relevant. I really like the alternative of just setting metrics that will be good after people optimize.
This is a situation where I feel gaming the system is not an inherently adversarial relationship.
It's one of the only clear-metric breakdowns that actually makes sense in light of my programming experiences. I'm hesitant about the idea of using it as a management tool (easy to game, and high commit count or even 'high impact' isn't proof of quality). And, as some other people noted, it's quite role-specific - a performance engineer's commit count won't be comparable to a line engineer.
But as a personal insight, or a mentoring tip? This seems excellent. I know I want to write good code, I'm not going to game my personal metrics, so a clear guideline like "break up code more" is a great thing to have.