Because lins of code churned out is not and has never been a good measure of productivity.
That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem.
Which is basically the entire point of the article.
Why not? Peer feedback is a prime component of most performance/rewards discussions at companies. Work outside of points is certainly not a new concept. A manager's job is to distill this information amongst others to their own management chain at the right time.
> We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways.
Bob's time isn't unlimited. There are surely instances where he was helping out Joe, Suzie, Darren, and James and had no time for Alice.
Based on your other comment, you seem to think someone being an unblocker/idea generator/dev lead is a "low performer" who weighs the team down. That's just fundamentally wrong.
> The people that can do this without needing Bobs around are the people that will be rewarded.
Unicorns are few and far between, but sure, you do you.
Also, solving the same problem with less code is a lot more valuable than many think. Not only are there fewer code paths to test, the system probably has fewer unnecessary constraints and edge cases to consider. How do you account for negative LoC?
It will take me far longer to come up with the correct 100 lines that is both maintainable and can be worked on by others down the line.
I can pad my lines of code in seconds if I wanted to before pushing the changes. That padding provides no business value and might even introduce bugs.
And how do you handle refactoring? If I come in and refactor everyone else's shitty padding by combining helpers and optimizing code, I'll have negative lines of code. Am I an unproductive worker?
Sure, most code is not some complex algorithm but lines of code is a stupid metric that is not representative of the work done and can be gamed by anyone knowing what they're doing.
It's better to have tests more sensitive to failure, like integration or regression tests.
The key there is caching your results. Don’t run unit tests for code that hasn’t changed.
They still serve the important purpose of checking validity of the code under test though, so if they do get modified downstream at some point and they fail you then know the changes aren’t conforming to expectations of the system.
This of course assumes people aren’t writing highly coupled tests and that is more rare than I wish it to be