4 ms·

> But some people pretend that’s how all their work is, when in reality they take a week to fix a css misalignment, or take a week to refactor some simple pytho

> But some people pretend that’s how all their work is, when in reality they take a week to fix a css misalignment, or take a week to refactor some simple python script and add one new command-line argument, and they average 50 LOC or whatever. You already know what the problem with these people is (e.g. they can take a week to add a new command-line argument). Tying that to the LOC count is counterproductive. Shitty managers like you who try to go against the well-known wisdom and try to use LOC as a metric are what leads to the problem of shitty developers trying to game that count and posting ridiculous metrics like "I checked in 51k LOC in January". Developers who treat their work as a craft will avoid shitty teams like that even if they otherwise do well on the LOC metric.

khazhoux 5y ago
> Shitty managers like you That's rude and against HN guidelines. Don't make this personal. I'm not attacking you. You think I'm taking an extreme position ("Managers should measure developers by their LOC"), which I am not. Are you actually taking the opposite extreme position, that a developer's LOC tells you absolutely nothing about their productivity? That there's not even a correlation or a hint of a connection, in the general case? As a manager, if one person on the team is committing several times a week, and their code is, even at a glance, non-trivial, meanwhile another developer merged 3 times in the last month and the git diffs are 20 lines each, would you say that the 15 LOC a week (or whatever small number) shouldn't be a major concern that I should look into? And when this developer has been saying in every team meeting and 1:1 the last month that they've been working on tough problems. I'm not going to put them on a performance plan over their LOC, but I'm sure going to dive in if I notice a small number there, and we're going to have a conversation about it if it turns out they're not delivering. PS: above is not hypothetical. It's happened many times in cases when I take on a new team or a developer moves under me. A couple of cases were great turnaround stories, with the developer extremely grateful that their manager was actually helping them improve their engineering. In one case the guy was let go, because he refused to accept the concept that he needed to deliver more than a couple of trivial python commits a month to justify his $250K/year salary (long story, I didn't hire him).
- gkbrk 5y ago
  A manager can keep track of job performance by looking at how many tasks are being completed. If someones LOC is very low, but they complete all their tasks on time, not only is there no problem, it is even beneficial as the work is being done without creating too much burden for future development. If someone commits a large amount of code without completing any tasks, that's clearly not useful. If you think LOC is a useful metric, I would disagree that someone calling this "bad management" is attacking you. A hospital manager that measures staff performance by incisions per day is clearly misguided.
  - khazhoux 5y ago
    > A hospital manager that measures staff performance by incisions per day is clearly misguided. Wrong analogy. I have two physicians on my staff. They both have the same years of experience, the same role, get paid the same. One sees 20 patients a day. The other sees 2 a day. That's not a red flag? I should ignore that and assume that somehow every single one of their patients is 10x more difficult, and not even bother to look into it? Because if you would agree I should look into it, then the number-of-patients was a useful metric. A metric is just data point, no more, and not a complete picture. > If someones LOC is very low, but they complete all their tasks on time, not only is there no problem, it is even beneficial as the work is being done without creating too much burden for future development. If someone commits a large amount of code without completing any tasks, that's clearly not useful. I must not have been clear. I'm not arguing for bloated code. Lean code is good, of course. I'm talking about the all-too-common developer who has some number of tasks to complete, and tells his teammates (and me, their manager) that the work is very complex, and so they land (let's say) one bug-fix a week, giving the impression that each bug-fix (or feature, whatever) was challenging. But on inspecting their code, the code itself is fine --nothing necessary wrong with it-- but the changes are all trivial and really shouldn't take a $180K/year developer two weeks or even one to crank out. LOC isn't the full picture but it's often correlated and if nothing else, it's an obvious red flag for me to investigate. To put it simply: If you're a high-paid engineer, you can deliver big features slowly or big tough bug-fixes slowly (and the LOC doesn't matter if the problem was actually difficult), or you can crank out lots of small features and small easy fixes quickly. But if you're barely outputting any code, and trickle out a meager amount of code, and the few lines of code you merge into the repo are all trivially simple, that's not acceptable. That engineer can't cling to "Don't judge me by my LOC!" I'm not -- I'm judging by the small amount of actual value they're delivering.

khazhoux 5y ago

> Shitty managers like you That's rude and against HN guidelines. Don't make this personal. I'm not attacking you. You think I'm taking an extreme position ("Managers should measure developers by their LOC"), which I am not. Are you actually taking the opposite extreme position, that a developer's LOC tells you absolutely nothing about their productivity? That there's not even a correlation or a hint of a connection, in the general case? As a manager, if one person on the team is committing several times a week, and their code is, even at a glance, non-trivial, meanwhile another developer merged 3 times in the last month and the git diffs are 20 lines each, would you say that the 15 LOC a week (or whatever small number) shouldn't be a major concern that I should look into? And when this developer has been saying in every team meeting and 1:1 the last month that they've been working on tough problems. I'm not going to put them on a performance plan over their LOC, but I'm sure going to dive in if I notice a small number there, and we're going to have a conversation about it if it turns out they're not delivering. PS: above is not hypothetical. It's happened many times in cases when I take on a new team or a developer moves under me. A couple of cases were great turnaround stories, with the developer extremely grateful that their manager was actually helping them improve their engineering. In one case the guy was let go, because he refused to accept the concept that he needed to deliver more than a couple of trivial python commits a month to justify his $250K/year salary (long story, I didn't hire him).

gkbrk 5y ago
A manager can keep track of job performance by looking at how many tasks are being completed. If someones LOC is very low, but they complete all their tasks on time, not only is there no problem, it is even beneficial as the work is being done without creating too much burden for future development. If someone commits a large amount of code without completing any tasks, that's clearly not useful. If you think LOC is a useful metric, I would disagree that someone calling this "bad management" is attacking you. A hospital manager that measures staff performance by incisions per day is clearly misguided.
- khazhoux 5y ago
  > A hospital manager that measures staff performance by incisions per day is clearly misguided. Wrong analogy. I have two physicians on my staff. They both have the same years of experience, the same role, get paid the same. One sees 20 patients a day. The other sees 2 a day. That's not a red flag? I should ignore that and assume that somehow every single one of their patients is 10x more difficult, and not even bother to look into it? Because if you would agree I should look into it, then the number-of-patients was a useful metric. A metric is just data point, no more, and not a complete picture. > If someones LOC is very low, but they complete all their tasks on time, not only is there no problem, it is even beneficial as the work is being done without creating too much burden for future development. If someone commits a large amount of code without completing any tasks, that's clearly not useful. I must not have been clear. I'm not arguing for bloated code. Lean code is good, of course. I'm talking about the all-too-common developer who has some number of tasks to complete, and tells his teammates (and me, their manager) that the work is very complex, and so they land (let's say) one bug-fix a week, giving the impression that each bug-fix (or feature, whatever) was challenging. But on inspecting their code, the code itself is fine --nothing necessary wrong with it-- but the changes are all trivial and really shouldn't take a $180K/year developer two weeks or even one to crank out. LOC isn't the full picture but it's often correlated and if nothing else, it's an obvious red flag for me to investigate. To put it simply: If you're a high-paid engineer, you can deliver big features slowly or big tough bug-fixes slowly (and the LOC doesn't matter if the problem was actually difficult), or you can crank out lots of small features and small easy fixes quickly. But if you're barely outputting any code, and trickle out a meager amount of code, and the few lines of code you merge into the repo are all trivially simple, that's not acceptable. That engineer can't cling to "Don't judge me by my LOC!" I'm not -- I'm judging by the small amount of actual value they're delivering.