3 ms·

> But by their own admission, they were crap at C++. They didn't really know memory management at all, and they didn't really get the whole "ethos" of C++. Tha

by rtlfe 6y ago

> But by their own admission, they were crap at C++. They didn't really know memory management at all, and they didn't really get the whole "ethos" of C++. That seems normal and expected. Why would these people know memory management and c++ "ethos" if they've never worked with c++ in a professional capacity? > Moreover, they periodically tried (and failed) at picking up functional programming. Presumably the reason they didn't learn FP was because there wasn't sufficient motivation and assistance. I work at a company that does all FP and primarily hires people with no FP experience. We have a week-long FP training and tech leads spend a few hours per week with each new person helping them get ramped up. Of the hundreds of people we've hired in the past few years, I've never heard of anybody who failed to learn the language and our codebase style. There are plenty of reasons that certain people haven't worked out, but this is not one.

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

by rtlfe 6y ago

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