4 ms·

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 one

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.

4lx87 4mo ago
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.
- fifilura 4mo 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.
- georgemcbay 4mo 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.
  - 4lx87 4mo ago
    > 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 4mo 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 4mo ago
        Old guard status games be like
- overfeed 4mo 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.
  - 4lx87 4mo ago
    It’s not a failure that resources were spent writing code that was not needed?
    - gf000 4mo 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 4mo ago
      It's only a failure if perfect information was available at the time, an impossibility for most people.
    - e12e 4mo ago
      Write one (system) to throw away...
- banannaise 4mo 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 4mo ago
    Rewriting code to be more compact is orthogonal to productivity.
    - jtbayly 4mo ago
      Which is not what is being discussed. Often rewriting code to make it more understandable makes everybody more productive.
    - tauroid 4mo ago
      In a similar way to how a radial burn (https://space.stackexchange.com/questions/44608/what-happens-to-orbit-after-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.
    - bryanrasmussen 4mo ago
      you have evidently been blessed to work only in places with acceptable level of quality code and above.
      - LtWorf 4mo ago
        Or he's the one bringing down quality and productivity.
    - risyachka 4mo 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
- sarchertech 4mo 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 4mo ago
    Every line of code is a liability. A potential security breach. An error waiting to corrupt customer data. A maintenance burden.
- FuckButtons 4mo ago
  … by some fool who didn’t know what they were doing, since evidently the same behavior could be done with less.
- gitremote 4mo 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; to 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 4mo 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 4mo 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 4mo 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.
- strix_varius 4mo ago
  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 4mo ago
    Numbers feels like outliers.
- LtWorf 4mo ago
  Not everybody is good at their job, or requirements changed over time.
- nedt 4mo 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.
- BerislavLopac 4mo ago
  Deleted code is debugged code.
pydry 4mo 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 4mo 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!
QuantumGood 4mo ago
• LoC/LOC = Lines of Code • sloc = Source Lines of Code .. so I suppose nloc would mean Net LoC
ihsw 4mo ago
[dead]
ecshafer 4mo 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.
- strix_varius 4mo ago
  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.
- dakiol 4mo ago
  "High performers". Can't believe we have normalized this vocabulary, among us, "hackers".
  - therealdrag0 4mo ago
    Most of us work for business and on teams where performance matters.
    - oompydoompy74 4mo 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.
    - blindhippo 4mo 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 4mo ago
tj-teej 4mo 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.
- strix_varius 4mo ago
  Good revision!
SwtCyber 4mo 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

4lx87 4mo ago

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.

fifilura 4mo 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.
georgemcbay 4mo 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.
- 4lx87 4mo ago
  > 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 4mo 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 4mo ago
      Old guard status games be like
overfeed 4mo 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.
- 4lx87 4mo ago
  It’s not a failure that resources were spent writing code that was not needed?
  - gf000 4mo 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 4mo ago
    It's only a failure if perfect information was available at the time, an impossibility for most people.
  - e12e 4mo ago
    Write one (system) to throw away...
banannaise 4mo 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 4mo ago
  Rewriting code to be more compact is orthogonal to productivity.
  - jtbayly 4mo ago
    Which is not what is being discussed. Often rewriting code to make it more understandable makes everybody more productive.
  - tauroid 4mo ago
    In a similar way to how a radial burn (https://space.stackexchange.com/questions/44608/what-happens-to-orbit-after-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.
  - bryanrasmussen 4mo ago
    you have evidently been blessed to work only in places with acceptable level of quality code and above.
    - LtWorf 4mo ago
      Or he's the one bringing down quality and productivity.
  - risyachka 4mo 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
sarchertech 4mo 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 4mo ago
  Every line of code is a liability. A potential security breach. An error waiting to corrupt customer data. A maintenance burden.
FuckButtons 4mo ago
… by some fool who didn’t know what they were doing, since evidently the same behavior could be done with less.
gitremote 4mo 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; to 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 4mo 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 4mo 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 4mo 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.
strix_varius 4mo ago
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 4mo ago
  Numbers feels like outliers.
LtWorf 4mo ago
Not everybody is good at their job, or requirements changed over time.
nedt 4mo 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.
BerislavLopac 4mo ago
Deleted code is debugged code.

pydry 4mo 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 4mo 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!

QuantumGood 4mo ago

• LoC/LOC = Lines of Code • sloc = Source Lines of Code .. so I suppose nloc would mean Net LoC

ihsw 4mo ago

[dead]

ecshafer 4mo 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.

strix_varius 4mo ago
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.
dakiol 4mo ago
"High performers". Can't believe we have normalized this vocabulary, among us, "hackers".
- therealdrag0 4mo ago
  Most of us work for business and on teams where performance matters.
  - oompydoompy74 4mo 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.
  - blindhippo 4mo 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 4mo ago

tj-teej 4mo 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.

strix_varius 4mo ago
Good revision!

SwtCyber 4mo 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