While you are correct that LOC is not a full measure of productivity, and there are many factors to consider, it would be nonsense to say that merging code has no bearing on productivity. All things equal (and disregarding engineers whose job isn’t coding per se), submitted code is the essential deliverable of a software engineer.

No, “solved problems” is the essential deliverable of a software engineer, and the more senior one gets the less often “submitting code” is the correct path to solving a problem. Someone might submit code based on your work, but there’s no direct correlation between “submitted code” and “did your job” at higher levels.

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.

> We've known that lines of code were no indication of code quality or developer productivity for well over two decades now

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.

Zero code situation is wishful thinking - poster just made it up.

Perhaps an awful lot of people were just working on a stealth no code project.

> wishful thinking

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.

There are people on my team that haven’t committed anything for a couple weeks. I don’t work at Twitter, but wouldn’t be surprised if there were people who basically weren’t working.

I spent the last month prototyping code for a demo that will not be checked in. I have a few small unrelated CLs submitted (minor fixes) but I spent 5 minutes per each, my main work for the month is completely unaccounted for in version control.

Should I be fired?

Yeah your shoddy practices are certainly suspect. Why aren't you using version control to checkpoint your prototype?

For your own sake, you should probably check that demo code in somewhere. Keeping a 'paper' trail of the work you've done is always a good practice to follow.

The true big brain 10x programmer is pushing -100 lines of code per sprint.

I sort of think of the absolute value of lines changed as a pulse.

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.

The true big brained programmer sat in a meeting and prevented a team of 25 people from wasting 6 months.

Sure. That’s super valuable.

But I hope they have something productive to show for the other 20 odd days that month they collected their paycheque for…

At a previous job I had a few months where I managed approximately minus‐1 instruction per week — and it was the best money the company ever spent. Hard constraints are hard.

Sure. But a code review of their checkins will reveal their productivity pretty quick. Any one claiming 10x (or even 0.75x) productivity would want some very good supporting evidence if they have zero activity in the source control for a month. You want some great specification documents or API documentation or platform architecture diagrams or something…

In case this wasn't clear, when I say "no code" I mean no commits, nothing they can point to as evidence of doing any work. Afaic, commits removing code count for at least as much as those adding code. And if they've spent the past month adding documentation to the intranet wiki or something like that, there should be logs they can show to prove it.

is code the only output of an engineer?

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.

That stuff is typically in a VCS.

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.