in reply to Measuring programmer quality
Not that having "good documentation" is ever bad, but the relative weightings of different attributes is heavily situation-dependent.
"Perfect" code, not that there is such a thing, is probably immune from all these considerations. But a "perfect" developer would not be -- you have to juggle things to fit your particular situation, or you're optimizing the wrong things.
I find that the opinions of the people around me are the most reliable gauge -- the users, the QA folks, the developers I work with, and the production people who suffer with the problems (both in my code and in reality, but reported to them via my code). I know people who quickly write large bodies of code that effectively and efficiently solve the problem at hand -- but they drive me crazy because they assume that everything will be perfectly configured and nothing will ever unexpectedly go wrong. And when it does, and I bring them the problem, they brush me off with a test case demonstrating that it works just fine. Clearly I misconfigured something or something about my environment "isn't what it's supposed to be" (== matches their assumptions).
In short, I think it's about whether you make the people around you happy, and whether you can keep them happy.
Come to think of it, that's a lot like another profession. One with a somewhat different dress code.
|
---|