Summary
- Relative: Are you among the top developers you work with (or worked with)?
- Absolute: Do you read C++ books from world-class experts, and understand them?
- Forever: Do you code in C++, trying to find new ways of coding better, faster and safer? Do you STL? Boost? Does C++0x means something to you?
- Humility: Do you know you're not the best, but are still able to find the info you don't know, reading the right expertise from the right experts, and understand it, and explain it to others, who will trust your answer?
- Investigating: Can you produce test code to prove/dismiss a point, producing results and analysing them, including using a language feature you never used before?
- Obsolescence: Learn to recognize when you are obsolete.
Note that most of the points will silently reference another...
1. Expertise is relative
Most people would not hire world-class C++ experts anyway, so you should not try to pass as one unless your first name is strange and recognizable (Herb? Bjarne? Andrei? Scott? Andrew?)
Instead, you should know where in the "global C++ developers" population you are.
For example, if in your past jobs, you went from "I'm junior C++ typewriter and I know Word and Excel" to "I know why your C++ code does crash", then you are at least somewhat better then the other people. Did you participate in your team/company's coding norm? Do people ask you questions about their C++ problems? Do you offer them solutions?
In the same way, if you participate in C++ forums with developers from all around the world, like Stack Overflow and that you are among the elite of this forum, that your answers are praised, that your questions are considered legitimate and interesting, then you could be considered an expert.
2. Expertise is absolute
Knowledge comes from experience, but also from pure learning. For example, reading books from C++ world-class experts like Herb Sutter or Scott Meyers is the bare minimum. Did you play with Alexandrescu's books? Did you have a copy of Bjarne Stroustrup book and actually read and understood them?
Did you read C++ books and felt you understood them? Did you write a C++ book? Or a C++ FAQ?
3. Expertise is Forever
Forever not like in "Diamond are Forever" (this would make you a world-class assh*le, forever stopping others from evolving because you believe you know better).
Instead, Forever like in "You will be condemned to practice your art forever".
Did you use C++ for real life projects? Did you write a library with real-life users? Did you use C++ for personal prototypes, just to see if it works?
No matter how much people work on C++ in their day work, each hour playing at home with C++ is worth 4, 8 or even 20 hours of normal day work because in normal day work, you won't get the opportunity to test your limits. So no matter how much late you are compared to others in your team, if you are geek enough to "play at home", you'll soon get past them in Turbo Mode. Your luck is that there are good libraries on the wild: STL and Boost being the easiest to come because, being templates, their source code is easily available.
This kind of practice pays because it keeps you on shape (mental, if not physical), keeps you up-to-date with current technologies, and because you're just accumulating experience past the experience of other "just for the pay" developers. And with experience comes expertise.
4. Expertise goes with Humility
You are not the expert on C++, but you can still be an expert if you know where to find the right info. This means reading posts from other experts, understanding which info is usable, and which info is useless. This means asking the right questions, to the right people.
You can be an expert if people come to you to have the right answer, no matter how you found it, as long as you can understand it and explain it to others
This goes along the line "Forever, not like diamonds". There is always a bigger fish, and sometimes, expertise is just recognizing the best among the best, understanding their viewpoints (and thus, learning), and sharing it with your co-workers.
People like it when, when they ask you a question, the answers is somewhat like "I saw this answer on this particular forum post, and I feel this is the right answer because...", because your knowledge has a verifiable base, and is not some kind of "out of the hat", "take it or leave it" miraculous answer.
People like to trust the people, so don't get mysterious with info.
5. Expertise is Investigating
I know of some armchair experts, that will tell to you that they are right, period.
An expert does not tell he/she is an expert.
An expert proves/dismiss points with code and is able to explain/discuss them, again with code.
And in the end, he/she does offer the proof the solution is the right solution, with both code and testing.
6. Expertise is NOT Obsolescence
It is easy to believe yourself an expert or some kind of technical reference when you worked on the same code since eons. Perhaps you did become set in your ways. Your expertise is just a fancy name to hide the fact you're obsolete.
Did you ever concluded a discussion with a "It is the way it is done here" when every other arguments you offered were easily dismissed as wrong?
If yes, then you have a problem.
You should consider the fact your expertise could be a thing of the past (if at all). Either you work hard to regain your expertise, or you should let go the "Expert" title, using instead something like "Experienced".