5 ms·
Well what I was driving at (and again, by this person's self-assessment) is that you wouldn't learn all the meta of a language like C++ in a couple of months. I
by fractionalhare 6y ago
Well what I was driving at (and again, by this person's self-assessment) is that you wouldn't learn all the meta of a language like C++ in a couple of months. I do believe anyone who can code is capable of learning it eventually, but I have never seen someone ramp up on that language from an interpreted one quickly. Which is not to say it's a badge of honor to code C++, it just is what it is.
I think if you talk about the narrow scope of learning a language's syntax for greenfield projects, it might be true that people who know one language well can quickly learn any other language. But some languages force you to learn so much other "stuff" before you can be professionally productive in it, and I think there's some danger in just repeating that any good developer can pick up any language quickly.
My bottom line point: if I saw a developer who I knew to be very competent fail to quickly ramp up on a very different language in a professional setting, I probably wouldn't revise my assessment of them being "good."
- rtlfe 6y ago> if I saw a developer who I knew to be very competent fail to quickly ramp up on a very different language in a professional setting, I probably wouldn't revise my assessment of them being "good." For me, it would depend on what support systems are in place. If they're asked to learn on their own with no assistance, sure this failure doesn't mean much. But if they're put in a team full of experts on the new language who are eager to help them learn, and they still fail, then yes I'd update my opinion.
- jarvuschris 6y ago> you wouldn't learn all the meta of a language like C++ in a couple of months. I think this reinforces OP' point though: what we really need are descriptions more specific than "software developer" but less specific than "$language developer" > some languages force you to learn so much other "stuff" before you can be professionally productive in it And it's exactly that stuff that should be the focus of describing the role. e.g. you're looking for a low-level network software developer with proficiency in memory management. If you were recruiting someone to help you with a Go or Rust codebase in that domain, you wouldn't pass over someone with a ton of relevant experience via C++ who hadn't spent much time with Rust/Go yet. Focusing on the language rather than the skills/application (even when there's a heavy correlation between the language and associated skills) excludes good candidates and includes irrelevant ones