During an e-mail exchange with a TechRepublic member, he mentioned that blogs, articles, and magazines aimed at developers seem to fall into two categories: items for beginners ("Hello World" type tutorials) and items for experts (MSDN Magazine).
#1: Learn another language
And when I say "learn another language," I mean really learn it. Learning a language consists of three realms of knowledge: the syntax, the built-in operators and libraries, and "how to use it." The first two are easy; I think that an experienced developer can pick up enough of a language's syntax to maintain code in 30 minutes to a few hours depending upon the language. The operators and libraries are just a matter of slowly accumulating knowledge and being willing to check reference materials until you memorize what you need to know. But it's the third item — "how to use it" — that can only be learned over months of working with a language and that's where the real magic happens. I suggest doing a project that is well suited for that language and doing it in that language's style.
Truly learn another language, and I promise that your abilities as a developer will start to blossom.
#2: Learn advanced search techniques, tactics, and strategies
More and more, being a good developer is not just about your skill, but your skill at finding information. Simply put, modern languages and development frameworks are too large for most people to remember much of them. As a result, your ability to get work done is often dependent upon your ability to perform research. Unfortunately, knowing how to find accurate, high-quality information is more than just heading to TechRepublic for the answer or typing a few words into your search engine of choice.
"Techniques," "tactics," and "strategies" may sound like synonyms, but they are not. The techniques you need to learn are the advanced search systems of your favorite search engine; you need to learn things such as the Boolean operators, how to filter results (negative keywords, domain restrictions, etc.), what role word order plays, and more. So essentially, RTFM.
You should learn tactics such as knowing how to approach any particular search and knowing what you should you actually look for. Errors are easy — just look for the error code — but keyword selection on many searches is much more difficult.
With regard to strategies, you need to learn things such as what search engines to use (hint: general purpose search engines are not always the right answer), which sites to visit before going to a general purpose search engine, and even which message boards to post to for help.
#3: Help others
Teaching others is invariably one of the best ways to learn anything. It is understandable to think that you don't have much to offer because you are relatively new to the development field. That's nonsense. Remember, everything you know you learned from someone or somewhere; so try being the someone that another person learns from. Spend a few minutes a day trying to answer the questions on TechRepublic or another site as best you can. You can also learn a lot by reading other members' answers.
#4: Be patient and keep practicing
Research shows that it takes "about ten years, or ten to twenty thousand hours of deliberate practice" to become an "expert." That's a lot of time. Furthermore, becoming an expert does not always mean doing the same task for 10 years; it often means doing a wide variety of tasks within a particular domain for 10 years. It will take a lot of time and energy to become an "expert"; working as a developer for a few years is not enough. Want to become a senior developer in your early 30s? Either start your education/training sooner or be willing to do a lot of work, reading, and practicing in your spare time. I started programming in high school, and I devoted a lot of off-hours to keeping up with the industry, learning new skills, and so on. As a result, I hit the intermediate and senior level developer positions significantly earlier in my career than most of my peers, which translates to an awful lot of money over time.
#5: Leave your dogmas at the door
Time for some brutal honesty: Beginner developers probably don't know enough to state that there is One Best Way of doing something. It's fine to respect the opinion of a friend or an authority figure, but until you are more experienced, don't claim their opinions as your own. The simple fact is, if you don't know enough to figure these things out on your own, what makes you think that you know which "expert" is right? I know this sounds really harsh, but please believe me; I have met far too many budding developers who had their careers or their growth set back years because they got hung up on some foolish piece of advice or followed some "expert" who really didn't know what they were talking about. A great example of this is the abuse of object-oriented architecture. For example, many beginners read some information about OO, and suddenly the class diagrams to their simple applications look like the Eiffel Tower.
#6: Learn a few advanced ideas in-depth
Much of what goes into being an intermediate developer is having a few concepts that you are really good at working with in code. For me, it is multithreading/parallelism, regular expressions, and how to leverage dynamic languages (and the last two are fading as I get farther away from my Perl history). How did this happen? Multithreading and parallel processing came about because I read articles on it, thought it sounded interesting, and figured it out on my own; I keep writing apps that use those techniques. I had a job that used a ton of regular expressions in Perl. Also, I ended up writing my own e-commerce engine with a template processing engine and built-in database system; then I spent nearly two years working on it.
Find something that has you really hooked. It might be image manipulation or maybe database design or whatever. Even if you're an entry-level developer over all, try to become an expert in at least one area of focus. This will get you into that intermediate level quite quickly, and once there, you will be halfway to expert.
#7: Learn the basic theories underlying your field
If you are a Web developer, read the HTTP RFC and the HTML spec. If you use a code generator, really look at the code it generates; if you use database tools, take a look at the underlying SQL it generates; and so on.
#8: Look at senior developers' code
At your job, take a look at the code the senior developers are writing and ask how and why things were done a particular way. If you can, check out open source projects as well. Even if other developers don't have the best coding habits, you'll learn a lot about how code is written. Be careful not to pick up bad habits along the way. The idea here isn't to just blindly imitate what other developers are doing; it's to get an idea of what works and what makes sense and try to imitate it.
#9: Learn good habits
Nothing marks an inexperienced coder like stupid variable names, poor indentation habits, and other signs of being sloppy. All too often, a developer learned how to program without being taught the less interesting details such as code formatting — and it shows. Even though learning these things will not always make your code better or you a better developer, it will ensure that you are not viewed as an entry-level developer by your peers. Even if someone is a senior developer, when variables are named after their 97 cats or their functions are called "doSomething()," they look like they do not know what they are doing, and it makes their code harder to maintain in the process.
#10: Have fun
Want to be stuck on the career treadmill? Hate your job. What it takes to move up in this business is not merely dogged determination to bring home an ever growing paycheck but an actual enjoyment of your work. If you do not like your work and you are a junior developer, what makes you think that being an intermediate or senior developer will be any better? Change jobs or change careers. On the other hand, if you love the work you are doing, great! I guarantee that you can become a better developer if you keep at it.