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.
> 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?
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.
> 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.
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.
… by some fool who didn’t know what they were doing, since evidently the same behavior could be done with less.
> 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.
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).