Много лет назад мы брали на работу просто разработчиков. В основном очень хороших. Но не всегда. И я лично, и все, с кем я начинал, писали на любом языке. Нужно что-то сделать на .net — делали. Нужно что-то сверстать — верстали (ну ладно, в основном я). Нужно было что-то забабахать на javascript — бабахали. О качестве решений пока говорить не будем.
Потом как-то незаметно появилось четкое разделение: вот команда javascript, которая на server-side задачи ноль внимания. А вот команда .net, которая в client-side ни ногой (за редким исключением). И прием на работу четко разграничен. Вот вакансия .net разработчика, вот вакансия js разработчика, а вот вакансия ios разработчика. Особенно ярко это проявилось, когда мы начали делать tp3 с четким разделением зон ответственности. Весь UI исключительно на js, все взаимодействует через REST, ядро договаривается с командой js о форматах запроса/ответа и вперед. Начинать новый проект таким образом неплохо. Каждая команда думает о своей части, колбасит свою архитектуру, рефакторит и уверенно стремится к совершенству.
Но вот возникает момент, когда архитектуры в целом готовы и сложных архитектурных задач как-то уже и мало. Но зато очень много прикладных задач, горизонтальных. И как-то получается, что задач на стороне UI дофига, а задач на стороне сервера мало. И тут специализация дает о себе знать во всей красе. Команды несбалансированны, UI разработчиков в 2 раза меньше. В результате половина команды ядра слоняется и просит дать им работу, так что приходится команду ядра нагружать не самыми важными задачами. А команда UI находится в постоянной запарке.
Мое мнение простое: специализация не должна быть абсолютной. Понятно, что человек любит определенную технологию и проводит с ней больше времени. Но классный программист способен быстро войти в новую экосистему и эффективно писать на любом языке. Правило 80/20 считаю вполне может тут работать. Ты фокусируешься на своих компетенциях, но и заглядываешь в новые для тебя области.
С точки зрения компании это очень круто, когда человек способен сделать фичу целиком. Уменьшаются задержки, фича быстрее проходит по всем этапам разработки, меньше всяких согласований и передач ответственности. Можно реально фокусировать на тех задачах, которые важны именно сейчас, а не подбирать работу из средне-срочной области.
С точки зрения разработчика тут не все так просто. Лично для меня никогда не было проблемой сделать все самому. Для многих это почему-то большая проблема. Да, сначала твои решения будут не идеальными. Да, будут и наивные ошибки. Но я считаю, что любой хороший программист может найти хорошие решения даже в незнакомой среде.
Второй момент, личная заинтересованность. Многие считают, что js это АДЪ. Однако, когда фреймворк уже готов, а HTML тебе дают тоже готовый, то все не так печально. Интересных задач и там хватает.
Почему мне нравилось делать фичу целиком? Да потому что у тебя тогда есть четкое ощущение, что вот эту часть системы ты сделал сам. Для меня это очень важное чувство. А для вас?
Короче, сейчас мы начинаем опять брать на работу просто классных разработчиков, которые могут (и не против) делать фичи целиком, не взирая на технологии.