[WizardOfNomaha]

In most hiring settings this isn't true though. Language-specific skills actually do matter, for all but entry-level positions at massive tech companies. It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever. Could I get up to speed in those languages in due time? Sure. But if you were on a hiring committee, hiring for a team that works mostly with Java (or whatever) would you rather hire me or the version of me that's had the same amount of experience but with Java?

[outworlder]

> It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever.

It should be.

Picking up language X is very easy for most values of X (more esoteric ones excluded). After you know a few (and the more diverse the set, the less new concepts you'll see), picking up a new one is quick. If it is something like Go, it's a weekend's worth.

Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time. If you are a solo developer, or if the entire team is ramping up at the same time, then it is bad.

But a new, experienced team member, with zero knowledge in the most used language in the team? Sure, why not? They may even bring new skills to an otherwise homogeneous group.

I always let the interviewee pick the language during my interviews. Usually it is something like Javascript or Python. Sometimes it is Bash. I keep waiting for the day someone will offer to do it in Scheme, Haskell, Elixir, Prolog, D, Rust, even Ada. Pseudocode is actually fine too, unless I have a reason to think the individual lacks programming experience.

Whatever you do, DO NOT brand yourself as a X developer, if X is a programming language. I can understand specializations like machine learning. But languages? It's a mere tool, and you need more than one in your toolbox.

[RussianCow]

> But a new, experienced team member, with zero knowledge in the most used language in the team? Sure, why not?

It really depends on how much time you have to wait for a new hire to ramp up before they are useful. If you need immediate help, then hiring someone who doesn't even have experience with your programming language is a complete non-starter. If, on the other hand, you are hiring for the long term and can afford to pay a ~3-month tax for a good engineer for (hopefully) several years, then you are correct and the ramp-up cost becomes pretty insignificant. But don't make the mistake of thinking that this is an exception to the rule—what languages you know absolutely does matter to any company needing to get work done now.

[cup-of-tea]

> Picking up language X is very easy for most values of X

I disagree. If you know Y and you're learning X, it depends much more on the value of Y. If Y is Lisp you will be quite successful at learning any X. If Y is something like C or assembly language, then you will not (it's always easy to spot the C guy who just started using Python etc.)

[Communitivity]

In my experience it is like learning a spoken language. If you know a language in the same family then learning the new language is relatively easier (e.g, Java -> Scala, Lisp -> F#). I also think the ease of learning a language is proportional to the ratio of expressiveness of the language you are coming from to the expressiveness of the language you are going to (e.g., Lisp to F# might have a much easier time than F# to Lisp).

[crdoconnor]

>Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time.

Yeah. As in years. This stuff also changes all the time so requires perpetual learning.

>But languages? It's a mere tool, and you need more than one in your toolbox.

It's not a mere tool and languages are more than just trivially learned syntax. They are the umbrella under which a panoply of tools, approaches, ideas, priorities and culture aggregate.

Sure, you specialization isn't necessarily always the optimal approach and sure there are benefits to the cross fertilization of ideas across community lines. However, being a jack of all programming languages, master of none probably means you'll suck more than a specialist at a lot of stuff.

Moreover, some ecosystems plain suck and avoidance is the sign of a good programmer. Statistically, you're probably a worse programmer if you've used a lot of PHP and better if you've learned rust/F#.

[onion2k]

Language-specific skills actually do matter, for all but entry-level positions at massive tech companies.

Absolutely, which is why I didn't stop at "I am a developer". That "who is good at Python" bit is definitely important.

However, seeing yourself as a "Python developer" rather than "a developer who is good at Python" makes it look like you see every problem as something you'll solve using Python. That's bad. That will put a lot of companies off hiring you (companies that believe in a 'best tool for the job' approach anyway, and those are the ones you probably want to work for).

[crdoconnor]

>However, seeing yourself as a "Python developer" rather than "a developer who is good at Python" makes it look like you see every problem as something you'll solve using Python. That's bad.

If a company didn't hire me because they idiotically interpreted "I am a python developer" to mean "I would try to build a rendering engine in python" then I'd say that's probably a bullet dodged.

I'd interpret it as "I don't build rendering engines but I build other stuff for which python is a good fit", but maybe that's just me being weird.

The trope about great programmers being people who reverse binary trees in their sleep and being able to swap ecosystems at the drop of a hat needs to die. Great programmers specialise.

[thomastjeffery]

Being able to interpret around your words does not make your words inherently better.

You aren't honestly trying to sift out clueless prospective employers out by their ability to parse a title, are you?

The advice here is to put focus on ability to write software, and experience using python as a tool to do so, rather than implying that your ability is limited to python.

[thomastjeffery]

That is true.

What parent was trying to explain is that an individual is not defined by a specific subset of his/her experience.

Just as fluency in Spanish does not make me Hispanic, experience in python does not make me a "python developer". That title puts focus in the wrong place.