| HN Mirror

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 8 days ago

"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.

Good revision!

ecshafer 8 days ago

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.

This is exactly what the article is addressing:

> But there is a correlation between output and LoC.

That is less true today than it ever has been, due to LLMs.

dlahoda 8 days ago

They could just use AI to communicate. Why they they still on meetings?

dakiol 8 days ago

"High performers". Can't believe we have normalized this vocabulary, among us, "hackers".

therealdrag0 8 days ago

Most of us work for business and on teams where performance matters.

Terretta 4 days ago

> Most of us work for business and on teams where performance matters.

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.

blindhippo 8 days ago

Dunno about you but I work for a "business" (large company, you've heard of it) and the concept of "High Performer" is synonymous with "best politician". Sure, a lot of theater goes into things, especially dances around "data points", but at the end of the day the top tier goes to the fortunate sons.

SideburnsOfDoom 8 days ago

You should not treat it as fact that "performance" of an individual, not a team is a thing that actually exists in any way that matters and is measurable.

therealdrag0 7 days ago

I do treat it as a fact. Why shouldn’t I? Varying performance among my coworkers is obvious and blatant.

oompydoompy74 8 days ago

I’m not sure that there is a consistent definition for matters in this context. What matters is completely subjective to an individual. Furthermore, performance is rarely correlated with success and compensation in an enterprise. I could just as easily say that playing the game is what matters.

pydry 8 days ago

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.

andrekandre 8 days ago

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

YES! this is exactly why at $work we have moved from loc to number of pr's per week!

in fact, i've sent over 20 variable rename prs and am now topping the leaderboard!

SwtCyber 8 days ago

Good code is absent code LLMs by nature work like autocomplete on steroids. They're always trying to write more than necessary to please the prompt. Seniority now is measured by the ability to break down a task so that the agent doesn't even think to drag in unnecessary abstractions

QuantumGood 8 days ago

• LoC/LOC = Lines of Code

• sloc = Source Lines of Code

.. so I suppose nloc would mean Net LoC

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.

sarchertech 8 days ago

We had a library written by a former employee who was a prolific producer of code. He insisted we needed it and spent over a year developing it in company time.

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).

agentultra 8 days ago

Every line of code is a liability. A potential security breach. An error waiting to corrupt customer data. A maintenance burden.

banannaise 8 days ago

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 8 days ago

Rewriting code to be more compact is orthogonal to productivity.

tauroid 8 days ago

In a similar way to how a radial burn (https://space.stackexchange.com/questions/44608/what-happens...) may be orthogonal to your trajectory but still may be necessary to avoid becoming a fireball in half an orbit's time.

e12e 8 days ago

How so? Let's say that over a year, a given section of code needs to be read and understood once a month. Taking some time to keep the code succinct and free of distraction will increase productivity all those occasions, as well as the rest of the lifetime of the system. Say the next decade.

How is that not efficient?

jtbayly 8 days ago

Which is not what is being discussed. Often rewriting code to make it more understandable makes everybody more productive.

risyachka 8 days ago

Simplification usually requires the most effort and results in simple and elegant systems easy to understand and maintain with reduced error surface.

So overall increases productivity by a lot

bryanrasmussen 8 days ago

you have evidently been blessed to work only in places with acceptable level of quality code and above.

LtWorf 8 days ago

Or he's the one bringing down quality and productivity.

dijksterhuis 8 days ago

non-coding manager spotted

gitremote 8 days ago

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

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;

and contributed various other negative lines of code in multiple areas.

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

Do you have any experience coding before LLMs?

saltcured 8 days ago

Written exactly like that, yours is obviously cleaner.

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.

gitremote 8 days ago

There were no comments.

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;

Many years ago, "lines of code" was the classic example of nonsense management metrics. Today, there are somehow HN users who argue that lines of code is indeed a good metric and ask "But what if the code had comments?" as if they have never seen comments interleaved with code.

> 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.

saltcured 8 days ago

FWIW, I'm no advocate of "lines of code", or really any KPIs at all. All I'm saying is context matters.

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.

nedt 7 days ago

That's still going to make it hard to read. I'd have one big comment above talking about the different cases and then one line of code. Even with the slightly higher risk of getting code and comment out of sync. But that context switch between code and comments you need when you read this one return are pretty awful.

Right, and do you spend so much of your time doing that your net LoC is negative? If that's the case it implies people are writing code only for other programmers to clean it up. Programmers solving a problem created by programmers. That's dysfunctional. Effective engineering as I see it would be putting the processes in place to prevent having to constantly rewrite code.

georgemcbay 8 days ago

> 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.

> 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 8 days ago

> 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.

whattheheckheck 8 days ago

Old guard status games be like

overfeed 8 days ago

> 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.

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

gf000 8 days ago

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?

overfeed 8 days ago

It's only a failure if perfect information was available at the time, an impossibility for most people.

e12e 8 days ago

Write one (system) to throw away...

nedt 7 days ago

It's all about YAGNI. Programmers try to be smart covering cases no one thought about, reviewer is happy that corner cases have been implemented, artificial tests report all good. But it's just more to read when you have to change the code.

fifilura 8 days ago

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.

FuckButtons 8 days ago

… by some fool who didn’t know what they were doing, since evidently the same behavior could be done with less.

Thought experiment: if you can solve a problem with 100 lines of dependency free code, or with 10,000 lines of code that depends on hundreds of things - which is better?

There's an obvious answer of course. And that is the direction that these effective senior engineers move towards.

dlahoda 8 days ago

Numbers feels like outliers.

LtWorf 8 days ago

Not everybody is good at their job, or requirements changed over time.

BerislavLopac 7 days ago

Deleted code is debugged code.

thisisit 8 days ago

There are also people who think AI is magic. I have often heard - "we want to use AI to automate processes but we don't have full documentation about the processes, we hope AI can help". Despite being told that no one can create outputs from thin air - every AI topic turns into the same discussion.

Often the solution to create those document to feed into these AI automations? Use AI. Its like ouroboros. Create docs using AI, then summarize and ingest using AI, explained by AI.

Same thing is going to happen with code. Create 1000s of line of code using AI. Then explain it using AI etc.

8note 7 days ago

a process of

1. add tools to be able to do the job 2. work through the process using the agent interactively many times 3. have an llm read back through the session histories to create the full agent definition 4. run it and review

works fairly well, and does use llms for most of the steps

giancarlostoro 8 days ago

> It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around.

It's okay, I'm sure the algorithm questions during the interview phase totally weeded out the fakers of systems knowledge right?

golly_ned 8 days ago

I've even seen AI-generated roadmap documents that promise the world, are broadcasted to director+, who sign off without a thought.

Words and code are so cheap they're meaningless, while human focus, attention, and understanding are so expensive and overloaded.

blensor 8 days ago

Maybe the solution is to look out for the most silent engineers. Those that output less despite having the ability to create near infinite output.

AStrangeMorrow 8 days ago

Not sure how to understand that. You mean as the best engineers?

Funnily at my company, the few engineer that did the majority of the work before AI still do the majority of the work now. By majority I mean tackling both more issues and better.

However there is a general verboseness and over engineering trend across the board.

blensor 8 days ago

Kind of yes. The person who does not spam the messages.

What I noticed for myself is that saying no to something is becoming harder by the day because, why wouldn't you try something if it's so cheap to do.

That makes having the strength to say no almost a quality in and of itself.

That is true both for external pressure and internal pressure.

LtWorf 7 days ago

Saying "no" as in "this makes no sense" is not the same as "give it to another team". The first can be an engineering take while the second is just politics.

sph 8 days ago

"I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage."

— Kurt von Hammerstein-Equord

These days it is so easy to appear hardworking (by volume of contributions) when you have LLMs. The difference is that the inept now can literally create orders of magnitude more than the careful, experienced engineer.

Arthurian 8 days ago

The under-performers and coasters just don’t read their code, in my experience thus far it’s been pretty transparent. PRs aren’t a perfect gate, but they’re one of the only ones we have right now, and it’s pretty clear who’s putting in the effort and who isn’t.

beezlewax 8 days ago

How is it clear though? It can be really hard to tell.

tonyedgecombe 7 days ago

Surely the harder it is to tell the less of a problem the whole thing is.

Quothling 8 days ago

I think it depends a little on how and where you work. In the energy industry of Europe where we are extremely regulated AI has been writing some excellent and maintainable code. Of course we can't do any of that CLEAN SOLID DRY stuff, or any abstraction and implicity really, and I imagine that AI would struggle with that. Though you have to wonder if any of those religions ever really worked when you consider that they've still failed to replace most COBOL systems 30 years later. Anyway, that's a different discussion and even Uncle Bob has moved on to functional programming.

I've yet to have Opus 4.8 fail me with defensive explict code. Often it'll write code that is better than what I might have done. I imagine it would be a nightmare to go through one of the OOP debug chains with implict error handling, but when every function has a runtime assertion which is basically the contract for how it is supposed to work and exactly what to do if it encounters a corrupt state, then things are just so much easier with AI.

I do agree with you on documentation. The amount we have has exploded in the post AI world. Which is a little ironic since the assertion is frankly what you'll need to know and not the 10 pages of prose the AI autogenerated in the shared loop (microsoft's terrible confluence). It is what it is though, and at least it's easier to meet EU compliance rules now, since those are more about the bureaucracy than actual security.

tonyedgecombe 7 days ago

>at least it's easier to meet EU compliance rules now

Until the bureaucrats start using AI to create a flood of new rules.

xnx 7 days ago

> the fallout from this phase of the industry is going to be an exotic form of technical debt

This is a common sentiment and possibly motivated by the belief that writing "clean" code was right all along. Even odds that an AI 2 major model versions smarter will be able to eliminate that debt or rewrite from specs derived from the codebase.

protocolture 8 days ago

>I have a feeling that the fallout from this phase of the industry is going to be an exotic form of technical debt that is remarkable mostly in its enormity.

This.

I feel like it is going to become illegal for older engineers to retire until its all cleaned up. When the debt catches up its going to be civilisation level problem, like asbestos or lead.

aakresearch 8 days ago

> like asbestos or lead

Perfect framing! I was leaning towards "AI Chernobyl" analogy in my predictions, but I think "asbestos" or "fossil fuels" captures its nature much better. May I borrow it? I definitely see the harmful consequences of "AI" exceeding both, however with sad realization that it usefulness was absolutely below par with any.

tracerbulletx 8 days ago

I've been thinking about the manga Blame! a lot recently, where the entire story takes place in a run away machine built mega structure that is larger than at least the solar system.

roncesvalles 8 days ago

>This is mostly due to incredible pressure from the C-level for every engineer to be using as much AI as possible

I think this is an important point. Software engineers always had the right instincts on how to approach AI for coding -- cautiously. Execs got too coked up on LinkedIn puff pieces from nobodies and adver-prophesizing CEOs selling their tokens and chips that they forced something unnatural upon their orgs.

Now what we see in the software dev space is incredible levels of malicious compliance ("you want slop, I'll give you slop").

mplanchard 8 days ago

I don’t know. I mean, I agree with you overall, but it seems like tons of engineers, especially here on HN, have been more than willing to go all-in on AI for at least the past year, with many dire warnings of “coding is a solved problem,” “if you’re not programming swarms of agents, you’re going to be left behind,” and so on.

This has not been my experience with my fellow engineers IRL on average, but I do feel like there is a significant contingent of us who are ready and raring to yield engineering in its entirety to the LLMs.

roncesvalles 8 days ago

A lot of people who write code aren't professional SWEs. A lot of professional SWEs especially on Blind aren't typical SWEs at typical companies. A lot of people who claim to write code are lying. I mean would you take Gary Tan as a valid datapoint for how effective AI is at professional SWE coding? I wouldn't. But these are the kind of people who shill it the most on HN.

Also, I suspect that a lot of HN comments that generally state that AI has been useful for their work are actually not referring to programming work, but it's very easy to default interpret it that way. For example, I just recently saw a comment stating how AI can do 90% of their senior-level job, and when I looked into the guy's profile, he was actually a designer, which makes sense. But on first read I assumed the comment was referring to writing code.

LtWorf 7 days ago

There's also a lot of people whose jobs involve sitting in 3 hours meeting to decide where to add another textbox to the website, and that will then create a ticket to create the textbox, have a meeting to estimate the creation of the textbox, have several meetings with the design team about the placement and size of the textbox.

Some teams are incredibly inefficient. And in the end the AI is perfectly capable of creating the textbox.

contravariant 8 days ago

You'll recognise the good engineers as the ones that remove code.

da-x 8 days ago

I bet code removal is _not_ something that goes into LLM training sets much, unfortunately

hintymad 8 days ago

Eh, are you using the loop engineering effectively? Remember, Boris can merge more than 200 PRs a week mostly with merely a phone and despite his busy schedule. Anthropic engineers do not write code manually any more, and they don't need to review most of the code either.

In all seriousness, though, I'm indeed curious about Anthropic's engineering practice, particular how they can achieve such level of autonomy.

youknownothing 8 days ago

Remember Facebook's original motto: Go fast and break things. That's where the speed is coming from.

Anthropic's speed of development is about 20% AI and 80% technical debt. We all could be faster if we stopped trying to build things right.

Once Anthropic floats, I predict a screeching halt in feature development to fix all the technical debt that they're accumulating.

j45 8 days ago

AI usage perhaps will have to be monitored by AI.

saltcured 8 days ago

This game-theory phase seems to go hand-in-hand with totally myopic grift/gig/hustle thinking too. There is no product but the confidence act needed to win each moment.

Chalk up yet another echo of the 1920s Gilded Age? Between all these economic spasms and the simultaneous tilting towards fascism, I think there is way too much historical rhyming going on right now...

budsniffer952 8 days ago

So, in other words, all the "awesome engineers" can't really tell good code from bad unless it's really obvious? Why should we listen to you about AI code being crap, then? Maybe, in the end, you don't really know. Maybe AI is better at it than you?

jasonlotito 8 days ago

No. Your AI tool that summarized the comment did you dirty. The key here was this:

> perfect formatting and at least superficial plausibility

Basically, a library full of books that have nice covers is going to take time to see that all those books are just filled with ipsum lorem. Before, they coudln't stand up a fake library.

The issue comes down to time and effort.

skydhash 8 days ago

> Basically, a library full of books that have nice covers is going to take time to see that all those books are just filled with ipsum lorem

Worse if it’s a mixture of good content and ipsum lorem.