Earlier quoted context omitted.
The question is who’s writing the code. A core part of a senior engineer’s job is helping to train and mentor junior engineers; it’s not unusual for an entire project to be designed and led by a senior engineer and implemented by more junior engineers. Design reviews don’t result in commits, deep dives on technical implementations don’t result in commits, negotiating an architecture change between groups don’t result…
This. Spending a productive, rewarding half a day pair programming with a receptive junior engineer who isn't sure how to approach a complex task nets them 1+ commits and you 0 commits. Spending half a day chasing after a "loose cannon" engineer who hastily committed bad code nets them 3 commits (the original bad commit, a rollback commit, and the fixed commit) and you 0 commits. How do the individual stats look at t…
It does, however, bring up the point that one should always be mindful of what their output looks like and how easy it is to prove. I'm sure everyone has worked with a 'meeting commando', who loves to discuss edge cases and bikeshed instead of shipping code. Maybe they've carved out a nice niche doing so, and have convinced others in the company of their (dubious) value, but it shouldn't be surprising when the company is sold/acquired/RIFd that someone else might expect someone with an engineering title to have more tangible contributions to point to.