[kaidon]

> deteriorate productivity in ways that will be difficult to understand

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.

[twawaaay]

That's why my personal favourite tool to manage this is pair programming with people. I do pair programming for interviews and I do longer (at least a week) pair programming projects with all my devs at some point.

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).