Aim for learning at least one language/technology from each major "paradigm". As for what you decide to learn when, just go with whatever is most applicable to things you're actually trying to do. If nothing is applicable, go with whatever you find yourself thinking about the most.

Becoming a great programmer is a multiple-decade process. Becoming a competent programmer is an at-least-a-few-years process.

I aim for a new paradigm, or technology in an area I'm not very familiar with at least once a year. This is enough time to get more than a "tutorial-level" overview of the topic, allowing my newly gained knowledge to assist me when using other, more familiar, technologies. Sometimes the new stuff becomes the normal stuff as well.

Don't be afraid to determine what to learn first by dipping your fingers in everything until you see what coats your hands and what runs off. Being a "greedy programmer" is not necessarily bad. Just don't be a greedy and impatient programmer.

Ah the old Generalist vs Specialist debate again. Here are a few previous questions covering that ground:

• Should developers be specialists or generalists? ^[1]
• Technical generalist vs. specialist: a job hunting problem ^[2]
• Should a developer know perfectly one language or know fairly well multiple languages? ^[3]

Part of this is about knowing what you want in terms of what do you like to do, what are you good at doing, and all that basic stuff. Some people would rather get a little of a lot of things and others would rather go way deep in one specific thing. Each has its own rationale and logic for being a good thing, so why can't we just live and let live?

You're going to get a lot of advice telling you to try and identify the languages which will be good for your future career. I'm going to disagree with this and call it poppycock.

You cannot predict what languages, concepts, techniques, etc. will be popular and important in the future. Anybody who says they can is either foolish or selling you something. Languages and paradigms and techniques and libraries and frameworks and and and come out of nowhere and into the forefront of technological thought in a veritable blink of an eye (despite there being essentially nothing new since about the mid-eighties).

I've lived through the shift to structured programming, the shift to object-oriented programming and am living through the shift to functional programming now (assuming it has legs). Along the way I've lived through methodology fashions, toolkit fashions and coding/testing technique fashions that get paired with these. I still can't tell you what the Next Big Thing will be because nobody knows what will be important tomorrow. For all we know logic programming may be the Next Big Thing and you'll have to brush up on your Prolog or Mercury or the like.

So...

What to learn? Learn what you need now for your job. Learn what you think you may need tomorrow for your career. And learn something entirely alien and different once per year at least (maybe even once every six months) to keep your mind flexible so that when (not if!) you get blind-sided by future developments you can quickly pick up what you need to know.

I would say consider where you want your career path to go as one way to decide. That always helps me decide which languages to focus more of my energy on. I wouldn't let current work loads drive what you focus on. If you did you could end up doing the same thing for 5-10 years and realize that you missed a lot of things that could have contributed a lot to your growth.

Also I always tend to think patterns and disciplines are a much better use of your time than particular languages. Languages come and go. But a good design pattern can live on through nearly any language.

That's my thoughts!

My advice is to look at what skills will aid your current skill set the most, depending on the industry you're in specifically. Prioritize based on how quickly you can become comfortable with the subject and how well each augments your current skill set.

As to how deep to learn them... learn them until you're comfortable putting them down. Then allow practice to take over the learning. If you learn something well enough to use it practically, you'll learn the rest passively as you practice.

I'm a game developer first and foremost. These are my fields and intended learning.

Main Fields:

• Rendering
• Animation
• Artificial Intelligence

Learning:

• Unreal Development Kit
• Lua
• Python
• Inverse Kinematics
• Flash/ActionScript
• Unity

I'm prioritizing them as such because many games these day's use the Unreal Engine. Lua and Python are often used as scripting languages for AI. Inverse Kinematics is present in just about every game these days, even in plenty of 2D games. Flash/ActionScript is something I'd like to do to make simple game prototypes before developing them for some income on the side. Unity is a toy interest, just to see what kind of development environment it is. I'm uncertain just how useful skills with it will really be.

do you REALLY want to learn all those frackin topics??

i've found that learning the latest THANG will always get in the way of getting an app DONE. And have found getting apps done way more important in the long run.

to me, the measure of a developer is the apps he's written. Use whatever language you want, but if the app ain't done yet, you ain't a dev yet.

Learn what you need for a project and finish it to completion while also doing some fun stuff on the side. You can only really learn by doing. Make sure you pay attention to developing your problem solving abilities rather than just learning technologies. Technologies will come and go but a developer is someone who can solve real problems using appropriate technology for the problem at hand. Peter Norvig has a nice article about what to focus on that I think is right on the mark: http://norvig.com/21-days.html. You'll see from the article that you should be patient and focus on what is fun to you and what your friends or community of support can reinforce for you. Lastly, I would suggest developing at the same time a deepening understanding of the ideas and science in computer science.

It's OK to have a long list of things to learn.

I think one should follow their instincts as to what to go for and what to accept when faced with opportunities.

..and one should try being productive ^[1].

..and don't forget to add computer science to your list. There are good free resources out there ArsDigita University ^[2] being one of them.

General Advice:

1. Focus on making software, not money. Adopt the ethos of a craftsman. View technologies and languages as tools of your trade. Master the tools you use, and realize that you'll need many to do the job well.
2. Try to find a job where you can complete products, components, or systems very regularly, to gain the freedom to move from domain to domain more frequently.
3. Avoid all techno-religion. It's bad.
4. When you learn a new language or technology, make sure you understand if both from the top-down and from the bottom-up. This means comprehending the philosophy that inspired the innovation as well as the low-level mechanics of why it actually works (or doesn't).
5. Don't ignore the people and process aspects of software development. Learn why the Prima dona is poison and the Waterfall is for those who love barrels.
6. Ascribe value to what you've built, not what you know.
7. Avoid high-level languages until you've mastered a low-level one (such as C, Obj-C, C++, etc.). High-level constructs obscure what's really happening in SW and HW.
8. Do what you love, and don't let yourself be promoted out of doing what you love.

It appears that everyone has advice for you, I can't tell you what will work for you, only what works for me. I'm ADD, I'm a C/C++ guy with a specialty in GPU coding environments.

I find that if I try to take in several languages at once, my mind is too easily distracted and I accomplish nothing. But if I focus on one and only one thing, it becomes boring and borders on torture to hold my mind to the grindstone (and make progress).

So personally, I've developed a queue where I'm working on two or at most three projects. I'm able to focus and make progress. I also have one or two things that I'm toying around with -- to take the edge off of a bad Monday (whilst still making progress on something).

Since we're all posting on Stackoverflow, my guess is that most of us agree with the mantra from "Joel on Software" that the most successful programmer is the one who is (1) smart and (2) get's things done.

With a little soul searching, I'm sure that you'll uncover a balance where you can continue to learn and make progress instead of being inundated by a million possibilities or being bored with a single course of action.

Ps. If you haven't read it, I liked http://www.amazon.com/Smart-Gets-Things-Done-Technical/dp/1590598385 ^[1] but I feel it's more a bathroom reader than the business guide it claims to be.

PPs. I have to inject one small bit of advice: if you study and study and study and become really good at hammering, then everything will look like a nail.

well, I know a say:
Learn something about everything and everything about something.

that means if you are an Asp.Net Developer you should know everything about Asp.Net such as:
Master pages, Themes, Profiles, Authorization and Authentication,
Web Forms, Server Controls, State Management ... etc

but you don't have to have a deep knowledge about how IIS works !!
but if you know headnotes about that, it would be great.

however, there is a Headlines every programmer (of any language) should know, such as Design Patterns, Application Architectures, Code conventions, UML Language... etc

and i can give you an example of my self, i like anything concerned with graphics, such as Game Programmer, or UI Designer. and i found that C# language fits for Windows Controls, or even Web Controls. so i am trying to be professional in C#, and C# can also be used in game development.

I am a perpetual learner and one of the sad impatient and greedy programmers. I work in spurts and collaborate with a lots of people mostly on Open Source projects and get a small bug/feature through. This does not make me a 9-5 developer but a troubleshooter.

How well this Jack-of-all-trades approach works for you will depend on the variety you have in your industry and the kind of stability you are aiming for. I have had language discussions and I believe we are moving towards fewer system programming languages and more dynamic high level languages which operate on a set of virtual machines/runtimes.

Sorry for the blathering, but I have chosen to go the learn everything that you encounter route and it has worked for me so far.

Learn just enough about each skill to know what it's good for. What are it's strengths and weaknesses? What are the alternatives?

Next, pick a small project that is a good fit for one or two of these new skills. First-hand experience is the best way to learn! After finishing the project, reflect on your experience. Did you enjoy playing around with the new skill? If so, this might be something to pursue further. If not, no big loss, the project was just a small experiment.