Hacker News Reader

Comment by cdavid | Hacker News Reader

LOC produced is a good example of what I call "negative" metric: high value does not mean much, but low value is a good indication that something is up.

As a manager, I won't care that dev A produces 2k vs dev B produced 4k. But if I see dev C would produced only 30 loc over say a quarter, something is most likely off.

View on HN

At some point, the curve definitely bends negative. I used to work on a team adjacent to one of the most "productive" programmers at G by that metric.

My team, and at least 4 other surrounding teams, had one full-time SWE cleaning up after him. He would go around making changes assuming things that he thought were safe and breaking tests, then his manager would argue with you that because you didn't make a promise that what he did wasn't safe, you have to fix the test breakage.

Yes, there are large negative externalities to a certain type of engineers who write a lot of code of dubious quality. Even after ignoring all the trivial cases of "artificial code stuffing", etc.

I used to work in a very dysfunctional org where the main "architect" was writing lots of broken code that kinda works, and the 20+ people in the team around it would basically be full time in fire fighting mode. The architect was a very smart guy but ironically enough without any sense of architecture: his level of abstraction for network was pushing bytes through a pipe, and for loops for calculations.

That was similar to this guy - he was a good IC who ended up being over-promoted to an "architecture" role (L7). He didn't really know how to architect things, so he went for creating externalities while resurrecting old, dead projects that past people had designed for him.

What if I produced only 30 lines of code and removed 1950 lines of code?

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

No, this ratio is unrealistic. Either you're making numbers up rather than describing a real situation, or yes you're far too slow for me to want to hire you.

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.

Reply on news.ycombinator.com