The most important thing from my perspective is how well he or she develops in the context of the entire team. In no particular order a good developer will:
1. raise issues when other developers suggest solutions (even if just to play devil's advocate) to encourage discussion
2. be willing to have his or her opinion overruled by consensus, understand why, and proceed with contributing to implementation of it as well as if it hadn't been
3. accept constructive criticism in reviews of his code (and can make counter-arguments when appropriate without becoming defensive)
4. improve his or her craft by acknowledging and correcting errors in code and design when he or she makes them (nobody is perfect, and every experience level of engineer will make mistakes in judgement, and errors in logic, structure, and design occasionally), but generally make fewer such errors as time passes
5. seek out opportunities to share expertise, experience, and advice with co-workers
I'd say if most of these points are hit, a developer is doing a good job.
I'd be very afraid of mentioning any of your points to anybody that needs them mentioned.
Well, #4 is a little more resilient to misunderstanding the other ones, but even it can lead to horrible decisions.
Anyway, that makes me question the original theme. The article's answer is as good as "if you know how to evaluate developers, you can evaluate developers", and yours isn't much better than it, yet, I've never seen a better answer.
Well, I disagree that this is equivalent to your description of the article's answer. But I take your point.
I'm not sure there's a universal, objective way to evaluate what "doing a good job" means for any job that isn't ruled almost strictly by some quantitative measure (e.g. "output is X widgets a day").
None of the items on this list have absolute measures ("plays devil's advocate at least once a month"), or even well-defined relative measures ("makes 10% fewer mistakes after being corrected") for exactly that reason. They're heuristics, and I'm skeptical applying anything more rigorous is reasonable to attempt.
1. raise issues when other developers suggest solutions (even if just to play devil's advocate) to encourage discussion
2. be willing to have his or her opinion overruled by consensus, understand why, and proceed with contributing to implementation of it as well as if it hadn't been
3. accept constructive criticism in reviews of his code (and can make counter-arguments when appropriate without becoming defensive)
4. improve his or her craft by acknowledging and correcting errors in code and design when he or she makes them (nobody is perfect, and every experience level of engineer will make mistakes in judgement, and errors in logic, structure, and design occasionally), but generally make fewer such errors as time passes
5. seek out opportunities to share expertise, experience, and advice with co-workers
I'd say if most of these points are hit, a developer is doing a good job.