You are a master of a programming language when you consistently write idiomatic code in that language which exploits the power of the language to solve difficult problems in an easy-to-explain way.
Or in detail:
You must consistently write code in the language. Knowledge without experience cannot make you a master.
You must write idiomatic code for the language. If you're just writing FORTRAN in another language, then you might be a FORTRAN master, but you aren't a master of the language you're using.
You must exploit the power of the language. If you're writing "for" rather than "foreach" loops to iterate over a collection in C# or rolling your own LinkedList class, you aren't a master of C#.
You must solve difficult problems. Writing Hello World will never make you a master.
You must write code in an easy-to-explain way. If you are the only person who can read your code, you aren't a master of the language.
The people I've worked with who were true masters of their languages (or other tools) understood what happened under the hood. They knew the techniques required to implement the language themselves, or to debug or optimize existing implementations. They understood any differences or gaps between the language spec and their preferred implementation's actual behavior.
I'm trying to approach it from a slightly different angle (although pmiller2 alludes to it):
When you know that a language is absolutely the wrong choice for a problem, you are probably there.
When you can hold a problem in your head, use two different programming languages to shape a solution, and intuitively understand - in a way you can clearly communicate at least to yourself - which one is best suited to the situation, then you can consider yourself an expert.
5 comments
[ 4.2 ms ] story [ 27.0 ms ] threadOr in detail:
You must consistently write code in the language. Knowledge without experience cannot make you a master.
You must write idiomatic code for the language. If you're just writing FORTRAN in another language, then you might be a FORTRAN master, but you aren't a master of the language you're using.
You must exploit the power of the language. If you're writing "for" rather than "foreach" loops to iterate over a collection in C# or rolling your own LinkedList class, you aren't a master of C#.
You must solve difficult problems. Writing Hello World will never make you a master.
You must write code in an easy-to-explain way. If you are the only person who can read your code, you aren't a master of the language.
expert: biggish list of work\projects finished, know how to leverage the standard/popular libraries
* He's written a non-toy compiler for the language.
* He knows how to choose between more or less semantically equivalent ways of writing the same code because he understands the tradeoffs involved.
* He's explored many or most of the dark and mysterious corners of the language and knows when and when not to invoke them in production code.
* He is familiar with the contents of the standard library and uses it whenever appropriate.
* Knuth is his homeboy.
That's all I can think of for now.
When you know that a language is absolutely the wrong choice for a problem, you are probably there.
When you can hold a problem in your head, use two different programming languages to shape a solution, and intuitively understand - in a way you can clearly communicate at least to yourself - which one is best suited to the situation, then you can consider yourself an expert.
Mastery is just a path.