> I find that I often have a 2 week ramp up for any given programming language.

I agree that a competent, experienced developer can do this. What's worth noting, however, is that it takes two weeks to cross the bar of "can contribute code in this language that produces deliverable results". But two weeks cannot get you across the bar of "can contribute robust, maintainable code in this language".

Even though you are not a beginner to programming, you are a beginner to the language and its ecosystem and so will still make some significant newbie mistakes. Ruby on Rails is a good example of this: half of being good at RoR is being a good programmer, the other half is memorized knowledge of the idioms and patterns of the framework and community.

> But two weeks cannot get you across the bar of "can contribute robust, maintainable code in this language".

Unfortunately, this is so true and yet so difficult for people to realize and understand.

I've seen in real life wherein somebody hired at a supreme decision-making authority comes in and says "We'll rewrite everything in language X". Existing folks in the team quickly start ramping up on the language and simultaneously writing production code. Much of the code thus written tends to be pathological.

> But two weeks cannot get you across the bar of "can contribute robust, maintainable code in this language"

So do 10 years of experience. "robust, maintainable code" is just coding convention that a group of developers comes up with. The convention can vary from one team to another.

I went from Perl to Python / Django. I could write stuff straight away as the languages don't differ too much, but took me 6 months to write decent Django code, and longer to produce efficient, nice django-esque code using best practices.

The silly thing about companies being so obstinate about hiring someone with experience in the exact stack they use is that often times job reqs go unfilled for many weeks or even months. The result is that they end up wasting a lot more time with an unfilled position than if they had just hired that person who needed 2 weeks or so to ramp up.

Letting a developer or engineering job go unfilled for months is nothing, at least in my experience. I've seen a lot of jobs go unfilled for years while the company tried to find a unicorn to fill it, while at the same time priding themselves for being so picky and demanding excessive levels of experience, "full stack" experience, and "culture fit."

> THIS. After learning a few languages and paradigms, I find that I often have a 2 week ramp up for any given programming language.

That sounds about right for many programming languages. My personal average from "having heard of the language" to "writing non-trivial programs" (let's say, something that is able to talk to a REST API and do some processing) is a non-stop weekend programming session. [1]

The time-consuming part is learning the libraries and how to write idiomatic code. That can take months or years (C++, I'm looking at you).

Still, knowledge of a specific programming language is usually the wrong thing to optimize for. Perhaps a more useful metric was the number of programming languages one has been exposed to? That is more useful, as once you have learned a bunch, you've seen most of the important concepts, and can focus on whatever subset is implemented by the new language.

[1] Except Haskell. That's a nut I still haven't cracked.

There are also developers who view Java as the one true programming language who are either unwilling or unable to learn anything else. I know they exist because I've worked with many over the years. Javascript seems to be accumulating people of a similar mindset these days as well.

Filtering these clowns out should be rather simple (make sure their resume mentions at least a few different languages and ask the right questions during a phone screen), but most companies aren't willing to expend the effort.

JavaScript has both the "JS can do everything" folks and the "JS was a terrible mistake, only idiots use it" folks.

How about "JS was a terrible mistake that can do everything"?

True.

One should also be vary of the other extreme: There are people that switch their favorite language every three months, and insist that they use the latest one for their day job. If you allow it, it may lead to lot of wasted time, small wars within your team, and so on.

I wonder if part of this is because of pressure from investors. I heard an investor once comment about how they don't want to pay for a team to learn on the job, which I found ironic given the VC space implicitly invests in innovation, which is creating new opportunities that have lots of unknowns.

You may be able to learn a new language in 2 weeks, but very few people have this ability. I think a lot of developers learn the syntax quickly, but don't "grok" the differences in a language for some time. I still see people trying to write JavaScript in the same way they would write Java, and they wrote their Java in the same way they would write a Basic program (procedurally). It reminds me of a quote I am fond of: "The determined Real Programmer can write FORTRAN programs in any language." -- Ed Post

I prefer Alan Perlis' advice: "A language that doesn't affect the way you think about programming, is not worth knowing."

Edit: I categorize myself as one of the programmers who can learn syntax, but it takes me much longer to understand the language.

While this is true, sometimes knowing the syntax and basic familiarity with the toolchain can be good enough to start contributing. It's just that help from peers becomes very important - good code reviews, etc and not every organization can facilitate this.

Almost all the languages you'll find on those "requires 10 years of experience on language X" ads are in that "not worth knowing" set.

So what is suggested for developers running into this situation? Not all of us live in dense, major cities where it's easier to find a cross-section of all stacks, but most of us with experience can ramp up into a new stack based on similar paradigms we already use regularly.

That cuts both ways, if your an employer out in the sticks then you won't be able to be so picky about skills.

Find better employers.

The game these employers have set up is unwinnable. Don't play it.