How easy is it to change languages/frameworks professionally? [closed]

Question

Forgive me for asking a career related question - I know that they can be frowned upon here, but I think that this one is general enough to be useful to many people.

My question is: How easy/difficult is it to get a job using language/frameowork B, when your current job uses language/framework A?

e.g. If you use C#/ASP.NET in your current job, how difficult would it be to get a job using python/django, or PHP/Zend, or whatever (the specifics of the example don't matter).

Relatedly, if you work in client side scripting, but perhaps work on server-side projects in your own time, how difficult would it be to switch to server-side professionally?

So, to sum up, does the choice of which languages/frameworks use at work tend to box you in professionally?

Answer 1

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.

Answer 2

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)

Answer 3

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
• debugging on eclipse & tomcat
• Writing ant config files (can be quite complicated!)
• Maven (Gak!!)
• Apache server clusters
• IPV6 trying to bind to stuff on newer systems (and slowing things down)
• 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.