Comment by 4lx87
11 hours 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.
11 hours 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.
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).
Every line of code is a liability. A potential security breach. An error waiting to corrupt customer data. A maintenance burden.
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.
Rewriting code to be more compact is orthogonal to productivity.
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.
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?
Which is not what is being discussed. Often rewriting code to make it more understandable makes everybody more productive.
you have evidently been blessed to work only in places with acceptable level of quality code and above.
non-coding manager spotted
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
> 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
to
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?
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 would be putting the processes in place to stop doing that.
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.
There were no comments.
If there were comments for each conditional, it should still be refactored as
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.
1 reply →
> 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?
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?
It's only a failure if perfect information was available at the time, an impossibility for most people.
Write one (system) to throw away...
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.
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.
> 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.
> 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.
1 reply →
… by some fool who didn’t know what they were doing, since evidently the same behavior could be done with less.