5 ms·

> "$language developer" is only slightly more useful I would argue that this is not a useful distinction at all. Any good developer should be able to pick up a

by rtlfe 6y ago

> "$language developer" is only slightly more useful I would argue that this is not a useful distinction at all. Any good developer should be able to pick up any language quickly. At the companies where I've worked, even the interns have no expectation of knowing the language before they're hired, and the vast majority of them learn quickly enough to ship useful code within their ~3 month internship.

kohtatsu 6y ago
They just meant in terms of "x language is typically used for tasks y, z". Of course you can do most all things in most all languages, but often times you can infer CRUD/web dev from PHP, for example, and would be far less likely to come across a PHP game developer.
fractionalhare 6y ago
> 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.
scarface74 6y ago
Languages are easy. Knowing the underlying frameworks, ecosystem, etc. is what takes awhile. I could (re)learn Java in a weekend, but that doesn’t mean I’m going to be able to write an Android app. Even for backend API development there is a leap from knowing C# to knowing how to correctly use all of the packages that surround it.
- closeparen 6y ago
  APIs are documented (hopefully) and can be rote-learned or looked up. If someone has the general skill of "learning APIs" then they're going to figure out Android or QT or Rails or Spring or whatever the problem requires. Not as quickly as someone who already knows, but I wouldn't doubt their ability to ramp up. I'd be more worried about paradigm shifts like higher order functions, manual memory management, OOP, concurrency (also between "share by communicating" and "communicate by sharing"), glue code vs. algorithm code, monolith vs. microservices, embedded vs. server side.
  - scarface74 6y ago
    There is a lot more that goes into learning an entire stack than “documented APIs”. Are you saying that because I know C# I could go out there and start developing games in no time since Unity is well documented? So you would really hire me to be an Android developer who has only written 20 lines of production code in Java over 15 years ago and the only mobile development I’ve done is on ruggedized Windows CE devices almost a decade ago, over an experienced Android developer? Let’s say I know AWS pretty well (which is the truth I work there as a consultant), and I do most of my AWS related scripting and development on top of AWS in Python. How useful would that combination of knowledge be if you told me to do the same type of thing on Azure or GCP? I wouldn’t even know where to start, I don’t know anything about either. On the other hand, if you told me I had to build the same sort of solution in Rust, a language I’ve never even seen, I’m sure I could pick up the language in a weekend, include the appropriate SDK and be just as efficient as someone who has been working with Rust for years building the same type of solution on top of AWS.
    - 6y ago
jjk166 6y ago
Yeah, imagine if you were a biologist who writes their papers in english and someone expected you to do a little meteorology because they're both natural science and english is a commonly used language in both disciplines.

by rtlfe 6y ago

kohtatsu 6y ago

They just meant in terms of "x language is typically used for tasks y, z". Of course you can do most all things in most all languages, but often times you can infer CRUD/web dev from PHP, for example, and would be far less likely to come across a PHP game developer.

fractionalhare 6y ago

> 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.

scarface74 6y ago

Languages are easy. Knowing the underlying frameworks, ecosystem, etc. is what takes awhile. I could (re)learn Java in a weekend, but that doesn’t mean I’m going to be able to write an Android app. Even for backend API development there is a leap from knowing C# to knowing how to correctly use all of the packages that surround it.

closeparen 6y ago
APIs are documented (hopefully) and can be rote-learned or looked up. If someone has the general skill of "learning APIs" then they're going to figure out Android or QT or Rails or Spring or whatever the problem requires. Not as quickly as someone who already knows, but I wouldn't doubt their ability to ramp up. I'd be more worried about paradigm shifts like higher order functions, manual memory management, OOP, concurrency (also between "share by communicating" and "communicate by sharing"), glue code vs. algorithm code, monolith vs. microservices, embedded vs. server side.
- scarface74 6y ago
  There is a lot more that goes into learning an entire stack than “documented APIs”. Are you saying that because I know C# I could go out there and start developing games in no time since Unity is well documented? So you would really hire me to be an Android developer who has only written 20 lines of production code in Java over 15 years ago and the only mobile development I’ve done is on ruggedized Windows CE devices almost a decade ago, over an experienced Android developer? Let’s say I know AWS pretty well (which is the truth I work there as a consultant), and I do most of my AWS related scripting and development on top of AWS in Python. How useful would that combination of knowledge be if you told me to do the same type of thing on Azure or GCP? I wouldn’t even know where to start, I don’t know anything about either. On the other hand, if you told me I had to build the same sort of solution in Rust, a language I’ve never even seen, I’m sure I could pick up the language in a weekend, include the appropriate SDK and be just as efficient as someone who has been working with Rust for years building the same type of solution on top of AWS.
  - 6y ago

jjk166 6y ago

Yeah, imagine if you were a biologist who writes their papers in english and someone expected you to do a little meteorology because they're both natural science and english is a commonly used language in both disciplines.