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.
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.
> But there is a correlation between output and LoC.
That is less true today than it ever has been, due to LLMs.
It truly does:
performance – the action of entertaining other people by dancing, singing, acting, or peformative coding
The problem is, that shouldn't matter. If you work somewhere it does, well, you probably have to. But that's OK, it doesn't stop you from working to uplift the goal and conversation and deliverables, through these other definitions of performance:
performance – how well a person, machine, etc. does an activity
Now we get into how to define well, but activity, looking busy, may not be as valuable as outcomes.
performance – how well a person, machine, etc. does a piece of work
This is getting close, but here we need to define the nature of work, the qualia of work. It's not how well someone codes a line of code, or how well someone programs a piece of software. It's not even how well the engineer a solution.
What matters is return on equity, meaning: how well does what is delivered enable the business to turn capital investment in bringing ideas into being, into returns on that capital.
For good measure (pun intended), track long term, so resilience, maintainability, and evolvability, and really any ongoing costs, including delay costs, opportunity costs, or cash flow costs, are part of the definition of how well.
That matters.
Note this can be shorthanded to both GPT and Claude, and will change the machines’ suggestions.
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.
> if you're trying to use sloc as a proxy for productivity in any way, shape or form you've already lost the game.
in fact, i've sent over 20 variable rename prs and am now topping the leaderboard!
• sloc = Source Lines of Code
.. so I suppose nloc would mean Net LoC
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.
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.
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.
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.
What would you keep from this?
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.
So overall increases productivity by a lot
How is that not efficient?
The library was a masterpiece of what if driven development. It was about 50k LoC, and it had 300k LoC of dependencies. It was a nightmare to modify. And no one wanted to take over maintenance so people would submit PRs to the former employee when they did modify it.
I wanted to change something in the library to support a large migration I was in charge of. When I went digging it turned out that we were barely using any of the features in the 2 years since he’d finished it. I replaced the 50k LoC library and 300k LoC of dependencies with 300 lines in less time than it would have taken me to modify the library (a few days).
Yes.
> That doesn't sound effective that sounds like digging ditches to fill them.
It sounds effective to me, like removing garbage from sidewalks so people can walk straight instead of walking around the trash.
> Every line of code removed is a line that was previously added.
Correct. Today I cleaned up
if (a || b)
return true;
if (c)
return true;
if (d)
return true;
return false;
return a || b || c || d;
Every line of code removed is a line that was previously added.
Do you have any experience coding before LLMs?
But, if that original code had comments and traceability of each condition and return to a specific domain scenario, you would be doing a disservice by collapsing it to the one flat boolean expression. In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.
If there were comments for each conditional, it should still be refactored as
return a || b // comment 1
|| c // comment 2
// long comment 3
// on multiple lines
|| d;
> In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.
This is nonsense. This optimization is not about compiler optimization for efficiency. It's an optimization for human readability and maintainability.
Such branches could make sense if the conditions have to do with underlying domain concepts, but you expect the outcomes to be revised. It could just be a moment-in-time accident that they are all returning True right now.
This kind of tension is also where you often see indirection via configuration files or other auxiliary data structures. Or in the old days, things like bit fields instead of booleans, so that merging the conditions would encode different small integers to use as lookup table indices.
There's an obvious answer of course. And that is the direction that these effective senior engineers move towards.