Hacker News Reader

Comment by TillE | Hacker News Reader

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.

View on HN

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.

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.

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.

Surely the other solution is to improve the work environment such that it’s possible to hire the people you aspire to hire…

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.

No one learns a new language effectively in a week.

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.

Yeah, but you don't need that many to start. That knowledge will spread rather rapidly to where it's needed.

But that has also the danger of forming islands (mortgage code) which can be maintained by some (or, one) specific engineers.

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.

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

Time doesn't mean experienced.

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.

While you are in general right, GP specificaly has relevant experience for a long time, when time does equal experience.

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.

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!

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.

Reply on news.ycombinator.com