Earlier quoted context omitted.
But they ARE a KPI that is easy to understand and measure.
they are not a KPI in the first place. loc is not a performance index of any kind.
Edited: wrong parent
-2000 Lines of Code (2007)
21–30 of 222 posts
Re: -2000 Lines of Code (2007)
#22this keeps coming… recently there’s been a bit of debate between Milvus and Qdrant on this topic: https://www.linkedin.com/posts/yujiantang_how-can-you-judge-...
Re: -2000 Lines of Code (2007)
#23> they stopped asking Bill to fill out the form which is only possible because he's so important. imagine doing this as a stack-ranked IC in an org like AWS. The old days of a software as an artisanal craft is long over imho.
I'm by no means important in my org but when something appears like a shitty idea I will raise that (like other ICs around me) and more often than not it works out fine. I'll agree to give something a shot but if it doesn't work it doesn't work and my managers so far have all realized that a bit into the trial period. Reading comments like yours, I guess I should value my work environment more.
If you want to see an extrema of people being afraid to speak up, just look at the Gemini image examples in a company that in theory encourages people to speak up. There are always topics that are exceptions.
Re: -2000 Lines of Code (2007)
#24Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many.
It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the commits.
This can reveal potential problem areas for the manager to investigate with the engineer. You might find that the engineer has very few, very small commits compared to their peers, and then upon looking at the actual code you may find that the code seems rather trivial. This would warrant a conversation. Why have they reported at every standup the last six months that they're stuck behind very tricky problems when the commit history shows only a couple of seemingly simple changes? Maybe the problem really was tricky, but maybe the engineer is struggling and doesn't realize it. So let's find out.
So while no one should be reduced to a simplistic LOC metric, and recognizing that more code can mean more bloat, we can't pretend that the amount of code that a developer writes is devoid of any meaning, as if it were just a random number.
Re: -2000 Lines of Code (2007)
#25A corresponding thought-experiment is to consider the results of the opposite situation: if a manager read this article, and simplemindedly decided to measure by lines of code removed instead. Would that make things better or worse?
Re: -2000 Lines of Code (2007)
#26Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.
Re: -2000 Lines of Code (2007)
#27Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
Do you really expect most managers, if any, would do this?
Re: -2000 Lines of Code (2007)
#28Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
The main issue is the majority of managers arent especially qualified to make a judgement of the code itself which makes the metric spurious at best. Lines changed is at least a better version than lines added. But it is fairly devoid of meaning removing ten lines can be extremely hard and impactful compared to adding 1000 lines of deeply nested ifs written poorly. Lines changed multiplied by number of files touched is possibly better too.
Re: -2000 Lines of Code (2007)
#29Gave myself RSI deleting On the plus side I replaced an O(n²) algorithm with a faster one in the very next commit. Needed to get rid of the ninety copies of the same bad idiom first.
600dd:w shouldn’t cause RSI ;)
Re: -2000 Lines of Code (2007)
#30The moral: even if you are smart as Einstein you are still an employee and need to do employee things.