Hi Bill!

https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

In your career, how often have you seen good software engineers whose main contribution was deleting code ?

Please take my argument in good faith: I am not looking at evaluating people based on their added LOC. The context is at orgs where I have reason to believe some people are slacking off, and looking for people who do next to nothing.

That's much more common than people who magically make everyone more effective by only deleting code.

I've seen a few projects across different organizations where an old dev was bad at copying and pasting code and ignored DRY principles. The projects had almost no refactoring, and the primary goal of a new dev was cleaning up the redundancy to better map things out for better organization of the codebase.

> In your career, how often have you seen good software engineers whose main contribution was deleting code ?

Depends on the size and age of the company. In a startup, approximately never since the job is to build something out of nothing.

In a large enterprise with decades of codebase history to be optimized, very frequently.

Yes, I have had to clean up a 300,000 LOC codebase and my primary contribution was deleting old code and reusing code we already had

I did say I wrote 30 lines of code, which was reusing other code instead of copy-pasting and changing a few things

Maybe the metric should be "How much diff did you produce. Removing 2k LOC and being able to replace it with 30 is kind of great.

Yes, obviously you would look at number of lines changed. Which is what git reports to you when you do git log --stat and so on.

I don't think anyone (sensible) thinks 'if someone only writes 30 lines of code per quarter, they should be immediately fired'. I think the point is more that if you have someone who's only written 30 lines of code, it's worth taking a look to see what they've been doing instead.

For sure there may be a thousand good reasons for it, but as a quick heuristic for 'who is worth having a quick check to see if we're getting the value out of them that we're paying them for?', I don't think it's irrational.

If this is what you did all quarter (and don't have any other artifacts to show, like an ML model or system design or whatever), yes it's a red flag.

It's not because the ratio is bad - if you wrote 300 and removed 19500 that might be fine. It's just that 30 is, in an absolute sense, too low.

I had to read 300,000 lines of code first. It's impossible to do that in a week or two.

The number of lines removed I don't remember and it changes nothing about the effort to read and understand the whole codebase

Reading code takes time, have you ever read through an entire 300k LOC codebase ever?

That's more lines of code than https://www.gnu.org/software/bash/

There was a funny story I don't remember where... A manager was doing LOC as a metric, and they were required to count it. But an engineer refactored and put -1000. That was the last time they asked for it.