[julik]

>You might be looking for a <..> specialist but you don’t want to attract people who are only interested in particular languages. Because that person’s narrow focus will hinder their growth.

Exactly what I have been witness to was this taken to the test. Result:

* You hire devs who do not like (or worse: hate) working in the language of the shop. They scold at the application they have to maintain and run, they do not contribute libraries or fixes, and topic number 0 at all larger meetings is "how we should rewrite everything in TypeScript/Go/Kotlin/whatever-tech-the-freshly-hired-senior-person-likes-best"

* You hire devs who do not care about the ecosystem. When the time comes to fix an external dependency which is not up to snuff, they will be saying things like "well if this app was written in $my_favourite_lang instead, this would have been so much easier"

* You create an infighting culture between people who do like to work with the current setup and people who want to destroy it and replace it with their favourite setup, be it for language preference or for "getting promoted" reasons

Briefly: no, I think it is absolutely imperative - especially at a company which is not polyglot - that even if it is not a requirement to be super-proficient in the main tech at the shop, it must be a requirement - and not a soft requirement - that the eng. be prepared to work, explore and develop in that tech. If this requirement is not present or not met, you are setting up your company for turf wars potentially for years to come.

[cardanome]

That is exactly the point the article is making though: Do not hire devs that are only happy working in a specific language.

I would add that it cuts both ways: Having developers that are too married to the current tech stack can also cause problems. Sometimes things do need to be rewritten. Sometimes adopting a new tech into the stack can be the right choice and offer competitive advantages. Devs with different backgrounds bring fresh ideas and can help you get out of an local optimum and towards a better global optimum for your goals.

So it is all about balance.

[julik]

What I am getting at is if you don't hire devs _specifically_ who are happy working in your stack you are setting your team up for trouble. What was "I am more familiar with X" during an interview might as well turn into "We should rewrite in X" on the job, and I do feel like this situation should be explicitly filtered against in the hiring pipeline.

But then again, I am biased by having experienced the negatives of the situation.

[marcosdumay]

Announcing some position as "we want software developers with $qualifications to work mainly on our PHP backend" is completely different from "we want software developers with 5 years of experience with PHP".

Also, you don't promote people for non-valuable rewriting of stuff.

[julik]

> Also, you don't promote people for non-valuable rewriting of stuff.

You do once it is organizationally perceived as "modernization". Speaking from experience as I been on both ends of this (getting promoted for rewrites which in retrospect were ego-driven as well as seeing others getting promoted even though nobody asked for their rewrite)

[matt_craig]

I like the suggestion of having an explicit hard requirement that employees be willing to use and engage with the existing tech stack. It makes it easier to point to the requirements and say “you signed up for this”.

I’m surprised, perhaps naively so, that devs apply for roles featuring languages they actively don’t like (or even hate).

What’s more understandable is a dev picking up a new language/tech stack on a job and discovering they don’t like it. (In that case they still shouldn’t actively fight against it, unless it’s actually detrimental to the company’s progress.)

[teh_klev]

> devs apply for roles featuring languages they actively don’t like

Then that's their problem, not the employer's fault. If you know what stack is being used when applying for a job, and you despise said development stack, then why apply for the job?

But there are other developers out there who aren't that fussed about what development stack they might be working with. Often there are other attractions to the role such as compensation, paid time off, etc.

> What’s more understandable is a dev picking up a new language/tech stack on a job and discovering they don’t like it.

This happened to me once, but I held my nose and just got on with the job.

[julik]

> then why apply for the job?

Opportunism perhaps? "...once they fire all these annoying legacy senior people we can redo everything..." As well as going down in the level of the joint (going from an A-league startup to a B-league startup) in the hope of more authority and ability to determine the choice of tech?

[julik]

This.

[anonymoushn]

> be prepared to work, explore and develop in that tech

This seems like a much weaker requirement than the sort of requirement the fine article argues against