Interesting how some large tech companies roll out tools to track the number of PRs merged per engineer - visible for everyone.

Meta had this for quite a while. Uber rolling it out recently.

There’s no target, but incentivises people to do small and frequent diffs.

Talking with people at most companies, the majority I talk with are fine with it. EMs like it as they have a tool to notice when someone has a change of pace.

When I was at Uber, 80% of performance issues on my team started with someone not landing code for eg weeks.

Also, before this tool was universally available at Uber, better managers manually collected stats on diffs and code reviews, brough it to calibration then used it to get their top people better ratings.

“My engineer did 200 diffs the past 6 months” was hard to argue with…

My point is with a tool it’s all the same ground.

Also, don’t forget the context: these are large companies with thousands of engineers, and a web of dependencies.

This tool incentives small and frequent changes at eg eng1-sr eng + unblocking people who struggle to do these.

Lots of replies assuming this is now a target (when it’s not) or it’s used for perf reviews (def not at Meta; AFAIK zero plans at Uber)

My point is it’s interesting and the goal is clearly to keep small diffs & moving fast top of mind.

It’s important both at Meta & Uber.

One more piece of context: both Facebook and Uber only develop on the main beam w and make extensive use of stacked diffs (which relatively few companies do). This allows breaking large changes into small & easy to review diffs that land at once.

Take it back there’s no target. At Meta there’s none but the way Uber is rolling it out there is a target value for number of diffs per week & number of code reviews/week.

I’m talking with engineers & managers how they feel about this at Uber (feel free to DM if this is you)