I'm sure this is gated by where you work (especially by how technically savvy your manager is), but the most effective contributors at my job tend to be the ones with near-zero (or sub-zero!) net LoC.

LLMs are prolific and they love to add shit. Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts.

▲

tj-teej 21 minutes ago | parent | next [-]

"Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts"

I'd simplify to "Truly capable engineers are able to achieve more positive outcomes" - half of what makes a capable, dependable engineer is knowing what outcomes are needed and making them happen.

▲

ecshafer 42 minutes ago | parent | prev | next [-]

I really can't agree with this. Sure pure LoC is a bad metric. But there is a correlation between output and LoC. Outside of a very senior developer, maybe a Principal or Lead that is spending all day in architecture meetings and reviewing PRs, most high performers are also outputting code.

▲

4lx87 2 hours ago | parent | prev | next [-]

The most effective contributors at your job remove more code than they add? That doesn't sound effective that sounds like digging ditches to fill them. Every line of code removed is a line that was previously added.

▲

banannaise an hour ago | parent | next [-]

Turning inefficient, unreadable code into efficient, readable code often results in an overall reduction in LoC.

High-quality code and high-volume code are highly anti-correlated. Incidentally, low-quality code that is excessively long just so happens to be common complaint with AI-generated code.

▲

hhjinks an hour ago | parent [-]

Rewriting code to be more compact is orthogonal to productivity.

	▲	jtbayly 37 minutes ago \| parent [-]
		Which is not what is being discussed. Often rewriting code to make it more understandable makes everybody more productive.

▲

fifilura 2 hours ago | parent | prev | next [-]

I definitely agree with the GP, and the point is that most often someone else (or an LLM) added all those LOC that are removed to make the system sensible.

▲

overfeed 2 hours ago | parent | prev | next [-]

> The most effective contributors at your job remove more code than they add

Perhaps they tackle non-code-editing tasks like architecture, design, mentoring and code review (think staff and principal tasks)

> Every line of code removed is a line that was previously added

Yes. This os not a failure. Code has a surprisingly short half-life.

▲

4lx87 an hour ago | parent [-]

It’s not a failure that resources were spent writing code that was not needed?

	▲	gf000 an hour ago \| parent [-]
		Maybe it was temporarily needed, but the assumptions around it has changed and now it's unneeded. Then people built on top of that not understanding that they could simplify the whole system, and only later was that option discovered. What would you keep from this?

▲

georgemcbay 2 hours ago | parent | prev [-]

> That doesn't sound effective that sounds like digging ditches to fill them. Every line of code removed is a line that was previously added.

Because they were added doesn't mean they were needed and even if the same person added and then removed them, it doesn't mean they are digging ditches to fill them.

The idea that "I would have written a shorter letter, but I did not have the time" also applies to code, and sometimes later you are blessed with more time than you had when implementing something under deadline pressure.

▲

4lx87 an hour ago | parent [-]

> Because they were added doesn't mean they were needed and even if the same person added and then removed them, it doesn't mean they are digging ditches to fill them.

Huh? If LoC weren't needed then adding them was unnecessary and a waste of time. Someone who is known at an organization for removing unnecessary code screams inefficiency to me. It's paying one person to create a mess then another to clean it up.

	▲	georgemcbay an hour ago \| parent [-]
		> Huh? If they weren't needed then adding them was unnecessary and a waste of time. My previous reply already addressed this? I can't help but think you are being purposefully obtuse if you can't acknowledge the concept of developers creating known (and hopefully temporary) technical debt due to various forms of deadline related time pressure or changing requirements.

▲

pydry 2 hours ago | parent | prev | next [-]

if you're trying to use sloc as a proxy for productivity in any way, shape or form you've already lost the game.

i tend to find that the most productive teams make better decisions and work fewer hours. the quality of decisions is such a huge force multiplier that it renders actual hours worked almost an irrelevant variable.

▲

QuantumGood an hour ago | parent | prev | next [-]

• LoC/LOC = Lines of Code

• sloc = Source Lines of Code

.. so I suppose nloc would mean Net LoC

▲

ihsw 44 minutes ago | parent | prev [-]

[dead]