One was doing absolutely nothing at all for months on end.
One was doing negative work - every line of code made things worse, every document was unintelligible, and they would approve every PR from other devs the second it was opened.
Suffice it to say, the dev that did nothing at all was the most productive of the two.
And these people frequently last surprisingly long at companies because it is pretty hard for managers to understand how individual team members contribute to overall productivity. Managers tend to focus on short term goals (like getting a feature delivered or a bug solved) but have hard time understanding long term implications of bad decisions their people make.
It is pretty easy to fix a bug or write a feature but a bad developer will cause large amount of debt along with it that will slowly deteriorate productivity in ways that will be difficult to understand. The people who understand what is happening -- senior devs -- will frequently not speak up about it or their voice will be downplayed ("Hey, this guy can't be that bad, he is delivering after all?")
- You close a feature ticket by cutting all corners possible
- Every corner cut will later become a bug ticket, that you can solve quickly as you are more familiar with the feature
Exactly! This can be very difficult to quantify; as this kind of debt is undetectable by standard gates (linter, static analysis, etc.). Instead, it is more nefarious... introducing coupling, where none was needed, or long-winded tests; that test very little, and make the code hard to refactor. I don't have a measure for this beyond my intuition of working with code for decades.
What makes it all worse, is when the features are 'delivered' and marked as 'complete' by these folks, they are difficult to take back! Especially if their delivery was identified as a key objective to a quarter.
It not only lets me know how the person works, how they solve problems. It lets me remediate some of the problems. And just get to know the person on personal level.
The only issue with this is it takes time and does not scale. You can honestly manage up to a dozen devs this way and when I have larger teams I have to skip it (for example I no longer pair with juniors -- I pair with seniors and then teach them to pair with juniors more productively).
Good luck to their new manager.