3 ms·
LOC as a datapoint provide no value that a manager couldn’t get quicker and with less ambiguity via other sources. For example, identifying engineers strugglin
by pflenker 3y ago
LOC as a datapoint provide no value that a manager couldn’t get quicker and with less ambiguity via other sources.
For example, identifying engineers struggling for a month on a topic, as you described, can be uncovered way earlier by replacing a reporting-Like „standup“ with collaborative structures that help the team, and the manager, understand progress and potential blockers.
LOC are lagging way behind on issues like these and are devoid of any meaning in isolation.
I know your counter argument here is „one data point among many“, but mine is: if your other data points are solid, LOC do not add any value.
- khazhoux 3y agoWith the exception of engineers whose role is strictly advisory, architectural, etc, for most engineers the direct literal expression of their work is the code that they commit. Not the design document, not the ideas in their head, but the code in the repo. Managers should be looking at this code in their evaluation of everyone's work. Someone with an unusually-small amount of code shouldn't be "punished" but it is something that should be noticed and examined.
- pflenker 3y agoThat is the equivalent of saying that the direct expression of a musician‘s work are the sounds they produce and therefore they should be heard in isolation. But as much as an orchestra produces symphonies as a group, development teams produce software as a group. This output matters and should be looked at, the individual code contributions to that output matter less and looking at them in isolation doesn’t provide insights that looking at the team‘s output in terms of working software, bugs, incidents and more wouldn’t. A manager looking at the individual LOC contributions is looking into the wrong direction.