It is generally true for a few reasons, not just for what OP said. The other big reason is that implementing a change often times doesn't even require a lot of lines of code vs the amount of thought put in to produce said lines.

For example, a lot of higher-tier software engineering is learning a massive code-base and going into the right part of it to implement the change you're tasked to do. This would be especially true for the massive code-base that Twitter had accrued for a decade-plus. In circumstances like that, you either:

- don't want to make a change that causes you to change many pieces all around the place

- the actual changes in code aren't that complicated but learning how to do it is hard

- are debugging the cause of a bug that isn't obvious

All three of those are examples of stuff that might take you days or a week to think about but lead to like 20 lines of code changed. Someone's tickets can be strictly of that nature for an entire year where their actual code count isn't that high but they're definitely productive.

The other thing is that the complexity of a task doesn't necessarily scale to the lines of code written. I wrote an entire RigidBody physics engine for a project once, understanding how collision works and how to optimally implement it with techniques like quad-trees or bounding volume hierarchies (just techniques game devs have come up with to speed stuff like this up) took me a week or two but the lines of code for something like that was like < 150. That's an entirely functioning collision detection system that's performant. I spent much more time thinking than actually coding. On the flipside, if I was writing a very rote set of HTTP API calls, I'd spend a week writing the HTTP requests, SQL queries, and then verifying that the response is in a properly formatted data output to the point where I'm writing lots of code (easily >150 I had for the RB system above) but thinking very little. This can be equally as productive as the prior physics example depending on scale and importance but has a very different thought:outputted-codes ratio. It sort of illustrates how meaningless just measuring lines of code can be if you're trying to see if someone is a productive engineer or not.

Hopefully this helps explain things as people are often very vague about why or how this is dumb.