As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

Domains are harder to change than frameworks.
–
RigOct 17 '12 at 17:46

1

Just to clarify, my question is not about how difficult it is to learn a new language, framework or domain. The question is, having learned it, but not used it in a workplace context, how difficult is is to convince any employer to hire you for the new language, framework etc.
–
user924731Oct 17 '12 at 17:51

Good programmers should have no troubles switching languages/frameworks beyond a short learning curve. I've done it more times than I can count. But in my experience, it is far easier to do so without changing jobs than to get a new employer to hire you without matching resume experience.
–
Steven BurnapOct 17 '12 at 20:52

3 Answers
3

It is as easy or hard as it is to find an employer that's willing to hire you.

There are enough similarities between the higher level languages (C#, C++, Java) that switching from one to another on a professional basis merely requires some additional ramp up time. Generally, that additional ramp up time is less than the time it takes for a newbie to pick up those techs but is obviously more than for someone who used that feature set elsewhere.

Switching from scripting to programming is a bigger jump due to the scale of the applications involved. And apologies for using imprecise terms there, what I mean is that moving from korn shell scripting to C# and the .NET framework is a much bigger jump than from Java to C#.

Some companies can afford that time. Some can't. Some start off by saying they can't afford that time; find they can't find anyone; and then accept the additional ramp time.

Your ability to show how quickly you ramp up to speed on new projects will be helpful in getting that opportunity to switch over. Your ability to demonstrate programming concepts will also increase your odds.

I think any of these situations can be addressed by considering what happens when you go from doing something familiar for pay to something unfamiliar for pay. You're asking someone to hire you to learn on the job.

In terms of how difficult it is, if you're an entry to mid level programmer whose best asset in terms of hiring companies is the ability to bang out code, it's going to be comparably difficult. If you're a senior to architect to manager level person, it's going to be easier since those roles tend to be more abstract. If you're already a polyglot who has proven the ability to understand and pick up technologies in the past, this helps too.

Following these loose guidelines, it then starts to depend on the hiring company. Are they investing in you for the long haul or do they need to hire someone who can generate code almost immediately? The former is going to be more lenient in letting you learn on the job, but if you're not switching techs, you can have your pick of both kinds.

I guess I'd summarize by saying that things are tradeoffs when you're doing just about anything. If you have a requirement such as "I want to switch technologies to one I don't really know", then be prepared to be flexible on another requirement like "money" or "benefits" or "corporate culture" or "length of job search".

(Though the market is so good for programmers right now that for the time being, you can probably have your cake and eat it too)

A good programmer should be able to adapt pretty quickly to a new language, and most other things are just a matter of getting used to an API of some sort or another. I started in C but when i needed to I dropped in to Assembly, VB, C++ and java and Groovy to solve specific problems or work on new tasks or at different jobs.

The libraries, frameworks and editors you use tend to take less time to get used to--I mean really everything is just an API, once you get it and it's usage you are golden.

These days I often get hung up on the configuration of various frameworks... for me that's been one of the larger problems. It's not that any one is terribly hard, it's that there are so many.
Here are some I've had to deal with in just the past two years--

Where does Tomcat put this file or that and how does it unpack them?

how do you build source in eclipse that doesn't interfere in your ant build

Running 5 apache servers on the same dev box and dealing with the resulting memory issues (A box with 2 JVMs can get to 95% of memory used before it goes bonkers, but when you get up to 5 JVMs it starts getting really funky at like 60-75% memory used level)

Heck even simply setting up a developer box has become a WEEK long process (seriously!)--It used to be simply "Install Eclipse and the JVm"

If you are in a situation where you don't have analysists coming up with requirements, the domain can even be a bigger issue and can take years to get used to.

I guess I'm just saying don't worry much abouth the language or various APIs you use, they won't be your biggest problem.

Heck I've even been hired by people who really didn't care what language I used previously as long as I had the right skills, for me the best way to learn a new language is on the fly, using it.