In most companies that do programming teams and divisions consist of programmers who design and write code and managers who… well, do the management stuff. Aside from just not writing code, managers usually do not even look at the code the team develops, and may even have no proper IDE installed on their work machines.
Still, the managers are to judge if a person works well, if he or she should be put in charge of something, or if particular developer should be assigned to a task of the most importance and responsibility. And last, but not least: the managers usually assign the quarterly bonuses!
To do the above effectively, a manager should know if a person is a good programmer—among other traits, of course. The question is, how do they do it? They don't even look at the code people write, they can't directly assess the quality of the components programmers develop… but their estimates of who is a good coder, and who is "not as good" are nevertheless correct in most cases!
What is the secret?
Best Answer
Typically a manager will look at
Its true that they usually don't see (or often understand) employees' code, but the above for them serves as a reasonable proxy for measuring how well an employee fits into the programming role imposed on them by their employer. If somebody isn't getting stuff done, gets low grades from their colleagues, can't communicate well, gets frustrated with different technology then they're used to, always needs supervision, and is always unhappy, its a good indication they aren't meshing well with this job.*
*It may be, however, that in a different context and environment they'd be very happy and enthusiastic. Maybe its just being that kind of programmer that they objected to, and they might do very well programming in a different context. "Programmer" can mean very different jobs at different places. But the manager cares mostly about their "programmer" role and how well an employee fits.