We've known that lines of code were no indication of code quality or developer productivity for well over two decades now -- why would it start to matter now, particularly for those at more senior levels?
You're severely overstating it. The difference between 500 loc and 5000 loc isn't a clear signal of anything. But zero lines of code certainly is. Firing people because the VCS shows they stopped working is common.
I have no stake in the matter. My supposition that some employees simply stopped working comes from my experience seeing similar things happen at other companies during periods of uncertainty, and from my knowledge that quite a few twitter employees were very uncertain about their future with twitter.
Should I be fired?
You can do -100. You can do 100. You can net zero from 100 adds and 100 subtracts (abs=200). But it’s something. If you have long stretches of zero that’s not good.
But I hope they have something productive to show for the other 20 odd days that month they collected their paycheque for…
not everything is committed in a VCS: you have documentation, architecture, RFC etc etc depending on the size of the company and seniority of the employee.
I don’t think it’s an absolute rule that no commits means someone isn’t developing. But it’s probably a reason to have a conversation.
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.
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?
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.
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.