5 ms·

We've known that lines of code were no indication of code quality or developer productivity for well over two decades now -- why would it start to matter now, p

We've known that lines of code were no indication of code quality or developer productivity for well over two decades now -- why would it start to matter now, particularly for those at more senior levels?

MichaelCollins 4y ago
> We've known that lines of code were no indication of code quality or developer productivity for well over two decades now You're severely overstating it. The difference between 500 loc and 5000 loc isn't a clear signal of anything. But zero lines of code certainly is. Firing people because the VCS shows they stopped working is common.
- covidiot5 4y ago
- watwut 4y ago
  Zero code situation is wishful thinking - poster just made it up.
  - polynomial 4y ago
    Perhaps an awful lot of people were just working on a stealth no code project.
  - MichaelCollins 4y ago
    > wishful thinking I have no stake in the matter. My supposition that some employees simply stopped working comes from my experience seeing similar things happen at other companies during periods of uncertainty, and from my knowledge that quite a few twitter employees were very uncertain about their future with twitter.
  - colinmhayes 4y ago
    There are people on my team that haven’t committed anything for a couple weeks. I don’t work at Twitter, but wouldn’t be surprised if there were people who basically weren’t working.
  - skirmish 4y ago
    I spent the last month prototyping code for a demo that will not be checked in. I have a few small unrelated CLs submitted (minor fixes) but I spent 5 minutes per each, my main work for the month is completely unaccounted for in version control. Should I be fired?
    - lupire 4y ago
      Yeah your shoddy practices are certainly suspect. Why aren't you using version control to checkpoint your prototype?
    - MichaelCollins 4y ago
      For your own sake, you should probably check that demo code in somewhere. Keeping a 'paper' trail of the work you've done is always a good practice to follow.
- pfisherman 4y ago
  The true big brain 10x programmer is pushing -100 lines of code per sprint.
  - colejohnson66 4y ago
    https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
  - prepend 4y ago
    I sort of think of the absolute value of lines changed as a pulse. You can do -100. You can do 100. You can net zero from 100 adds and 100 subtracts (abs=200). But it’s something. If you have long stretches of zero that’s not good.
  - Gibbon1 4y ago
    The true big brained programmer sat in a meeting and prevented a team of 25 people from wasting 6 months.
    - bigiain 4y ago
      Sure. That’s super valuable. But I hope they have something productive to show for the other 20 odd days that month they collected their paycheque for…
  - kps 4y ago
    At a previous job I had a few months where I managed approximately minus‐1 instruction per week — and it was the best money the company ever spent. Hard constraints are hard.
  - bigiain 4y ago
    Sure. But a code review of their checkins will reveal their productivity pretty quick. Any one claiming 10x (or even 0.75x) productivity would want some very good supporting evidence if they have zero activity in the source control for a month. You want some great specification documents or API documentation or platform architecture diagrams or something…
- thinkindie 4y ago
  is code the only output of an engineer? not everything is committed in a VCS: you have documentation, architecture, RFC etc etc depending on the size of the company and seniority of the employee.
  - prepend 4y ago
    That stuff is typically in a VCS. I don’t think it’s an absolute rule that no commits means someone isn’t developing. But it’s probably a reason to have a conversation.
khazhoux 4y ago
While you are correct that LOC is not a full measure of productivity, and there are many factors to consider, it would be nonsense to say that merging code has no bearing on productivity. All things equal (and disregarding engineers whose job isn’t coding per se), submitted code is the essential deliverable of a software engineer.
- roughly 4y ago
  No, “solved problems” is the essential deliverable of a software engineer, and the more senior one gets the less often “submitting code” is the correct path to solving a problem. Someone might submit code based on your work, but there’s no direct correlation between “submitted code” and “did your job” at higher levels.
  - khazhoux 4y ago
    But you’re describing exactly what I mentioned above: engineers whose job is not code, per se. Yes, the super-senior engineer who cracks down on bad code by others and sets the right path, etc, is very valuable even if they’re not directly coding themselves. I’m talking about the engineers who are directly responsible for implementing features and fixing bugs. I.e., most software engineers. Sometimes a great engineer spends a month tracking down a 3-line fix, and that’s just what happens with complex software. But by and large, if an engineer averages only a few LOC a month (and I’ve unfortunately seen this way too many times) then we probably have a problem on our hands.
    - roughly 4y ago
      The question is who’s writing the code. A core part of a senior engineer’s job is helping to train and mentor junior engineers; it’s not unusual for an entire project to be designed and led by a senior engineer and implemented by more junior engineers. Design reviews don’t result in commits, deep dives on technical implementations don’t result in commits, negotiating an architecture change between groups don’t result in commits. A large amount of the actual heavy-lifting value-add of an actually senior engineer is not in the code they’re writing.

MichaelCollins 4y ago

> We've known that lines of code were no indication of code quality or developer productivity for well over two decades now You're severely overstating it. The difference between 500 loc and 5000 loc isn't a clear signal of anything. But zero lines of code certainly is. Firing people because the VCS shows they stopped working is common.

covidiot5 4y ago
watwut 4y ago
Zero code situation is wishful thinking - poster just made it up.
- polynomial 4y ago
  Perhaps an awful lot of people were just working on a stealth no code project.
- MichaelCollins 4y ago
  > wishful thinking I have no stake in the matter. My supposition that some employees simply stopped working comes from my experience seeing similar things happen at other companies during periods of uncertainty, and from my knowledge that quite a few twitter employees were very uncertain about their future with twitter.
- colinmhayes 4y ago
  There are people on my team that haven’t committed anything for a couple weeks. I don’t work at Twitter, but wouldn’t be surprised if there were people who basically weren’t working.
- skirmish 4y ago
  I spent the last month prototyping code for a demo that will not be checked in. I have a few small unrelated CLs submitted (minor fixes) but I spent 5 minutes per each, my main work for the month is completely unaccounted for in version control. Should I be fired?
  - lupire 4y ago
    Yeah your shoddy practices are certainly suspect. Why aren't you using version control to checkpoint your prototype?
  - MichaelCollins 4y ago
    For your own sake, you should probably check that demo code in somewhere. Keeping a 'paper' trail of the work you've done is always a good practice to follow.
pfisherman 4y ago
The true big brain 10x programmer is pushing -100 lines of code per sprint.
- colejohnson66 4y ago
  https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
- prepend 4y ago
  I sort of think of the absolute value of lines changed as a pulse. You can do -100. You can do 100. You can net zero from 100 adds and 100 subtracts (abs=200). But it’s something. If you have long stretches of zero that’s not good.
- Gibbon1 4y ago
  The true big brained programmer sat in a meeting and prevented a team of 25 people from wasting 6 months.
  - bigiain 4y ago
    Sure. That’s super valuable. But I hope they have something productive to show for the other 20 odd days that month they collected their paycheque for…
- kps 4y ago
  At a previous job I had a few months where I managed approximately minus‐1 instruction per week — and it was the best money the company ever spent. Hard constraints are hard.
- bigiain 4y ago
  Sure. But a code review of their checkins will reveal their productivity pretty quick. Any one claiming 10x (or even 0.75x) productivity would want some very good supporting evidence if they have zero activity in the source control for a month. You want some great specification documents or API documentation or platform architecture diagrams or something…
thinkindie 4y ago
is code the only output of an engineer? not everything is committed in a VCS: you have documentation, architecture, RFC etc etc depending on the size of the company and seniority of the employee.
- prepend 4y ago
  That stuff is typically in a VCS. I don’t think it’s an absolute rule that no commits means someone isn’t developing. But it’s probably a reason to have a conversation.

khazhoux 4y ago

While you are correct that LOC is not a full measure of productivity, and there are many factors to consider, it would be nonsense to say that merging code has no bearing on productivity. All things equal (and disregarding engineers whose job isn’t coding per se), submitted code is the essential deliverable of a software engineer.

roughly 4y ago
No, “solved problems” is the essential deliverable of a software engineer, and the more senior one gets the less often “submitting code” is the correct path to solving a problem. Someone might submit code based on your work, but there’s no direct correlation between “submitted code” and “did your job” at higher levels.
- khazhoux 4y ago
  But you’re describing exactly what I mentioned above: engineers whose job is not code, per se. Yes, the super-senior engineer who cracks down on bad code by others and sets the right path, etc, is very valuable even if they’re not directly coding themselves. I’m talking about the engineers who are directly responsible for implementing features and fixing bugs. I.e., most software engineers. Sometimes a great engineer spends a month tracking down a 3-line fix, and that’s just what happens with complex software. But by and large, if an engineer averages only a few LOC a month (and I’ve unfortunately seen this way too many times) then we probably have a problem on our hands.
  - roughly 4y ago
    The question is who’s writing the code. A core part of a senior engineer’s job is helping to train and mentor junior engineers; it’s not unusual for an entire project to be designed and led by a senior engineer and implemented by more junior engineers. Design reviews don’t result in commits, deep dives on technical implementations don’t result in commits, negotiating an architecture change between groups don’t result in commits. A large amount of the actual heavy-lifting value-add of an actually senior engineer is not in the code they’re writing.