> a bugfix which takes ages to find and ends up being one or two lines of locally trivial code

I once had a junior engineer who took maybe 4-6 weeks to fix an intermittent bug in dynamic lib loading. When he finally fixed it, the fix was <5 lines of code. But it was obvious that (1) the bug was insanely deep and hard to find, and (2) he did amazing kick-ass debugging to uncover it deep in Linux code. It was great work, and he was one of our top rising talents. But that's not the kind of cases that I'm talking about.

No, it's instead the engineer who gives the appearance that they're always doing tough work, but then the commit history shows that they're simply not. The person who says they're implementing a new data structure in the code, but really then take a month to replace a list with a dict in python, or whatever. This happens.

> a senior who spends most of their day unblocking junior devs and keeping the team on track: 0 lines of code

I'm not talking about them at all. I'm talking about people who aren't doing mentoring, advising, architecture, forward-looking design docs, etc.

> overzealous code formatters: lots of lines of code. A junior writing an overly complicated mess of a solution to a problem that could be solved much more simply: ungodly amounts of code

Yup, this happens. This is also something managers will learn by looking at code.

- a developer talking to the client directly and finding out that problem that they're trying to solve is already solved by the product in a way that the client didn't think of, rather than immediately wasting company resources on a feature that's ultimately unnecessary (0 lines of code over lots of lines of code)

Absolutely. The best way to get more work done is to figure out what work you don't have to do.

But if you have an engineer on your team make $200+K/year and they're not writing much code, nor writing design docs, nor advising other engineers, nor guiding the technical strategy, etc... if all the engineer does all day is "not wasting company resources" by doing very little whatsoever, you have a problem on your hands.

All you're doing is affirming the antecedent.

> There is 0 correlation, none whatsoever

This is quite unlikely to be true. No correlation at all?

Especially if we shift to ΔSLOC rather than +SLOC, I don't believe that for a second.

You've made a good case that it's a bad proxy for productivity. It is. But there's no need to over-egg the pudding.

I think it'd help to go over what the word correlation means, and then go over the examples again, and then look at the claim that there's a correlation between the value a dev provides and lines of code.