Здравствуйте, Sinclair, Вы писали:

Ты такой большой и классный пост написал, что я несколько дней собирался ответ накатать, ибо хоть и здорово написано, но не верно

S>Наверное, вы говорите о каких-то мега джедаях, которые способны за неделю-две, пусть даже и с помощью коллектива, изучить совершенно новый для себя язык вместе с его набором библиотек так, чтобы сразу думать на нём.
S>Увы, я к таким не отношусь, и своими глазами таких никогда не видел.

Начнём с того, что такого человека ты знаешь и регулярно видишь — это ты, и это вообще любой нормальный программист. Что такое нормальный? Ну, он хочет развиваться, учить что-то новое, а не просто как-то сделать задачу и пойти домой. Таких, само собой, не 100% в АйТи мире, но изрядное количество.

Кодовая база это же по сути живой организм, который постоянно меняется, развивается и далеко не на 100% идиоматична тому языку на которой она написана. Даже опытные разработчики на одном и том же языке видят "прекрасное" по разному, что приводит к изрядной неоднородности. Часто код начал свою жизнь ещё *надцать лет назад, когда идиомы были сильно иные даже в рамках одного и того же языка. Особенно это характерно для closed sources, где компания не несёт репутационных рисков показывая что же на самом деле они продают и "продать вовремя" выходит на первый план.

Когда разработчик выходит на новое место работы, его основная сложность далеко не язык программирования, а то наследие в которое он погружается. Вся та куча костылей, отсутствия или неактуальности документации, неочевидности развёртки или тестирования, и ещё тысяча и одна причина которая сделает первые месяцы работы мало эффективными. Будет ли на фоне этого переход на новый язык играть какую-то негативную роль? Будет конечно, но вот насколько она серьёзна, это уже отдельный вопрос. Если взять какую-то отдельную область, например классический бэкенд, то окажется что там гора фундаментальных принципов начиная от классических алгоритмов, заканчивая какой-нибудь экосистемой типа AWS которые совершенно одинаковы для любого языка программирования. Ну серьёзно, будет ли AWS Lambda на Python как-то значительно отличаться от лямбды на JS? Да ничего подобного, но вот знать что такое лямбды и как их готовить уже реально полезно.

В итоге получается, что подход "мы ищем бэкенд разработчика на C#" имеет широкое распространение в РФ, но это не более чем создание дополнительных сложностей компании на ровном месте. А вот более правильный вариант "мы ищем бэкенд разработчика готового работать с нашим стеком" даёт куда как более широкий простор для маневра и получения в штат реально высококлассных специалистов. Кроме того, если компания хоть слегка крупнее чем Рога-и-Копыта, то за время роста и развития кодовая база успевает обрасти несколькими языками и технологиями которые всяко нужно поддерживать и развивать, знания и навыки не пропадут.

Но как я уже говорил выше, такой подход не будет нормально работать с "языками для мутантов" типа C++/Rust или Haskell, где язык на столько сложен, что это становится критичным, т.к. вероятность всё разломать становится довольно не иллюзорной. Основная же масса коммерческих языков таких как C#, Java, Python, Go, Elixir, JS, TS (и наверняка кучи других, с которыми я просто не сталкивался еще) позволяют легко их менять без заметного негативного эффекта для качества кодовой базы и/или производительности. Я такое постоянно наблюдаю в компаниях в Сингапуре, аналогичная ситуация всегда была и в наших американских офисах. Был бы разработчик хороший, а язык — это вторично (за редкими исключениями).