Mastering a programming language takes a long time. The only way to do it is to read and write lots of code — lots of different kinds of code so you have to learn every feature of the language. Doing tutorials and following toy examples in books gives you an idea of what a language looks like, but it’s a long way from mastery. Learning to program probably takes ten years. Mastering a programming language shouldn’t take that long, but it takes longer than a few late nights.
A lot of programmers are language dilettantes: they have played with a lot of languages but haven’t mastered one. Some of them are amateurs who don’t have to make a living writing code. Some are paralyzed by too many choices. It’s easy to think you’re missing something when you see articles about Haskell, Erlang, F#, Ocaml every day. It’s easy to think you’ve already missed something when languages you never learned are revived: Scheme, Lisp, Forth, Smalltalk, and Prolog, for example. Where to start? Which language will be best for getting a job? Which is most fun? Most interesting? Most cool?If you program for a living you probably don’t get to pick the languages or tools for your projects. Where’s the fun in mastering Java or Visual Basic or whatever language you have to use at work? It’s no wonder programmers prowl the web reading about Ruby, or try to get some version of Lisp to run when they should be working. The curiosity and restlessness that makes playing with a new language fun also makes programmers lose interest quickly. Just like people upgrading cell phones and digital cameras before they how to use all of the features, programmers lose interest in languages before they have mastered them.
One way to stay interested in a language long enough to master it is to work with programmers who are already experts, on a real project. Work at becoming an expert, not just good enough to do the job. Play with the parts of the language you don’t understand and figure out ways to use those parts in your work. Memorize operator precedence and scoping rules so you don’t have to look them up or write clunky code to protect yourself. Read the source code for the standard libraries. Take charge of some broken or badly-written code, figure it out, then refactor it. Look at other languages to find ideas you can apply to your own work: functional programming, generics, parallelism.