One thing very clearly separates exceptional developers from average "programmers:" naming.

I've found that looking at a developer's naming habits is a clear, fast way to evaluate both overall skill and mastery of a given topic. Take a Java library; look at its JavaDoc and pay close attention to the way classes are named.

If the intent of the library's key abstractions doesn't stick with you once you learn the names and read the docs, it is a bad sign. Exceptional developers create classes with clear, simple names that convey intent and suggest how all the pieces fit together.

Take Doug Lea's concurrent library. Even if you aren't familiar with the differences between Java and POSIX threads, just looking through the class documentation makes the library usage clear.

Even though you may not remember the details, you'll quickly pick up the intent of Channels, Executors, and Barriers. The classes are named simply and make interface / implementation separation easy to understand. The names are simple, like Executor, rather than obscure (Doer, TaskHandler), goofy (Cruncher) or wordy (RunnableEntityManager).

Good developers know how to name things.

Likewise, one way to spot developers working on problems they don't fully understand is to look for naming breakdown. I see this with myself. When I really understand the problem I'm trying to solve, my code is much cleaner, and class / method names are better thought out. When I'm unsure of the nature of the problem, however, my naming breaks down. I start writing lots of "*Manager" classes. I copy / paste methods (getActiveCustomers()) and subtly rename them (getFullyActiveCustomers()) without conveying intent and difference.

When I'm starting to hack, the code starts to smell.

So, yea; I'm big on the names of things. Of course, maybe I'm this way because I have an English Lit degree. You decide.