it's also a bad metric? cleanup is nice but # of lines is still not a good measure of good code or even good.. anything. i went a month or more without writing any code because i was just writing docs

You could use lines of docs too. These aren't bad metrics.

They are terrible metrics. To use a worn aphorism: Measuring productivity by lines of code is like measuring progress on an airplane by weight. Obviously using "more weight" as a metric is bad because it will result in a plane that won't fly. Slightly less obviously "less weight" is also a bad metric, because you'll end up with a plane made from paper and twigs where the wings will shear off if you look at it wrong.

You want to aim for a plane with the right weight, but you only know what that is by working out the entire design. Similarly you want to aim for the right number of lines in your code base, but you can only know what that is by working out the entire design.

I never said that more lines = more productive. That is a strawman.

Parent explained in a metaphor how both metrics (more lines, less lines) can be bad.

Maybe engineer A has a easy feature to do. Lots of lines of code but it's smooth sailing. Another engineer, B, has a tricky bug fix to do, which requires him to read documentation, navigate the fode, reproduce the issue, until he published a fix with a handful of lines of code.

Who's the better engineer, A or B?

Even if we consider the average over time, one may be getting more tricky features than other. Or spending time in tasks such as hiring, mentoring, etc, which is worth a lot to companies.

# of lines of codes is a super-valuable metric when used relatively to compare two different things in software.

For example, I worked a .NET project with a central form that had close to 30K lines of code. This was 10x in comparison with anything else in the app. This is clearly a "whale" of a problem.

The lines-of-code comparison made it much easier for non-technical staff to now understand why this "one form" (really dozen of different functions contained in a single form) was troublesome in terms of fixes, enhancements etc. and also why no one wanted to touch it.

They are bad metrics.

Maybe it helps you understand if you think about how easy they are to game. You could just as well create useless lines of documentation as you could create useless lines of code.

Goodhart's law says:

"When a measure becomes a target, it ceases to be a good measure".

By your logic any metric is a bad metric is a bad metric because it can be gamed. In your model of the world good metrics don't exist.

I believe that you maybe misread me, which usually means that I haven't made myself clear enough.

I'm not saying "LoC is a bad metric because it can be gamed". Most metrics can, if you work hard enough.

I'm saying "LoC is a bad metric because it can be gamed by a child within a couple of minutes".

It's the difference between lock made of a tin sheet and a proper heavy-duty steel lock. People like the lockpicking lawyer can still pick the latter, but the former is so weak that it should never be relied upon.

It seems as if the gaming instinct is only at play if LOC is used as a productivity metric.

Avoiding LOC measurement for other (non-productivity) purposes is a mistake.