sometimes the most senior engineers don't ship a ton of code to prod, but they should certainly be writing code to figure out where the organization should go, justify the ROI of their ideas, demonstrate a large-scale problem that needs resources mustered, interrogate business logic databases to tie disparate ideas together, understanding the scale and frequency of large scale problems, and so on. If you're a senior engineer and can't point to any code you've written in the past 3 months, maybe you're not really an engineer, because you're not using engineering to solve problems.

I think a lot of software engineers get too comfortable with the idea that meetings are deliverables - they aren't; meetings are coordination and planning. if nobody completes the work that was coordinated and planned, the meeting was nothing but a waste of time. Depending on your seniority as an engineer, you may have written code to decide that the work should be done, or you may be tasked with writing code to carry out the plan. If you're an engineer and you're not writing code on either side of meetings, you should dig deep and figure out why.

But you’re describing exactly what I mentioned above: engineers whose job is not code, per se. Yes, the super-senior engineer who cracks down on bad code by others and sets the right path, etc, is very valuable even if they’re not directly coding themselves. I’m talking about the engineers who are directly responsible for implementing features and fixing bugs. I.e., most software engineers.

Sometimes a great engineer spends a month tracking down a 3-line fix, and that’s just what happens with complex software. But by and large, if an engineer averages only a few LOC a month (and I’ve unfortunately seen this way too many times) then we probably have a problem on our hands.

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 in commits. A large amount of the actual heavy-lifting value-add of an actually senior engineer is not in the code they’re writing.

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 the end of the month/quarter/Musk Layoff Review Period when these kinds of days are relatively common?

All that, in theory, would be tracked. The senior engineer would be able to point to the PRs/MRs with all the helpful comments that led to the code improvements. It wouldn't be hard to show calendar invites or whatever for pair programming sessions, which could be corroborated by asking the junior as well.

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.