[twawaaay]

I would add to it that there are a lot of devs that can't build stuff but they try (frequently successfully) to sell that they are doing a lot of volume of work (like closed tickets, lines of code, hours clocked).

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?")

[leghifla]

If management does not pay close attention, doing sloppy work with many small bugs is the key to very high (measured) productivity:

  - 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

Total: you have closed more tickets than a dev that did the feature right the first time... sad

[closeparen]

Given how short tenures are across the board, those of us who are even around to notice long term outcomes are sort of wierdos to begin with. Many senior and staff engineers, architects, directors, etc. have never seen their own work 2 years down the line. Even if they stay at the company they switch teams, etc.

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