Comment by 88913527
2 years ago
It's more about measuring outcomes. We have a goal, did we meet the goal. There are many paths to the goal, so measuring things like lines of code is incorrect. But so is measuring Bob's ability to ask Alice a good question. Management can't, at scale, consider such factors. We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways. Performance reviews would become even more subjective if we had to place a value on the impact of asking questions. All forms of measurement are flawed, so I stick with outcomes.
Quickly shipping a thousand lines of buggy code that you then spend the next month fixing (by writing thousands more lines of code) is a good way to fool everyone into thinking you are productive.
> Management can't, at scale, consider such factors.
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.
It isn't wrong, it's right; because pontification of things (in a vacuum) yields no results. I cannot sell my customers Bob's ideas. All I can sell them is software that does something. The people that can do this without needing Bobs around are the people that will be rewarded.
Well that software you sell them is fundamentally better and more maintanble because a person like Bob is around to give directions.
> 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.
The part that's often missed is the future outcome, when someone returns to this code to fix a bug or add a new feature. I believe it's incumbent upon those of us with some experience to ensure maintainability is part of the considerations.