[khazhoux]

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.

[eviks]

confirmation bias indeed works that way more often than not: it confirms what you already believe

[khazhoux]

I'm confused which part of this is so off-putting.

Joe is always the one in every standup saying the thing he's working isn't done yet because he's wrestling "one last tough bug." As a manager, you wonder if the technical problems are really that tough or if Joe is just struggling. Let's look at the commit history... yeah, something is off here, Joe has 1/10th the commits of his peers and they really don't seem more complex in any way, but look rather trivial. Time to talk to Joe and look at these commits together and see what's going on.

Is that really such a troubling proposition?

[eviks]

So troubling that you can't propose it cleanly: if you've already defined that "they really don't seem more complex in any way, but look rather trivial", why would you need to count? (another troubling sign is going for the order of magnitude assessments, and another minor point: you've mistakenly replaced volume of code with # of commits)

[jen20]

So why wasn’t the response after day 1 of the “tough bug” something like “hey, why don’t you pair with X to get to the bottom of it?”?

[samatman]

If you declare by fiat that every confirmation is confirmation bias, you've made knowledge impossible.

[eviks]

What happens if you declare by fiat that every mention of confirmation bias is declaring by fiat that eveyr confirmation is biased?