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.
Exactly! I've myself spent days investigating an issue only happening on a specific Android device (but used by an important client) only to find that the solution was something along the lines of using "opacity: 0.1" instead of 0.
That bug was left unfixed for months but now it's solved. Should I have received a talk because of that?
(Of course the commit would have had at least 10 LOC more, explaining the reasons and providing references to future devs/self)
I wonder what the grandparent would think about a few LOC/month, there were a few rather gnarly performance issues in the codebase at my work for which the fix was usually a one or two liner, but that took an inordinate amount of research to even know where to start looking.
I guess I should be grateful for having a workplace that has sufficient understanding for the effort it takes to debug such issues.
Right. One data point among many. And managers should be looking at everyone’s code, not just the low LOC ones.
But there are people (I’ve seen this frequently) who constantly represent their work as having been “much more difficult than expected” but then you discover that they actually are struggling with what should be easy tasks, and looking at code (complexity and volume) is a data point. For me, more often than not, it serves as a confirmation of a problem I’ve started to suspect.
xandrius|1 year ago
That bug was left unfixed for months but now it's solved. Should I have received a talk because of that?
(Of course the commit would have had at least 10 LOC more, explaining the reasons and providing references to future devs/self)
khazhoux|1 year ago
Of course not.
But, if your commit history for last 6 months is just one or two of those one-line changes a month, that might hint that there’s a problem.
supriyo-biswas|1 year ago
I guess I should be grateful for having a workplace that has sufficient understanding for the effort it takes to debug such issues.
khazhoux|1 year ago
khazhoux|1 year ago
But there are people (I’ve seen this frequently) who constantly represent their work as having been “much more difficult than expected” but then you discover that they actually are struggling with what should be easy tasks, and looking at code (complexity and volume) is a data point. For me, more often than not, it serves as a confirmation of a problem I’ve started to suspect.
eviks|1 year ago