I spent a lot of time trying to figure it out and I have some theories.

First, we underestimate how difficult it is for managers to learn which employees are good ones and provide value. There is a lot of reasons for this.

Maybe they aren't very good engineers themselves in the first place? Maybe they have some skewed measure of what value is (for example they just count closed tickets or lines of code written or some other measure that has little to do with real value?)

Second, some people create a lot of shit that will come around as technical debt later. But understanding technical debt is incredibly complex task for the manager. I have never seen a manager that has good understanding of where their technical debt comes from, forget about pinpointing exact people that are causing it, except for very special situations (like me pointing out a PR and explaining line by line why this is poor development).

They can and do close tickets a lot. They do that because they feel insecure and need justification for them being there. But they will do quantity over quality and will tend to pick simple problems that will not expose their lack of capability.

You can solve a lot of problems by simple trial and error. Which tends to produce poor code.

Yes, they tend to close a lot of tickets. But they also tend to create more problems than they solve.

Most corporate projects I worked for do not require any complex coding. You can get by ctrl-c/ctrl-v-ing existing code. A difference between a good and bad employee will not be in whether they can produce a code that works now. The difference might be whether they can:

- produce code that will work correctly regardless of the changing circumstances,

- produce code that is as simple as possible but not simpler than necessary,

- notice problems with the codebase and take initiative to fix this on the spot (sometimes without anybody else even being aware of),

- notice opportunities for improvement that somebody else will be working on,

- drive communication to ensure the feature that is being built is really what the client needs (rather than what the client wishes), then to confirm satisfaction,

etc.

Additionally, these people tend to create an image of being overworked which looks plausible from manager's point of view. It does not help that other developers might be aware of this but will not say a word to the manager (as it might be considered "snitching" or they might feel they shouldn't do that which somebody else might do for them).

These things are not easy to understand when you are a manager and you are also surrounded by your team that guards every word they send your way.

Thank you for sharing your detailed experience and insight into the problem. It sounds like this field has a long way to go to produce better engineers. Perhaps the way software engineering education and training needs to be completely rethought. It’s ironic that despite the name, so much of the creation of software lacks the craftsmanship attributes that other engineering disciplines possess.