9 ms·

Hiring Kotlin devs is easy because you can just hire open minded Java devs.

TillE 4y ago
Seriously, there are so few circumstances where a good developer absolutely requires deep experience in a specific language (or framework) on day one. Smart people can learn, and they can learn pretty quickly if it's not radically different. I'm currently doing a ton of C# work and it's great - my relevant professional background is basically all C++, with some Java in the very distant past.
- RhodesianHunter 4y ago
  I think it really depends. If all you're doing is slinging JSON over an API then sure. If you're dealing with concurrency and distributed systems at medium to high scale you really want your senior people to be familiar with the language.
  - jonathankoren 4y ago
    Yeah, but you don't need that many to start. That knowledge will spread rather rapidly to where it's needed.
    - egeozcan 4y ago
      But that has also the danger of forming islands (mortgage code) which can be maintained by some (or, one) specific engineers.
      - jonathankoren 4y ago
        That can be mitigated by hiring senior engineers that understand engineering leadership, and having competent engineering management to specifically encourage knowledge transfer. It’s not really that hard.
  - FpUser 4y ago
    >"If you're dealing with concurrency and distributed systems at medium to high scale you really want your senior people to be familiar with the language." I've written my first application level thread/concurrency library for DOS in the 80s. So you can count me as experienced. In my opinion as long as one is senior developer and knows the subject language does not mean fuck all as long as it adequate and language / libraries support needed primitives. I've written distributed middleware with multithreading / concurrency in many languages including ones I did not know before starting the project.
    - daguava 4y ago
      Time doesn't mean experienced.
      - FpUser 4y ago
        You can challenge anyone with this type of arguments. I was doing this kind of programming and delivering successful solutions since the 80s. If you chose to doubt my expertise it is your right. Does not mean your opinion has a shred of truth in it.
      - necovek 4y ago
        While you are in general right, GP specificaly has relevant experience for a long time, when time does equal experience.
  - baq 4y ago
    I’d argue the language matters even less as folks with true experience in distributed systems know that the real problems arise between thread/ process/host boundaries which are mostly language-agnostic. IOW you really want senior people, full stop.
  - necovek 4y ago
    On the contrary, I think that people familiar with generic concurrency and distributed primitives will easily transfer their knowledge between languages (I mean, a race is a race, and starvation is starvation...), whereas you can be very senior in a language yet never experience the edge cases of parallel programming. Sure, each language has different tools to solve corresponding issues, but I prefer to understand the problem I am solving to intimately knowing the tools I need to use. Ofc, having both is perfect!
    - pjmlp 4y ago
      Unless they have experience in the language runtime handles them, and how they might differ across implementations, they are in for a surprise when debugging parallel code.
- doctor_eval 4y ago
  Yeah, I mean I hired a great Java dev to do Go work and she picked it up in 3 months... but I knew she was awesome, so I wasn't worried about it at all. But hiring someone you don't know, which is typical ... retraining in a new language feels like it surely adds to the already substantial risk of hiring.
- egeozcan 4y ago
  I think the same as you, but let's admit that C# is one of the easiest languages to get into, especially with the magnificent tooling.
  - weego 4y ago
    I think everyone in this chain should admit that hiring the kinds of developers you can 'throw x language book at' and a week later you have a competent x lang developer is an incredibly expensive and time consuming processthat most companies will never be able to afford. Even if you can, you then have to solve the issue of keeping a department stocked full of senior devs happy when you have limited promotion/perk/raise options and so churn will likely be relatively high even in a healthy environment. It's a nice fantasy view of the market as an ideal world simulation but does not reflect the reality of hiring software engineers.
    - jen20 4y ago
      Surely the other solution is to improve the work environment such that it’s possible to hire the people you aspire to hire…
    - jackcviers3 4y ago
      You can't buy a book, keep it on a shelf, lend it to new hires, and afford to have an employee take a week out of being productive to learn something? Or you can't afford salaries for a company of people who have more than 5 years of development experience? Both sound like major dysfunctional problems.
      - RhodesianHunter 4y ago
        No one learns a new language effectively in a week.
ch4s3 4y ago
You can hire any senior dev and give them the elixir book and a week to read it. You can also pick up someone junior who hasn’t learned anything wrong and coach them for a few months. I’ve successfully done both. The org I work in was one of the Elixir lang case studies and we still love using it, and have very little trouble hiring. It would be different if we had to hire 50 devs in less than 6 months, but we just don’t need to do that.
- Apocryphon 4y ago
  Elixir is a functional language, which is definitely a less common paradigm than OO languages like Java, which Kotlin is very similar to. Plus you can hire Android devs.
  - ch4s3 4y ago
    Yeah of course, but the FP stuff is not very complicated in Elixir land. The heady stuff from ML family languages just isn’t there. The process model takes some time to adjust to, but a lot of JVM folks have used akka which is inspired by the BEAM. The tooling an docs all guide you in the right direction and usually code in the wild aims to be straightforward. I’ve really never had trouble onboarding people to Elixir unless they had started learning it solo as a Ruby dev, then they typically have to unlearn some stuff.
  - jrvarela56 4y ago
    Is this true anymore? I'm biased by HN content but feel like I've been hearing non-stop about FP for the past 10 years.
    - jedberg 4y ago
      You're hanging around crowds that talk about FP. :) Right now I'm working with a team where we're trying to introduce FP and reactive programming, and most of them have never heard of either one, or if they have, have never really used it.
      - 4y ago
SergeAx 4y ago
Even better: you can just hire Android devs who are fed up with client side programming.

Seriously, there are so few circumstances where a good developer absolutely requires deep experience in a specific language (or framework) on day one. Smart people can learn, and they can learn pretty quickly if it's not radically different. I'm currently doing a ton of C# work and it's great - my relevant professional background is basically all C++, with some Java in the very distant past.

RhodesianHunter 4y ago
I think it really depends. If all you're doing is slinging JSON over an API then sure. If you're dealing with concurrency and distributed systems at medium to high scale you really want your senior people to be familiar with the language.
- jonathankoren 4y ago
  Yeah, but you don't need that many to start. That knowledge will spread rather rapidly to where it's needed.
  - egeozcan 4y ago
    But that has also the danger of forming islands (mortgage code) which can be maintained by some (or, one) specific engineers.
    - jonathankoren 4y ago
      That can be mitigated by hiring senior engineers that understand engineering leadership, and having competent engineering management to specifically encourage knowledge transfer. It’s not really that hard.
- FpUser 4y ago
  >"If you're dealing with concurrency and distributed systems at medium to high scale you really want your senior people to be familiar with the language." I've written my first application level thread/concurrency library for DOS in the 80s. So you can count me as experienced. In my opinion as long as one is senior developer and knows the subject language does not mean fuck all as long as it adequate and language / libraries support needed primitives. I've written distributed middleware with multithreading / concurrency in many languages including ones I did not know before starting the project.
  - daguava 4y ago
    Time doesn't mean experienced.
    - FpUser 4y ago
      You can challenge anyone with this type of arguments. I was doing this kind of programming and delivering successful solutions since the 80s. If you chose to doubt my expertise it is your right. Does not mean your opinion has a shred of truth in it.
    - necovek 4y ago
      While you are in general right, GP specificaly has relevant experience for a long time, when time does equal experience.
- baq 4y ago
  I’d argue the language matters even less as folks with true experience in distributed systems know that the real problems arise between thread/ process/host boundaries which are mostly language-agnostic. IOW you really want senior people, full stop.
- necovek 4y ago
  On the contrary, I think that people familiar with generic concurrency and distributed primitives will easily transfer their knowledge between languages (I mean, a race is a race, and starvation is starvation...), whereas you can be very senior in a language yet never experience the edge cases of parallel programming. Sure, each language has different tools to solve corresponding issues, but I prefer to understand the problem I am solving to intimately knowing the tools I need to use. Ofc, having both is perfect!
  - pjmlp 4y ago
    Unless they have experience in the language runtime handles them, and how they might differ across implementations, they are in for a surprise when debugging parallel code.
doctor_eval 4y ago
Yeah, I mean I hired a great Java dev to do Go work and she picked it up in 3 months... but I knew she was awesome, so I wasn't worried about it at all. But hiring someone you don't know, which is typical ... retraining in a new language feels like it surely adds to the already substantial risk of hiring.
egeozcan 4y ago
I think the same as you, but let's admit that C# is one of the easiest languages to get into, especially with the magnificent tooling.
- weego 4y ago
  I think everyone in this chain should admit that hiring the kinds of developers you can 'throw x language book at' and a week later you have a competent x lang developer is an incredibly expensive and time consuming processthat most companies will never be able to afford. Even if you can, you then have to solve the issue of keeping a department stocked full of senior devs happy when you have limited promotion/perk/raise options and so churn will likely be relatively high even in a healthy environment. It's a nice fantasy view of the market as an ideal world simulation but does not reflect the reality of hiring software engineers.
  - jen20 4y ago
    Surely the other solution is to improve the work environment such that it’s possible to hire the people you aspire to hire…
  - jackcviers3 4y ago
    You can't buy a book, keep it on a shelf, lend it to new hires, and afford to have an employee take a week out of being productive to learn something? Or you can't afford salaries for a company of people who have more than 5 years of development experience? Both sound like major dysfunctional problems.
    - RhodesianHunter 4y ago
      No one learns a new language effectively in a week.

ch4s3 4y ago

You can hire any senior dev and give them the elixir book and a week to read it. You can also pick up someone junior who hasn’t learned anything wrong and coach them for a few months. I’ve successfully done both. The org I work in was one of the Elixir lang case studies and we still love using it, and have very little trouble hiring. It would be different if we had to hire 50 devs in less than 6 months, but we just don’t need to do that.

Apocryphon 4y ago
Elixir is a functional language, which is definitely a less common paradigm than OO languages like Java, which Kotlin is very similar to. Plus you can hire Android devs.
- ch4s3 4y ago
  Yeah of course, but the FP stuff is not very complicated in Elixir land. The heady stuff from ML family languages just isn’t there. The process model takes some time to adjust to, but a lot of JVM folks have used akka which is inspired by the BEAM. The tooling an docs all guide you in the right direction and usually code in the wild aims to be straightforward. I’ve really never had trouble onboarding people to Elixir unless they had started learning it solo as a Ruby dev, then they typically have to unlearn some stuff.
- jrvarela56 4y ago
  Is this true anymore? I'm biased by HN content but feel like I've been hearing non-stop about FP for the past 10 years.
  - jedberg 4y ago
    You're hanging around crowds that talk about FP. :) Right now I'm working with a team where we're trying to introduce FP and reactive programming, and most of them have never heard of either one, or if they have, have never really used it.
    - 4y ago

SergeAx 4y ago

Even better: you can just hire Android devs who are fed up with client side programming.