6 ms·

> Any good developer should be able to pick up any language quickly. I see this repeated very often without support, and I think it should be challenged. In my

> Any good developer should be able to pick up any language quickly. I see this repeated very often without support, and I think it should be challenged. In my experience there are cases where it's true, and cases where it isn't. Actual example: I have met highly competent software engineers who were (primarily) excellent Python programmers. They knew OOP well, they didn't typically over-abstract, but they could still leverage modular code for reusability, they tested early and often, they could dig into an existing codebase and maintain it, they could critically and constructively review others' code, they had a deep knowledge of the Python standard library and various domain-specific frameworks, etc. They were really good at all of this. 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++. Moreover, they periodically tried (and failed) at picking up functional programming. Now I believe if they were sufficiently motivated they could eventually pick these languages up. But they wouldn't "quickly" ramp up on a production codebase written in a C++ or Clojure. The idea that they're not a "good developer" because they wouldn't be able to quickly become productive in one of these radically different languages is therefore incongruous to me. I'm sure they could dive into a Ruby or JavaScript or even Java codebase. Or maybe C++ if it was strictly modern, 17+ and avoided raw pointers like the plague. But in general, no. It would take a lot of time, because some languages come with a lot of baggage that aren't just about the syntax. For someone who had always relied on Python's PIP, for example, the process of vendoring and importing C++ header libraries is already an obstacle. The reason I'm going on about this is because it seems like received wisdom and is often stated as an accepted aside, but I really think it needs more nuance. Otherwise we run the risk of defining "good" software engineers by what is perhaps just a no true scotsman.

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
ilonski 6y ago
The trick here is to know which skills you need and which ones cross over. There are lots of families of languages, and maybe that's a better way to evaluate. If you need a C programmer, then you want to know they can manage memory. If you want a Haskell programmer, you want to know they can handle difficult functional abstractions. So there are certainly cases where you need to worry whether they have the transferrable skills, but it doesn't necessarily mean they have to know your exact language.
mkoubaa 6y ago
I think you'll find many professional C++ developers say they are crap at C++. It isn't a reflection of their abilities
- rtlfe 6y ago
  That's true. A large proportion of people who are extraordinarily good at anything will never acknowledge how good they are but instead will talk about how much there is left to learn.
- markrages 6y ago
  C++ is a such a huge and sprawling language. Most people deliberately or accidentally choose a subset of the language to program in.
- blub 6y ago
  Maybe they say that they don't master the language. If they're crap at it they'd either get a different job or eventually get fired.
  - mkoubaa 6y ago
    Effectiveness at using a language =\= effectiveness at implementing useful things in it
closeparen 6y ago
I think we conflate the language learning curve with the problem domain learning curve. Is what throws people about C++ actually the language, or is it "thinking with pointers" and "concurrent programming with shared memory"? My CS education taught me those things (at least to a beginner level) in C. I suspect this would give me a major advantage at "C++" over someone who had never seen them. Even though we are both newbies to C++ itself. Dependency management is a chore. Chores are different across language ecosystems, but it doesn't exactly stretch your mind to learn how they're done in different areas. Whereas minds really do catch on problems like pointers, locks, recursion, etc. and we can legitimately wonder whether someone is going to become okay at them anytime soon, or ever. I saw friends wash out of CS over these topics.

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

ilonski 6y ago

The trick here is to know which skills you need and which ones cross over. There are lots of families of languages, and maybe that's a better way to evaluate. If you need a C programmer, then you want to know they can manage memory. If you want a Haskell programmer, you want to know they can handle difficult functional abstractions. So there are certainly cases where you need to worry whether they have the transferrable skills, but it doesn't necessarily mean they have to know your exact language.

mkoubaa 6y ago

I think you'll find many professional C++ developers say they are crap at C++. It isn't a reflection of their abilities

rtlfe 6y ago
That's true. A large proportion of people who are extraordinarily good at anything will never acknowledge how good they are but instead will talk about how much there is left to learn.
markrages 6y ago
C++ is a such a huge and sprawling language. Most people deliberately or accidentally choose a subset of the language to program in.
blub 6y ago
Maybe they say that they don't master the language. If they're crap at it they'd either get a different job or eventually get fired.
- mkoubaa 6y ago
  Effectiveness at using a language =\= effectiveness at implementing useful things in it

closeparen 6y ago

I think we conflate the language learning curve with the problem domain learning curve. Is what throws people about C++ actually the language, or is it "thinking with pointers" and "concurrent programming with shared memory"? My CS education taught me those things (at least to a beginner level) in C. I suspect this would give me a major advantage at "C++" over someone who had never seen them. Even though we are both newbies to C++ itself. Dependency management is a chore. Chores are different across language ecosystems, but it doesn't exactly stretch your mind to learn how they're done in different areas. Whereas minds really do catch on problems like pointers, locks, recursion, etc. and we can legitimately wonder whether someone is going to become okay at them anytime soon, or ever. I saw friends wash out of CS over these topics.