4 ms·

No, just hire a "programmer". It really doesn't take long to get up to speed in a new language and can make it more fun, adding to motivation. In any other prof

by opk 8y ago

No, just hire a "programmer". It really doesn't take long to get up to speed in a new language and can make it more fun, adding to motivation. In any other profession job adverts don't specify the exact make and model of tools being used so why is it always required with programming?

krapp 8y ago
>No, just hire a "programmer". It really doesn't take long to get up to speed in a new language and can make it more fun, adding to motivation. It doesn't take long to learn the absolute minimum of many languages, but that might just give someone just enough knowledge to be dangerous, not useful. I would not, for instance, assume that my knowledge of javascript more or less prepares me to write banking software in COBOL or drivers in C, even if javascript and C share a lot of common syntax. > In any other profession job adverts don't specify the exact make and model of tools being used so why is it always required with programming? Because "programming" is not the profession. Programming specific applications in specific languages that meet specific business needs is the profession - and the necessity for domain knowledge beyond the bare minimum required to produce correct syntax is always more important than the language itself.
- sheepmullet 8y ago
  > and the necessity for domain knowledge beyond the bare minimum required to produce correct syntax is always more important than the language itself. I can't help but feel you are agreeing with the parent poster. In your examples you changed the domain. The parent was talking about the shift in language being the least important factor. It's not entirely true but as a web dev I have written a web app in x86 assembler and cgi-bin without too much trouble. It took longer but I never really felt stuck.
  - carlmr 8y ago
    Exactly, it's a classic rhetoric device to destroy an argument by extending it so much that it sounds silly and addressing the silly proposition instead. There are some languages which are very interchangeable where someone from a similar family will be able to get up to speed quickly. e.g. C# developers can be hired for F#/Java/Scala/Kotlin/... positions. They're all GC'd, statically typed and don't require much familiarity with computer architecture. C and C++ devs can be hired for Rust positions, it's both non GC and requires some understanding of what you're doing with your memory, even if Rust is taking your footguns away. Sure, I wouldn't hire a JavaScript developer to do C, because they can do a lot of damage there. But I'd consider a C dev for a JavaScript position, even though I'd have to ask them why they want to do that to themselves. Levels of abstraction might be a better "metric". ASM < C/C++ < ADA, Rust < C#, F#, Java, Scala, Kotlin < Python, JavaScript, Perl < DSLs < GUIs It's easy to move up in the abstraction layers. It's harder to move down, because you have to think about things you haven't thought about before.
    - sanxiyn 8y ago
      > C and C++ devs can be hired for Rust positions In my experience, this is very untrue. Knowing C++ does not make learning Rust any easier than knowing Java.
      - carlmr 8y ago
        I find it does, at the very least familiarity with RAII concepts and smart pointers will make the whole borrow checking business seem very familiar.
    - gkya 8y ago
      The domain is more important, I think; i.e. you can hire a web dev to work with almost any language/framework, but you may not hire a Django dev for a statistics heavy project written in Python.
      - carlmr 8y ago
        Yeah, that's true. For that statistics project I'd look at their academic background. If there's not much math in what they studied I wouldn't consider them.
    - krapp 8y ago
      > Exactly, it's a classic rhetoric device to destroy an argument by extending it so much that it sounds silly and addressing the silly proposition instead. That's not what I was attempting to do. > Sure, I wouldn't hire a JavaScript developer to do C, because they can do a lot of damage there. But I'd consider a C dev for a JavaScript position, even though I'd have to ask them why they want to do that to themselves. But it's a problem either way. A C developer likely is going to want Javascript to work like C, and they're going to hate that it doesn't, and they're going to write bad Javascript as a result. And understanding modern Javascript means understanding the DOM and how to efficiently interact with it, and the whole horrible mess that is NPM, and compile-to-js languages. My argument is that outside of a textbook, the domain and the language seem to be inseparable, or at least very tightly coupled. Abstraction is one dimension (and I'm not entirely sure it's true that it's easy to move up, since abstractions carry their own debt) but it's likely not one that really matters to a business.
- deleted 8y ago
  [deleted]
camgunz 8y ago
The language itself is (usually) the easy part. If you need a senior frontend engineer, JavaScript knowledge is table stakes. You need someone who can collaborate with product and design, and work with the engineering team on platform and implementation decisions. If you need a senior backend engineer you need someone who's really familiar with server side APIs, database behavior, and data model patterns who can advise the product team on what is reasonably possible and what is practically impossible. And these are just the baselines; we're not talking about emergencies, outages, modern software development (continuous integration, testing, deployment, etc.), or "intangibles" like attitude. Basically that's why hiring engineers is so hard. There are 1000 variables and really they're all important.

by opk 8y ago

krapp 8y ago

>No, just hire a "programmer". It really doesn't take long to get up to speed in a new language and can make it more fun, adding to motivation. It doesn't take long to learn the absolute minimum of many languages, but that might just give someone just enough knowledge to be dangerous, not useful. I would not, for instance, assume that my knowledge of javascript more or less prepares me to write banking software in COBOL or drivers in C, even if javascript and C share a lot of common syntax. > In any other profession job adverts don't specify the exact make and model of tools being used so why is it always required with programming? Because "programming" is not the profession. Programming specific applications in specific languages that meet specific business needs is the profession - and the necessity for domain knowledge beyond the bare minimum required to produce correct syntax is always more important than the language itself.

sheepmullet 8y ago
> and the necessity for domain knowledge beyond the bare minimum required to produce correct syntax is always more important than the language itself. I can't help but feel you are agreeing with the parent poster. In your examples you changed the domain. The parent was talking about the shift in language being the least important factor. It's not entirely true but as a web dev I have written a web app in x86 assembler and cgi-bin without too much trouble. It took longer but I never really felt stuck.
- carlmr 8y ago
  Exactly, it's a classic rhetoric device to destroy an argument by extending it so much that it sounds silly and addressing the silly proposition instead. There are some languages which are very interchangeable where someone from a similar family will be able to get up to speed quickly. e.g. C# developers can be hired for F#/Java/Scala/Kotlin/... positions. They're all GC'd, statically typed and don't require much familiarity with computer architecture. C and C++ devs can be hired for Rust positions, it's both non GC and requires some understanding of what you're doing with your memory, even if Rust is taking your footguns away. Sure, I wouldn't hire a JavaScript developer to do C, because they can do a lot of damage there. But I'd consider a C dev for a JavaScript position, even though I'd have to ask them why they want to do that to themselves. Levels of abstraction might be a better "metric". ASM < C/C++ < ADA, Rust < C#, F#, Java, Scala, Kotlin < Python, JavaScript, Perl < DSLs < GUIs It's easy to move up in the abstraction layers. It's harder to move down, because you have to think about things you haven't thought about before.
  - sanxiyn 8y ago
    > C and C++ devs can be hired for Rust positions In my experience, this is very untrue. Knowing C++ does not make learning Rust any easier than knowing Java.
    - carlmr 8y ago
      I find it does, at the very least familiarity with RAII concepts and smart pointers will make the whole borrow checking business seem very familiar.
  - gkya 8y ago
    The domain is more important, I think; i.e. you can hire a web dev to work with almost any language/framework, but you may not hire a Django dev for a statistics heavy project written in Python.
    - carlmr 8y ago
      Yeah, that's true. For that statistics project I'd look at their academic background. If there's not much math in what they studied I wouldn't consider them.
  - krapp 8y ago
    > Exactly, it's a classic rhetoric device to destroy an argument by extending it so much that it sounds silly and addressing the silly proposition instead. That's not what I was attempting to do. > Sure, I wouldn't hire a JavaScript developer to do C, because they can do a lot of damage there. But I'd consider a C dev for a JavaScript position, even though I'd have to ask them why they want to do that to themselves. But it's a problem either way. A C developer likely is going to want Javascript to work like C, and they're going to hate that it doesn't, and they're going to write bad Javascript as a result. And understanding modern Javascript means understanding the DOM and how to efficiently interact with it, and the whole horrible mess that is NPM, and compile-to-js languages. My argument is that outside of a textbook, the domain and the language seem to be inseparable, or at least very tightly coupled. Abstraction is one dimension (and I'm not entirely sure it's true that it's easy to move up, since abstractions carry their own debt) but it's likely not one that really matters to a business.
deleted 8y ago
[deleted]

camgunz 8y ago

The language itself is (usually) the easy part. If you need a senior frontend engineer, JavaScript knowledge is table stakes. You need someone who can collaborate with product and design, and work with the engineering team on platform and implementation decisions. If you need a senior backend engineer you need someone who's really familiar with server side APIs, database behavior, and data model patterns who can advise the product team on what is reasonably possible and what is practically impossible. And these are just the baselines; we're not talking about emergencies, outages, modern software development (continuous integration, testing, deployment, etc.), or "intangibles" like attitude. Basically that's why hiring engineers is so hard. There are 1000 variables and really they're all important.