The more I think about it, self evaluating is hard without a reference to "guide" you towards a particular domain. For example, aside from the foundations (name your variables properly, writing readable code), the rest starts going into too esoteric requirements (writing libraries that simplify an api?, author of a framework?). Some of these requirements are unjudgeable (I can author a framework to encode/decode ssl packets, but in itself it's a poor indication of my skill), now writing a framework that stands the test of time (is rarely revised) is a different measuring stick, but that can only be 'evaluated' by someone who understands what are the pitfalls of writing a framework (http://lcsd05.cs.tamu.edu/slides/keynote.pdf). And if you are in an area that writing frameworks is not desirable (a lot of security-centric projects are like that, you want to use trusted sources and not venture in writing your own thing), then that measure becomes irrelevant.

I think that there is only two ways to improve in our field.

- Write, write, and write code. The more complex the better. Two caveats:

Maintain what you write. One-off projects don't count, you gotta live with what you write, since that's forcing you to make it maintainable.

Write with people, if other people have to live with what you write, they will tell you if something stinks (of course this is assuming your teammates have a decent level of professionalism).

- Be mentored: Essentially someone who did the above, and then shows you how he suffered :)

Hope this helps.

Freddy (http://www.javapubhouse.com)