5 ms·

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

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.

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.