Programmers are like art: you can't exactly pinpoint why a particular painting is good but you can usually still put different paintings in rough order of how good they are. It's never that one brush stroke that reveals the quality but the complete picture.
With programmers, there are indirect, subtle signs which may or may not give clues. Sometimes they only validate some good or bad aspects of the programmer.
I think that to really know the only way is to work with the programmer and see what works and what doesn't. Generally the team does have a good notion of who are good and who are just great, although a manager might want to use the information from that source with some grain of salt.
However, it's easier to pinpoint programmers which aren't good, or not completely good. The guy who doesn't get things done. The guy who breaks more stuff than he fixes. The guy who rewrites everyone else's code as the first step in any project or the guy who's always asking help from others for simple things. Or the guy who is actually a good programmer but always ends up doing something a bit different than what the important things to do are. Or the good programmer who is relentless in insisting he's right because "that's what the facts are" while completely ignoring social issues such as understanding that a dictatorian attitude doesn't fly well with other programmers. These guys still do provide some value but you can see these shortcomings from far away. Then there are the guys who actually produce negative values, i.e. taking away others' time merely by being employed.
With programmers, there are indirect, subtle signs which may or may not give clues. Sometimes they only validate some good or bad aspects of the programmer.
I think that to really know the only way is to work with the programmer and see what works and what doesn't. Generally the team does have a good notion of who are good and who are just great, although a manager might want to use the information from that source with some grain of salt.
However, it's easier to pinpoint programmers which aren't good, or not completely good. The guy who doesn't get things done. The guy who breaks more stuff than he fixes. The guy who rewrites everyone else's code as the first step in any project or the guy who's always asking help from others for simple things. Or the guy who is actually a good programmer but always ends up doing something a bit different than what the important things to do are. Or the good programmer who is relentless in insisting he's right because "that's what the facts are" while completely ignoring social issues such as understanding that a dictatorian attitude doesn't fly well with other programmers. These guys still do provide some value but you can see these shortcomings from far away. Then there are the guys who actually produce negative values, i.e. taking away others' time merely by being employed.