Из-за нестабильной ситуации в мире отношение к Junior и Middle специалистам в области ИТ изменилось: компании сокращают младших и средних специалистов, либо останавливают их найм. Любые компании будут диверсифицировать риски и стараться закрыть наибольшее число потребностей — для чего и стараются брать Сеньор специалистов. И хоть профессионалы среднего звена в меньшей зоне риска, на младших это отразилось сильно. Тем не менее, каждый уровень ИТ профи по-своему важен и нужен. Разберём, почему всё же стоит обратить внимание на Junior и Middle работников.
Экономия бюджета
Есть задачи, с которыми джуниор специалист отлично справится. Нет необходимости брать на них высококвалифицированных работников, зарплата которых значительно выше. Всегда рекомендуется подбирать профессионала под свой уровень ответственности в компании, чтобы не было ситуации, что в штате несколько Сеньоров и часть из них выполняет в основном задачи Джуна.
Рутинная работа больше подходит средним и младшим специалистам
У Сеньоров и так широкий набор задач, если добавить к нему ещё и работу Джуниор и Миддл уровня — специалист будет перегружен. Он станет отвлекаться от основной работы чтобы сделать задачи Джуниора, придётся переключаться туда-обратно. От этого у любого работника пострадает качество его труда. К тому же, младшие и средние специалисты больше готовы к базовым задачам — они ещё не накопили столько опыта, чтобы заниматься архитектурным уровнем Сеньора. Компании часто, особенно в кризис, набирают Сеньоров. Они предполагают, что такие эксперты быстро сделают необходимую разработку и тем самым спасут компанию — такая система неустойчива. Иерархия сделана так, чтобы у каждого уровня был свой круг задач.
Если мы набираем только Сеньоров — они сначала должны будут выполнять всю работу Джунов, а потом переключаться на творческие задачи и принимать решения. Если набирать только Джунов — некому будет проектировать новое, бизнес не станет расширяться. Если взять только Джунов и Сеньоров, но не брать Лидов - потеряется контроль команды. Везде нужен баланс, так называемое золотое сечение.
Дольше находятся в одной компании
HR могут заметить, что Джуниор и Миддл специалисты, как правило, дольше находятся на одной позиции. Почему? Когда сеньоры достигли определённого порога— им хочется прыгнуть выше. Если внутри команды им не дают такую возможность
(если руководитель не считает это необходимым, или не может позволить себе развитие Сеньора) — Сеньор начинает смотреть сторонние предложения в поисках подходящей компании. Так они переходят из одной компании в другую с дальнейшим развитием в Лид команды.
А Миддл ещё не имеют необходимых знаний и автономности для принятия подобных решений. Они уходят, в основном, если им тяжело на рабочем месте, или если какой-либо важный внутренний процесс не налажен и тем самым портит жизнь работнику. Если в компании всё хорошо — Миддл будет работать достаточно долго. То же самое касается трейни, джунов.
Лояльность к работодателю выше
Большой плюс набирать Джунов и Миддлов — это лояльность. Чем более юный специалист, тем выше лояльность к компании. Взяли на работу на раннем этапе, дали “хлеб”, обучение — такой человек будет иметь не только работу, но и лояльность к компании и команде. Они больше привязаны к компании, чем Сеньоры, которые в любом кризисе могут начать вертеть головой в поиске места лучше.
Количество открытых к предложениям Сеньоров и Лидов стало больше, при любой кризисной ситуации специалисты именно этого уровня ищут что-то более стабильное, а Миддлы остаются привязаны к текущему месту до окончательного разрешения ситуации в компании.
Легче мониторить рабочий процесс
Миддлы и Джуны выполняют чаще процессную работу, им можно назначить чёткие kpi. Именно поэтому их работу легче оценить и проследить. У Сеньор специалистов часто бывают архитектурные задачи, вовлечение в другие проекты. Грань стирается, начинается "творчество" - свобода что-то решать, и в этот момент появляется необходимость продумывать сложную систему оценки Сеньор специалиста. Если компании нужно расширение, выводы исследований - тогда нужны Сеньоры. С остальным могут справиться Джуниор и Миддл работники.
Легче адаптировать и подгонять под процессы компании
Джуна и Миддла можно обучить под компанию и Сеньора, вырастить их такими, какими нужны. А Сеньоры уже приходят с определёнными собственными устоями, которые не всегда сочетаются с компанией. Для Сеньор специалистов стресс адаптации к новой компании значительно выше, чем для Джунов и Миддлов, как раз потому, что приходится менять привычные процессы под компанию. У младших и средних специалистов таких устоявшихся привычек как у экспертов либо нет, либо их совсем немного, поэтому их и проще адаптировать под культуру и работу компании.
Приходят с более свежим взглядом
Младшие и средние специалисты чаще приходят с рынка с чем-то свежим, дают новый взгляд на базовые задачи. Если Сеньор видит такие задачи - либо выполняет быстро, как он привык, либо пытается автоматизировать. А Джуниоры и Миддлы могут предложить новое решение с их прежнего места работы/учёбы, ведь для них рутина Сеньоров — это зона роста. Сеньор если приходит извне — тоже может внести что-то новое, но по новой изобретать велосипед ему вряд ли захочется.
Коротко о главном
Все уровни специалистов в ИТ индустрии по своему важны. Каждый выполняет определённую работу лучше другого, потому что больше на неё заточен и готов к ней. В любой команде всегда есть лидеры и те, кто работает под их началом — нельзя сводить всю команду к одним старшим уровням, эта система теряет свою опору.
Комментарии (77)
4eyes
26.06.2022 17:31+13Большой плюс набирать Джунов и Миддлов — это лояльность. Чем более юный специалист, тем выше лояльность к компании.
... и тем заметнее перемены, когда джуниор или миддл понимает, чтоб бизнес - это про деньги. И хорошо, когда он понимает, что не просто про деньги, а про взаимовыгодное сотрудничество.
Где-то посередине этого перехода наблюдается разочарование в одной картине "рабочего мира" со всеми этими Корпоративными Ценностями™ и Семейным Духом™ и неимение другой. Иногда получается кто-то вроде Доктора Хауса, но с профессиональными навыками уровня мидла.
panzerfaust
26.06.2022 17:35+38Работал я в одной компании, которая решил сыграть в эту рулетку "сеньоры не нужны, вырастим сами". Три джуна за полгода наработали техдолга на 2 человекогода по оценке CTO. Ненужный сеньор потом полгода весь в мыле рефакторил эту "экономию бюджета" параллельно со своими задачами. Теперь компания как миленькая ищет сеньоров. Урок усвоен. Вы тоже усвоите.
aamonster
26.06.2022 18:20+9За полгода "параллельно со своими задачами" отрефакторил "техдолга на 2 человекогода"? Это не сеньор, а какая-то машина для рефакторинга просто. Не верится, imho где-то в этой истории обман – или оценка завышена, или он так и не исправил ситуацию.
(но мысль, что нельзя оставлять джунов без присмотра, поддерживаю всеми лапами)
panzerfaust
26.06.2022 18:43+4отрефакторил
Я не говорил, что действие было завершено. За полгода были удалены самые дикие уродства и антипаттерны. Код стало реально поддерживать и дорабатывать в срок и без постоянного регресса.
h1pp0
26.06.2022 19:03А как получилось, что рефакторинг сильно дороже самой разработки? Три джуна * полгода = полтора человекогода (в джунах). Если такая возможность есть, то проще было бы переписать это всё зановос с околонулевым техдолгом за условный человекогод.
dididididi
26.06.2022 19:11+12Это так сеньор сказал) Он всё это время расставлял импорты в алфавитном порядке, и добавлял private к переменным. С воплями "кто вам делал это гуано". Видал таких.
Ellinist
27.06.2022 08:07Спасибо - поржал...
Я еще видел, как юзинги упорядочивали лесенкой - начиная от самой короткой строки, типа using NLog; до самой длинной (подключение проектов с очень длинными нэймспейсами).
Borz
27.06.2022 08:53+2но... зачем? Есть же автоформатеры кода, которые поправят код так, как надо. Или это в те времена, когда автоформатирование кода не в ходу было?
dididididi
27.06.2022 20:22Безусловно есть. Но он же дефолтный) Ваще не тру. А синьору нравится по-другому. Он знает как правильно)
Aleksandr-JS-Developer
27.06.2022 23:01+1знает как правильно
Один из многих парадоксальных сходств джуна с сеньором - это как раз ругань на общепринятые инструменты: "моя знай как правильно, а у твоя какаха вода туалет плавай"
dimti
27.06.2022 14:13+2Ну а как ещё. В файле по 20-40 use. Все идут в разнобой. Почему не потратить две минуты времени и не упорядочить их хотябы по неймспейсам.
PhpStorm не форматирует автоматически это, а вставляет просто новые use вниз.
funca
27.06.2022 14:31-2Бывает ещё так, что над файлом работает несколько человек и у каждого из них IDE использует разные правила для автоформатирования. Тогда в PR появляется масса ненужного шума из-за которого сложно понять что же конкретно собирался менять автор.
JekaMas
27.06.2022 21:47+2Попробуйте настроить проверку правил форматирования, как часть CI. И ваша жизнь станет лучше.
zaqqq13
28.06.2022 08:50В чем проблема проверки код стайла на pre push хуке и при ci? А в проект просто закинуть конфиг кодстайла под основную ide в команде?
Aleksandr-JS-Developer
28.06.2022 09:47основную ide в команде
Как показывает практика, не всегда IDE есть "основная" на всю команду.
Если используется популярный форматер, то нужно класть конфиг для него. А в IDEшки уже устанавливать плагины. Или вообще форматер как зависимость тащить, независимо ни от чего
zaqqq13
28.06.2022 08:49Так те же продукты intelij по дефолту импорты ставят по алфавиту, плюс автоформаттер можно конфигурировать путем настройки code style проекта. Хреновый был у вас сеньор, раз он руками это все двигал вместо того, чтобы потратить пару дней на настройку и потом одним кликом мыши все сделать моментально
StupidMouse
28.06.2022 11:59так он так и делал, но рассказывал что делал все рукми и работы этой много. пол года самых лёгких денег.
funca
26.06.2022 19:42+4переписать это всё зановос с околонулевым техдолгом за условный человекогод.
Порой на условный человекогод нет денег, а чинить надо уже сейчас.
BugM
26.06.2022 22:25+8Легко. Код уже в проде. На него уже завязались. Он уже приносит деньги.
Ремонтировать самолет в полете сложно и дорого.
iMedved2009
27.06.2022 01:57+6Старый анекдот на тему:
Кардиолог приезжает в автосервис, ему работяга машину чинит, потом говорит:- Слышь, мужик, вот я мотор перебираю - и ты мотор перебираешь, только человеческий - почему тебе платят в 4 раза больше?Кардиолог кивает, идет к машине, включает зажигание и говорит работяге:- А попробуй, при работающем движке теперь - перебери!
Ellinist
27.06.2022 08:06+7Да, анекдот старый, и когда-то я над ним смеялся.
Но сейчас понимаю, что все не так - ни один хирург не перебирает человеческий мотор, который работает - либо сердце останавливают (с применением гипотермии), либо выводят из основного цикла (с применением искусственного мотора).
snaiper04ek
28.06.2022 12:27Так а разница? По аналогии - машина должна крутить колёса на пониженных оборотах, пока мотор подменяют электромотором, а настоящий мотор отключенным перебирают, тогда уже понадобится и план "операции", вместе с ассистентами.
Механик открывает капот, и смотрит, чё где потекло или не потекло, идёт на перекур, советуется с коллегой пока курит, возвращается, лезет внутрь - вроде собрал - ай нет, забыл трубку накинуть, которую отцеплял когда внутрь лез.
А прежде чем оперировать нужно обследовать из вне(окей, аналог осмотра под капотом), составить план операции, предусмотреть варианты развития, в том числе самые плохие, и сама операция ограничена по времени, нужно всё успеть за один заход, и сразу сделать всё правильно от самого начала, до самого конца. А рядом сидит анастезиолог, который заранее рассчитывает корректную дозу обезбаливающего, и добавляет по мере необходимости, если операция затягивается. Требования к квалификации несопоставимы, мотор можно и самому в гараже перебрать в течение месяца, а в случае ошибки, цена - не вполне работающий мотор.
Я к чему.
Анекдот всё ещё смешной))
yerbabuena
28.06.2022 12:43+1А рядом сидит анастезиолог,
Не торопите события, он пока еще стоит или находится :) Сидеть будет, если карательные органы усмотрят состав дела в произошедшем.
Tresimeno
27.06.2022 10:21+3А как получилось, что рефакторинг сильно дороже самой разработки?
А примерно также, как строить небоскреб на месте снесенной пятиэтажки в центре Москвы сильно дороже, чем строить такой же небоскреб посреди бескрайних просторов Балашихи или еще какого Красногорска. Требование деликатно работать с имеющимся наследием, в т.ч. с данными, плюс небходимость вкурить что же это там такое было сделано и почему именно так сделано - это все время на разработку только удлинняет.
KvanTTT
27.06.2022 14:04+1Ну судя по текущей ситуации, бескрайние просторы Красногорска подошли к концу.
K1aidy
27.06.2022 10:23Конечно, тут без уточнений сказать наверняка нельзя, но вполне возможно, что там обратно-независимая архитектура получилась, которую переписать за один подход невозможно. Как правило, джуны про это не особо задумываются, а больше пытаются построить расширяемую архитектуру, в силу своей неопытности. Хотя ВСЕГДА нужно помнить, что после вас ОБЯЗАТЕЛЬНО придет "сеньор", который скажет, что все говно и начнет все рефакторить.
XeaX
27.06.2022 10:21+3Я правильно понял, что СТО сначала допустил самостоятельную работу 3 джунов приведшую к серьезному техдолгу, а затем еще и не смог корректно его оценить? Т.к. между "два человекогода" и "полгода параллельно основной работе" разница очень серьезная.
panzerfaust
27.06.2022 10:53+2Странно, что все цепляются к оценке. Если в течение полугода написать код, отдать заказчику и дорабатывать по методике "и так сойдет", то кто сказал, что итоговый техдолг будет те же полгода? Возможно и меньше, возможно и больше. Переписать банальный перекладчик джейсонов после джуна и правда можно довольно быстро. А если у вас нетривиальные бизнес-кейсы плюс нетривиальная схема данных, то попасть можно довольно крупно, а править это по живому будет занимательным приседанием.
Как допустили джунов до таких дел? А вот так взяли и допустили. Я же сказал - сыграли в рулетку "сэкономим, вырастим своих джунов". Понадеялись, что метод fake it till you make it сработает.
XeaX
27.06.2022 19:15На всякий случай замечу, что из вашего описания не понял, в чем же проблема в этом проекте в итоге была у компании. Провалили дедлайн? Качество? Бюджет? Не сделали все фичи?
Из описания - да, иногда так можно растить из джунов в сеньёры, если есть откуда брать подходящие задачи класса "не бей лежачего" + "выкинуть через полугода", ну и повышать градус постепенно. Особенно хорошо заходит, когда есть какие-то образцы кодовой базы, откуда джуны могут черпать мудрость.
panzerfaust
27.06.2022 20:28Качество. Там, где сеньор заложил бы задел под новые хотелки, джуны херачили спагетти-процедурщиной напрямик лишь бы сделать. А хотелок было достаточно, заказчиков много и у каждого свои особенности. Через пару итераций джуновские направления встали колом - каждое следующее изменение требовало все больше времени и гарантированно приводило к регрессу. Поступает новое требование - джун не моргнув глазом берет под козырек, пыхтит 2 недели, выдает мерж-реквест на 2к строк в 50 файлах. Ревьювер фалломорфирует, тестеры фалломрофируют, релиз флооморофирует и съезжает на 2 неделю, босс фалломорфирует и идет извиняться перед заказчиком, что фичу придется подождать. Все попытки донести мысль о декомпозиции задач, планировании, архитектуре, солиде, наконец, ни к чему не приводили.
Двух джунов в итоге на мороз выставили. Третьего перевели исключительно на задачи уровня изи. А ненужный сеньор пошел это все исправлять - но в итоге выгорел и сам уволился. Вот так скэномили.
Akinfeev
28.06.2022 10:54Создалось очень чёткое ощущение, что проблема вашей компании вовсе не в джунах и сеньорах...
xeeaax
28.06.2022 11:02Даже интересно из описанного - а СТО в компании чем занимался? За организацию разработки отвечали сами джуны?
TheCluster
27.06.2022 11:35+2А я был в противоположной ситуации, когда компания нанимала только синьеров. Ушел через 3 месяца, потому что пилить crud и интегрировать очередной soap/json/etc провайдер данных, это как раз задачи мидлам или даже джунам.
pankraty
26.06.2022 17:44+8Джуниоры и Миддлы могут предложить новое решение с их прежнего места работы/учёбы,
Тут у меня большие сомнения. Так-то и джуниор, и сеньор могут сказать "у нас на прошлом проекте использовался X для Y", но навыков Джуна или Мидла (если только это не "сильный мидл, почти сеньор) вряд ли хватит на то, чтобы сопоставить требования, которые были "там" и есть "тут", оценить подводные камни и издержки по внедрению того решения и принять взвешенное решение о целесообразности этого. А у сеньора и опыта прошлых проектов побольше обычно. Так что этот пункт вообще мимо.
DyadichenkoGA
26.06.2022 18:27+24Брать джунов и мидлов нужно только затем, что нужны новые сеньоры. Иначе скоро один сеньор будет стоить, как крыло от боинга (хотя я не скажу, что я против) :) В остальном в 99% случаев - это расход ресурсов и денег :) Сеньоры делают быстрее всё. И рутину, и сложные задачи. Что рутину часто впадлу делать - это другой вопрос. Но когда ты задачу решал 150 раз, то в 151 ты делаешь её примерно за минуту. Сеньорам есть что обсудить на ревью, и часто сеньорам лень менять компанию, так как денег платят везде на определённом уровне в тех же корпах +- одинаково. И если ты уже "устал от приключений", ты просто работаешь на проекте и не паришься. Чаще всего мотивацией смены работы я видел скуку, а не вопрос деньгах. Лидами вообще многие становится в принципе не хотят.
В большинстве своём сеньоры - это такие бывалые, уставшие профессионалы, которым плевать что делать, так как они умеют очень многое и на контекст задачи смотрят, как на предметную область. Бывает кто-то ещё горит работой, но за 6 лет+ ты начинаешь к программированию (коммерческому) относится филосовски. Пилишь какой-то пет проектик, если тебе не надоело программировать, так как там никто не меняет бизнес требования, не переобувается на лету, не нужно думать о коммерческих рисках использования той или иной технологии. А коммерция вся +- одна и та же, меняется по моему опыту разве что контекст. Поэтому нет смысла менять особо компанию, так как поменяешь в большинстве случаев одно на другое, если не подвернётся действительно супер интересный проект :)
aamonster
26.06.2022 18:29+7tl/dr; (вру, прочитал)
Куча дурацких, порой откровенно неверных обоснований вместо трёх слов: джун дешевле сеньора.
Что ещё может сыграть в ту же сторону: "свой" миддл (уже нырнувший в проект) на краткосроке может оказаться полезней "чужого", только пришедшего сеньора.
Готовность выполнять рутинные задачи, насколько я могу судить, вообще не коррелирует с рангом. Легче адаптировать – хрень, сеньор, который не умеет адаптироваться – это просто старый закосневший джун. И так далее.
funca
26.06.2022 19:08+3нельзя сводить всю команду к одним старшим уровням
Вообще да, "генералы не бегают". Я как-то работал в стартапе, куда в самом начале набрали звёзд за хорошие деньги (многие имена широко известны по выступлениям на популярных конференциях). Естественно все старались. За год концепция продукта менялась несколько раз, дизайн креативил, разработка выдавала фантастические решения (создав в процессе несколько до сих пор популярных в народе библиотек). Это было драйвово и весело, но в итоге все превратилось в глючное и неподдерживаемое . Потом фаундеры заменили супер-стар-команду на прикормленных аутсорсеров, оставив часть предыдущего состава
не у делв ролях консультантов. Те конечно звез с неба не хватали, но стоили меньше в разы и собрали с фактически с нуля вполне рабочий MVP за несколько месяцев.Чисто по ощущениям, совмещение ролей, когда ты утром работаешь над архитектурой, а после обеда идёшь разбираться с каким-то нюансом в скриптах сборки или клепать формы - контрпродуктивно, поскольку вынуждает постоянно переключать контекст. В любом проекте есть уйма типовой работы, с которой может справиться даже новичок.
dididididi
26.06.2022 19:15-1Ага. Да возьми пару звёзд и через полгода твой проект не сможет понять никто. Работать он может быть будет.
aamonster
26.06.2022 19:28+7Спасибо, благодаря вашему комменту осознал пользу от джунов (не упомянутую в посте): если ты не можешь объяснить свой код джуну, то код – [censored]. Этакая опорная точка.
Если код организован так, что ты можешь давать задачи джунам и не бояться, что они что-то сломают (проверять надо только тот кусок, который джун делал) – кодовая база прекрасна.
iMedved2009
27.06.2022 01:58+1Как бы есть подозрение что не все из стэка технологий джун может знать.
aamonster
27.06.2022 02:14+3Это решаемо (если джун толковый – до уровня базового понимания технологии доводится быстро)
Если в стеке технологии, требующие серьёзного обучения (до уровня мидла) просто для чтения кода – может, в консерватории что-нибудь поправить?
iMedved2009
27.06.2022 03:12+2Ну окей, базово понял да. Вот только если у нас что то крупное - это не фига не будет достаточным.
Ну прочитал он код того что там работает с очередью. Но если он не знает эти очереди, к чему они здесь, почему оно так - сломать он сможет только в путь.
aamonster
27.06.2022 08:23Я ж не агитирую нанимать джуна на позицию сеньора :-)
Речь о том, что сломает он только там, где пилил. И косяк не вылезет в совершенно в другом месте. Ну и, опять же, см. пункт 1 :-)
iMedved2009
27.06.2022 09:59Речь о том, что сломает он только там, где пилил. И косяк не вылезет в совершенно в другом месте.
Ну как сказать. В свое время один "не сеньор" накатил hash индекс у него норм, админы на дыбы встали реплика поломалась.
Nialpe
27.06.2022 09:16+5Поддержу вас. Опыт у меня, может быть, и не 100500 лет, но припоминаю такой случай:
Собеседовался, нанимающим не понравилось, что я работал из СУБД только с MySQL, а "у нас на проекте PostgreSQL(!)". Кряхтели, сомневались, видимо, но оффер прислали. Начинаю вкатываться в проект. Думаю, наверное, у них там какие-то фишки именно PostgreSQL используются (пока отрабатывал на прежнем месте - попытался почитать, дома развернул, пощупал). Выхожу на новую работу, месяц работаю, два... Полгода. Ничего кроме ANSI SQL нет, а развертыванием и администрированием разработчики не занимаются от слова "вообще". Парам-парам-пам.
Поэтому, бывает оооочееь по-разному и иногда (часто) технологии тащат в проект разработчики, чтобы пощупать и поучить (в т.ч. и для резюме), а не потому, что эти технологии жизненно необходимы.
Ares_ekb
26.06.2022 19:38+6В любом проекте есть уйма типовой работы, с которой может справиться даже новичок.
У нас, например, такой работы очень мало. Рутинные задачи делаются один раз, второй, а в третий раз делать то же самое становится лень и задача автоматизируется. Минус в том, что для джунов нет работы, через которую они могли бы погружаться в проект. Даже если человек в чем-то разобрался, то скорее всего делать ещё раз то же самое по аналогии ему уже не придется, а будет снова задача, в которой придется что-то исследовать, искать варианты решения.
Даже если возникают какие-то типовые задачи, то синьор условно сделает их несколько штук в день, а джун будет одну задачу делать неделю.
funca
26.06.2022 20:13+1а в третий раз делать то же самое становится лень и задача автоматизируется.
А что за предметная область? Моя команда сейчас работает небольшими инкрементами (иначе сильно растут риски) над, условно, автоматизацией документооборота. Самое сложное это разобраться в требованиях, придумать и согласовать решение со всеми заинтересованными лицами. Закодить, написать тесты, задеплоить, проверить, где-то обновить документацию это все довольно муторно, но уже не сложно. Джуны по началу теряются из-за количества церемоний, но при наличии гайдов, ментора и код ревью, быстро втягиваются. Синьеры лучше видят решение вцелом, но типовые задачи закрывают не сказать, что сильно быстрее.
Ares_ekb
26.06.2022 23:47+2На нашем проекте разобраться в требованиях - вообще не проблема, гораздо сложнее найти людей с опытом в этой области или без опыта, но кому было бы интересно этим заниматься.
Предметная область - разработка инструментов моделирования, анализа моделей, кодогенераторов и т.п. Вполне естественно, что с автоматизацией рутины сложностей нет, т.к. это одно из назначений самого продукта :) Поэтому джуны, которые закрывают типовые задачи по инструкции, не нужны, такие задачи (типа добавления новой формочки, поля, правил валидации, добавления новой нотации моделирования в инструмент, добавления отчета, написания boilerplate кода) уже автоматизированы, или могут быть автоматизированы, или делаются самим заказчиком без участия разработчиков. По сути мы делаем конструктор, который сами же и используем в разработке.
На мой взгляд многие задачи в ИТ проходят через такие стадии:
1) Сначала задача исследовательская, видны только какие-то первые шаги для её решения, как она будет реализована в деталях неизвестно. Для таких задач джуны бесполезны. Они или в принципе не сделают её ни за какое время, или будут делать в 10-50 раз дольше сеньора, или сделают что-то не то.
2) Затем задача тщательно документируется, становится типовой. Остается прочитать разные внутренние руководства по решению таких задач, по оформлению кода и т.п. Для таких задач, да, джуны вполне подходят.
3) Затем задача постепенно автоматизируется. Появляются какие-нибудь скрипты, кодогенераторы, движки с типовыми компонентами. Джун вряд ли сможет разработать что-то такое, но может использовать. Например, сгенерить boilerplate код и что-то ещё дописать. Или взять готовый компонент и задать параметры.
4) Наконец все эти инструменты внутренней автоматизации становятся отдельным продуктом, выходят на рынок и используются повсеместно, задача полностью автоматизирована. Начиная от каких-то внутренних задач. Например, оформление кода, поиск типовых ошибок могут быть автоматизированы с помощью SonarLint, Checkstyle, ESLint - для этой рутины уже не нужен ни джун, ни синьор. Генерация документации по коду. Или при разработке учетных систем, систем документооборота можно делать всё с нуля, а можно взять движок типа DevExpress XAF, или разработать свой такой движок. Тогда большая часть работы будет заключаться а) в описании схемы данных, описании формочек в виде модели (в основном это аналитическая работа, с которой синьор справится быстрее джуна) или б) в реализации сложных вещей, выходящих за рамки готового движка (с этим сеньор тоже справится лучше). В разработке инструментов моделирования я видел примеры, когда люди тратят очень много ресурсов, делая многие вещи с нуля и вручную, вместо того, чтобы взять готовый движок, использовать правильные технологии и сократить время разработки раз в 10.
Я сходу не могу придумать задачи в ИТ, которые невозможно довести до 4-ой стадии. Наверное часто это не делают по каким-то организационным причинам, проще нанять десяток синьоров и сотню джунов. Синьоры будут заниматься сложными задачами и писать инструкции, а джуны по этим инструкциям будут решать типовые задачи.
Хотя, блин, я всё-таки уверен, что сеньору лень заниматься рутиной и он будет искать варианты автоматизации и в итоге сделает задачу быстрее джуна. Например, у нас была такая задача. Есть структуры таможенных и других документов, для них описаны правила заполнения на русском языке. Нужно реализовать систему, которая будет проверять документы на соответствие этим правилам. Типов документов сотни. Правил заполнения для каждого от сотен до тысячи. Самый очевидный вариант решения следующий. Аналитики вникают в эти правила, пишут постановки разработчикам, разработчики реализуют всё в коде, покрывают тестами, тестировщики тестируют вручную. Отличный проект на сотню-другую человеколет, и для джунов работы полно. У нас не было столько джунов, поэтому мы пошли следующим путём. Правила описываются на формальном языке (что-то типа предикатной логики), а всё остальное генерится автоматически. Нужно несколько синьоров, которые реализуют этот транслятор из формального языка спецификации правил в валидаторы документов, а джуны не нужны вообще. Хотя даже при этом всё равно находилась какая-то рутинная работа, которую в принципе можно было бы дать джунам, например, перевод правил с русского языка на формальный. Но у джуна перевод тысячи правил займет неделю непрерывной механической работы. Мне это занятие надоело уже через несколько минут, я потратил день чтобы сделать табличку в Excel с формулами, которые делают это автоматически для большинства правил, а в сложных случаях можно дописать уже вручную.
На мой взгляд, даже если задача совершенно типовая и простая всё равно синьор справится с ней быстрее, потому что он будет искать какие-то варианты автоматизации рутины.
BugM
27.06.2022 00:16+2Правила описываются на формальном языке (что-то типа предикатной логики) , а всё остальное генерится автоматически.
Вы просто написали свой собственный язык программирования и обучили разработчиков писать на нем. Этот подход имеет право на жизнь, но далеко не всегда. Скорее даже это довольно нетипичный способ решать задачи.
Ares_ekb
27.06.2022 08:05+3С одной стороны, да, конечно! И есть мнение, что это чуть ли не единственный правильный подход к программированию. Когда-то очень давно прочитал эту статью и она запала мне в душу. По хорошему разработка любого приложения - это разработка своего DSL.
1) Это может быть прямо реальный DSL со своим синтаксисом. При этом синтаксис может быть текстовым (SQL, HTML, CSS, XML, XSLT, XPath, Gradle, Make, JSON, YAML, DOT, PlantUML, Docker, ...) или графическим (BPMN, UML, диаграммы SSIS, ...). А может быть и таким, и таким как у SysML v2. Разработчики постоянно пользуются такими языками. Постоянно появляются новые языки. Они могут быть разной степени сложности. Но если стоимость разработки какого-нибудь простого DSL - пару дней, а время изучения - пару часов, то что в этом плохого? Если это какой-то безумно сложный DSL, который нужно изучать годы и потом эти знания нигде не пригодятся, то наверное это просто не самый удачный язык. Не все DSL похожи на 1С.
2) Может быть DSL, встроенный в другой язык. Например, JavaDoc, LINQ, JSX.
3) Может быть DSL на базе языка с макросами (Lisp) или расширяемым синтаксисом (Isabelle). Тут создание своих своих языков - это просто обычный подход к разработке, с этого всё начинается.
4) Может быть DSL на базе JSON, XML, YAML в виде конфигурационных файлов. Например, GitLab CI/CD, Docker Compose, Ansible, Spring, ...
5) DSL в виде аннотаций. Тот же Spring, UML-профили.
6) Наконец, если все эти кастомные синтаксисы, конфиги и аннотации не для нас, мы просто пишем код на ЯП и всё, то даже в этом случае хорошее приложение состоит из набора микрофреймвоков или наборов типовых компонентов. Например, набор своих или чужих React-компонентов, из которых мы собираем UI. Набор компонентов для обработки каких-нибудь данных, рассылки уведомлений и т.д. Главная идея, что есть какая-то узкая область, например, UI приложения. Этот UI строит из какого ограниченного набора компонентов. А будет UI собираться в коде, описываться на YAML, рисоваться в виде диаграммки или текстом на специальном DSL, ... - вообще пофиг, это уже детали.
Многие фреймвоки реализуют сразу несколько вариантов из перечисленных выше. Например, в Spring одно и то же можно сделать вариантами 4, 5 и 6. Аналогично в Swagger. В React - варианты 2 и 6.
В общем, ещё раз подытожу идею, на мой взгляд, разработка любого приложения - это разработка своего DSL одним или сразу несколькими способами описанными выше. Я думаю, что это нормальный и правильный подход к разработке, когда программист смотрит на приложение с этой точки зрения. В противном случае код превращается в какую-то кашу с файлами на тыщи строк, с классами с десятками приватных полей и методов, которые через эти поля обмениваются какими-то данными и нужно часами дебажить этот код и рисовать на листе бумаги схему его работы, чтобы понять что там вообще происходит. Или если в приложении прямо очень много однотипного boilerplate кода, многие задачи решаются копипастой, куча рутинных задач, то возможно настало время как-то обобщить этот код, сделать свой микрофреймвок, вынести что-то в конфиги или даже сделать свой DSL. Я не то, что не вижу в этом никакой проблемы, а наоборот хороший сеньор должен мыслить такими категориями ещё до того, как рутина в принципе появилась.
С другой стороны, мы никакой собственный язык программирования не придумывали, а взяли готовый. Хотя это не язык программирования, а язык спецификации. Это тоже отдельная тема, я не хочу писать тут ещё столько же текста, пора уже сворачивать этот поток графоманства ) В 90-е высказывались идеи, что на UML можно нарисовать несколько квадратиков, по которым можно сгенерить любое приложение (веб-сайт, компьютерную игру, систему управления атомным реактором), а языки программирования и программисты не нужны вообще. По каким-то "неведомым" причинам идея оказалась несостоятельной :) И с тех пор бытует мнение, что вообще все эти квадратики со стрелочками, текстовые DSL и т.п. не нужны, потому что они не могут заменить языки программирования общего назначения. DSL абсолютное зло, не нужно использовать их нигде и никогда. Но сейчас как-то незаметно DSL стали использоваться практически везде (выше много примеров), а многие разработчики даже не осознают того, что какие-нибудь JavaDoc, Docker, GitLab CI/CD, LINQ, Swagger, Gradle и т.п. - это на самом деле DSL, языки, которые позволяют специфицировать на более высоком уровне абстракции что нужно сделать, чем это делается на ЯП общего назначения.
Безусловно здесь можно впасть в крайность, начать создавать какие-то безумные абстракции над абстракциями, создавать какие-то свои сложнейшие языки, в которых никто никогда не разберется. Поэтому первое что нужно сделать - это посмотреть не создавал ли кто-то такой язык уже до тебя. Например, в нашей предметной области (разработка инструментов моделирования) большая часть DSL уже придумана консорциумом Object Management Group. Тот же OCL для описания правил валидации или запросов к объектным моделям. QVT для преобразования моделей в модели, M2T для преобразования моделей в текстовое представление. MOF для описания языков моделирования. И т.д. Я видел много примеров, когда вместо специального DSL, придуманного умными людьми в серьезных компаниях, используют какие-нибудь VBA, Lua, JavaScript, C# и т.п., мотивируя это тем, что на hh.ru резюме JavaScript разработчиков дофига, а людей со знанием QVT нет вообще. Но в итоге получается печаль печальная, потому что JavaScript не предназначен, например, для преобразования моделей. На нём можно это сделать, но нет никакой гарантии, что в итоге не получится неподдерживаемый лапшакод. Потому что практически все JavaScript разработчики, разместившие своё резюме на hh, занимались совершенно другими задачами (фронтом или бэком), а не преобразованием UML моделей в BPMN модели и не реализацией какого-нибудь имитационного моделирования. Чё-то меня прямо прорвало, извиняюсь за этот поток )
Если подытожить весь этот поток:
1) Я думаю, что разработка своего DSL - это единственно правильный способ создания приложений.
2) Реализованы эти DSL могут быть совершенно разными способами: от диаграммы с квадратиками и стрелочками до микрофреймвока. Принципиальной разницы между ними я вообще не вижу, это детали реализации, какой способ удобнее, тот можно и использовать.
3) Каждый язык должен использоваться для своих задач. Если в коде много boilerplate кода и копипасты, возможно удобнее будет использовать какой-то более высокоуровневый язык.
4) Разные DSL используются практически повсеместно, постоянно создаются новые. Некоторые удачные, некоторые не очень удачные. Но это данность. Многие разработчики думаю, что используют только один ЯП, хотя реально они используют десятки языков, просто не осознают этого.
5) Безусловно есть неудачные примеры очень сложных и узкоспециализированных DSL или когда в приложении накручивают микрофреймвок над микрофреймвоком и в этом невозможно ничего понять. Но это не значит, что сам подход неправильный.
Блин, я никак не могу закончить это сообщение :) На самом деле после всего этого опуса до меня дошло, что я просто являюсь адептом языко-ориенированного программирования и расширяю его на всё программирование вообще. Т.е. в моём понимании все разработчики на самом деле используют ЯОП, просто в разной степени осознают это.
siziyman
27.06.2022 11:22+1Многие фреймвоки реализуют сразу несколько вариантов из перечисленных выше. Например, в Spring одно и то же можно сделать вариантами 4, 5 и 6.
Нет, вы извините, но ставить равенство между тем, что в спринге можно описать кодом и тем, что можно описать конфигом (что аннотациями, что конфиг-файлами), категорически нельзя. Код писать всё равно придётся, конфигурация остаётся только конфигурацией, пусть и умной и с кучей хороших дефолтов в разных местах, о которых вы могли и не подумать.
Ares_ekb
27.06.2022 18:21Согласен. В случае с React наверное пример был корректный. Можно использовать JSX, а можно то же самое написать на JavaScript/TypeScript.
Для Spring, да, разными способами можно описать только конфигурацию приложения. А реализация всего этого всё равно пишется на ЯП общего назначения. Хотя если посмотреть на какой-нибудь Spring Cloud Gateway, то там в конфигах можно описывать уже достаточно сложные правила и может быть даже удобнее чем в коде.
funca
27.06.2022 14:06И с тех пор бытует мнение, что вообще все эти квадратики со стрелочками, текстовые DSL и т.п. не нужны, потому что они не могут заменить языки программирования общего назначения
На то есть чисто технологические причины. Разработка DSL не уменьшает общую сложность решения, она лишь перекладывает ее из одного места в другое, зачастую увеличивая ее там напорядок.
Для работы с DSL нужен обмен знаниями и соответствующие инструменты (начиная с банальной подсветки синтаксиса и т.д.), инвестиции в разработку которых могут ни когда не окупиться.
Кодогенерация это ад в поддержке (ни кто не может сделать нормально с первого раза), поскольку нужно знать не только целевой язык, но и логику работы кодогенератора, и учитывать как изменение скажется на всей массе проектов, которые могут не быть под вашем контролем. Если же вы здесь пользователь, то можете ждать годами когда вендор соизволит починить баг в кодогенераторе.
Графический способ это лишь одно из возможных представлений, которое ни чего не говорит ни о надёжности, ни о нагрузках, ни о юзабилити, ни о массе других нефунциональных требованиях, которые существенно влияют на архитектуру. На этом уровне сложно решать вопросы версионирования и слияния. Это все мега удобно для проектирования, когда у вас один архитектор, десяток-другой сущностей и нужно показать определенные аспекты. Когда их становится больше, то диаграммы превращаются в месиво.
Короче я не против DSL как идеи, и в определенных задачах в них есть смысл. Но это ни разу не замена ЯП общего назначения.
Ares_ekb
27.06.2022 17:59Кодогенерация это ад в поддержке (ни кто не может сделать нормально с первого раза), поскольку нужно знать не только целевой язык, но и логику работы кодогенератора, и учитывать как изменение скажется на всей массе проектов, которые могут не быть под вашем контролем.
Другой вариант - интерпретация, но это может оказаться ещё большим адом, потому что фиг его знает что там в рантайме происходит, пока не запустишь не узнаешь. А в сгенеренный код можно хотя бы посмотреть.
В целом, да, конечно это ад. Когда Gradle или Maven проект не собирается, попробуй пойми что там внутри происходит. Или, например, SQL запросы тормозят и нужно смотреть планы их выполнения. С GitLab CI/CD я недавно намучился, прочитал тонны документации, pipeline нормально начал работать только после 150 запуска. В докере иногда загадочные вещи происходят.
Какая альтернатива-то? DSL и так используются везде, это данность. Отказаться от них и писать всё на языках программирования общего назначения? Но и в их компиляторах/интерпретаторах могут быть баги. Перейти на ассемблер?
Что делать с типовым boilerplate кодом? Мне лень даже копипастить один и тот же код, я скорее напишу какой-нибудь генератор, который это будет делать за меня.
Кодогенераторы бывают очень разные. Например, у меня транслятор из OCL в Java занимал 2000 строк. Транслятор из Xtext (BNF-подобный язык) в JavaScript занимал строк 200. Это достаточно простой код, который легко сопровождается. Я сталкивался и со сложными кодогенераторами, например, в SCADE один из кодогенераторов был написан на Tcl, проще было его с нуля переписать, чем разбираться. Но я не согласен с тем, что кодогенераторы это обязательно что-то очень сложное, что разрабатывается годами, занимает сотни тысяч строк кода.
На этом уровне сложно решать вопросы версионирования и слияния. Это все мега удобно для проектирования, когда у вас один архитектор, десяток-другой сущностей и нужно показать определенные аспекты. Когда их становится больше, то диаграммы превращаются в месиво.
На прошлом проекте в модели данных у нас были тысячи сущностей, сотни процессов. Десятки аналитиков в разных компаниях из разных стран, создающие эти модели. На текущем проекте больший акцент на процессах, их десятки тысяч, сотни моделировщиков. Со слиянием, да, есть сложности. Есть инструменты типа EMF Compare, EMF DiffMerge, ... которые позволяют это делать. Но на практике проще и правильнее разделить зоны ответственности, чтобы потребности в слиянии изменений не возникало вообще.
Короче я не против DSL как идеи, и в определенных задачах в них есть смысл. Но это ни разу не замена ЯП общего назначения.
Конечно это не замена, но я не вижу какой-то принципиальной пропасти между DSL и ЯП общего назначения. Например, мне нужно реализовать какого-нибудь поискового робота. Я могу описать для него конфиг на YAML:
description: News parser crawl: document: http://some-news.example.com interval: 1m article: path: html/body/div.article title: h1.title body: div.content publicationDate: path: span.date format: YYYY-mm-ddВ соответствии с этим конфигом робот может раз в минуту с указанного адреса скачивать HTML-страницу, находить на ней теги div с классом article, в каждом из них находить заголовок, содержание и дату новости.
Могу для того же самого запилить DSL:
define crawler('News parser') { crawl('http://some-news.example.com') { interva = 1m for (`html/body/div.article`) { add() { title = `h1.title` body = `div.content` publicationDate = date(`span.date`, 'YYYY-mm-dd') } } } }Могу описать примерно то же самое на Java (псевдокод):
public class NewsCrawler implement ICrawler { public String getDescription() { retrun "News crawler"; } public int getInterval() { return 60; } public void run() { Document page = PageService.getPage("http://some-news.example.com"); for (Node article : page.get("html/body/div.article")) { ArticleService.add( article.get("h1.title"), article.get("div.content"), article.get(parseDate("span.date", "YYYY-mm-dd"))); } } }Могу сделать то же самое, но с аннотациями и Fluent API:
@Crawler("News crawler") public class NewsCrawler { @Crawl(interval = 60) public ArticleProvider run() { return Document.get("http://some-news.example.com") .articles("html/body/div.article") .title("h1.title") .body("div.content") .publicationDate("span.date", "YYYY-mm-dd"); } } }Я не вижу принципиальной разницы между всеми этими вариантами. Есть определенная предметная область "Парсинг сайтов". В ней есть свой набор базовых понятий: поисковый робот, документ, который парсится, материалы в этом документе, у которых есть заголовок, содержимое и дата.
Допустим у нас контора, которая пилит такие парсеры сайтов. На начальном этапе каждый пилит как хочет. Затем мы определяем структуру типового парсера, создаём какой-нибудь интерфейс парсера с тремя методами getDescription(), getInterval(), run(), а внутри run() можно писать что угодно. Затем мы пишем какие-нибудь рекомендации по содержимому метода run() типа для получения страницы желательно использовать такой-то класс, а для парсинга HTML такой-то. Затем мы можем реализовать типовые методы для получения страницы, для извлечения из неё материала и т.д. И уже на этом этапе мы создали не что иное как embedded DSL!
Если мы используем какой-нибудь Lisp, то можем пойти немного дальше и определить для нашего DSL более подходящий синтаксис, чем например в Java.
Можем пойти ещё дальше и разработать полностью свой синтаксис для нашего для DSL (например, с помощью Xtext, он практически даром даёт парсер, текстовый редактор с подстветкой синтаксиса и автодополнением). Можем не заморачивать со своим синтаксисом, а использовать тот же YAML.
А затем можем написать либо интерпретатор для этого DSL или этих YAML конфигов, либо транслятор в Java код или ещё во что-то. Причем результирующий код может выглядеть ровно так же как в примерах выше, это не обязан быть какой-то лютый нечитаемый треш.
Я не топлю за то, что абсолютно всегда нужно делать свой DSL с каким-то своим синтаксисом. Я говорю о том, что к разработке любого софта можно относиться как к созданию DSL, т.е. выделить в приложении какие-то осмысленные области, для каждой области определить набор базовых понятий и конструкций. А какой при этом у этих DSL будет синтаксис (какой-то кастомный, YAML, или это будет просто eDSL в Java) - вообще пофиг, что удобнее, то и нужно использовать.
BugM
28.06.2022 01:49+1Сделать язык это сложно. Правда сложно.
Даже довольно простой язык спроектировать так чтобы им можно было пользоваться и не страдать это уровень выше сеньоров. Людей способных на такое обычно звездами называют. И у них часто есть всякие PhD и статьи в интересных местах. А еще они Лисп любят (это личное наблюдение без пруфов).
Написать и развивать язык не сильно проще. Сеньоры плачут над практическими реализациями AST и оптимизаторами AST. Когда туда надо запилить новую фичу или поправить баг в корнер кейсе в глубинах реализации. Поддержка приемлимого басфактора для вашей реализации языка это дорого само по себе. На это надо жечь много времени сеньоров.
Это нормальный путь для написания софта. Но на него способен мало кто. Окупается он еще реже. Нанять джунов делать "типовые формочки" на любой модной сегодня технологии обычно проще и дешевле.
dididididi
26.06.2022 21:05+1Я шесть лет назад, смотрел как фронтовики кроваво сражаются с комбо боксом с множественным выбором и поиском, прошло 6 лет. Бойня стала только кровавей) Но раньше её джун делал. С развитием новых технологий, задачка стала под силу только тимлидам)
dididididi
26.06.2022 19:19-9На заре карьеры работал Джуном. Три Джуна подчинялись мидлу, три мидла сеньору. Очень чистый код, и большинство задач решались копипастой. Если у вас на проекте не так, то сеньора у вас там нет.
За следующие пять лет, даже близко такого не видел, зато в проекте всё сеньоры.
BugM
26.06.2022 22:30+9Сеньор руководящий командой из 12 человек это матерый тимлид. Код он будет писать максимум 1-2 дня в неделю. Остальное время он будет управлять людьми, сидеть на совещаниях о продукте и заниматься планированием.
Счастье если такие люди у вас на проекте есть. Их найти еще сложнее чем сеньоров.
EighthMayer
26.06.2022 23:44+14Очень чистый код, и большинство задач решались копипастой
Чистый код с копипастой. Клёво.
urvalla
26.06.2022 22:49Мне кажется, заголовок не соответствует статье. В статье говорится о том что не стоит оставлять одних лишь сеньоров. С таким утверждением согласен - сеньоры оставшись в одиночестве банально тухнут из-за обилия рутины и начинают страдать от синдрома самозванца.
datacase
27.06.2022 05:29+5Какие-то кадровые фантазии про сферических программистов. В статье верные джуны и нервозные сеньоры, по факту наоборот. Джун наберётся опыта и свалит с зарплатой, полученной за процесс, а сеньор будет колотиться до приемлемого результата, особо при этом не нервиничая, так как повидал уже всякого.
Aleksej2020
27.06.2022 13:04+1Так и есть. Любой джун или младший или ассистент где-то через год прекрасно понимает - заинтересованна ли компания в его росте, или планирует им закрывать дыры.
Dime_n_u
27.06.2022 06:17Прям ненависть к джунам какая-то. Может я что-то не понимаю в антиджуновских изречениях, но может проблема была в том, что набрали джунов, сказали работать и благополучно забыли про них? Менторство абормотов - не про деньги же да и вводить их в курс дел лень. К тому же слабо представляю себе сеньора, которому нравится когда его дёргают "сделай тут, поправь там и тут ещё сделай" и ещё меньше представляю работодателя, который будет платить большие деньги за работу джуна. Да и если тренд - сеньору делать работу джуна/мидла, то последние наверняка могут претендовать на зп приближеную этого самого сеньора. Ну и в таких перспективах теперешние сеньоры как динозавры ибо какой смысл учиться на ИТ, если тебя априори не возьмут на работу? Вобщем если в вашей организации отсутствует рутинная работа, то вы прям редкостные молодцы, в остальных случаях какой-то сюр
rdo
27.06.2022 08:46+8У статьи неверное и даже дезинформирующее название. Если по-честному, она должна называться "Вам скорее всего не нужен сеньор на каждую должность в проекте"
youlose
27.06.2022 11:30+2Почему-то не увидел в статье самого главного - про найм: "как нанять мидла, если владелец бизнеса или HR не разбирается в предметной области?". Работал с несколькими бизнесами, где за зарплату сеньора работали джуны и исправлять результаты их жизнедеятельности оказалось очень и очень дорого и сложно.
acsent1
28.06.2022 11:22Хорошие мидлы всем нужны. Но таких людей очень мало. Либо джуны, либо сеньоры.
Мидл - это переходный вариант, на год-два. Ибо это странно, когда человек секет в программировании, развился, но до сеньора не дорос. Те кто не дорастают, они и до мидлов не дорастают.
Есть конечно еще и роскстары, до туда, да, не все могут дорасти - это нужно талант иметь
4eyes
Потому, что автору статьи так захотелось написать.
Из моих личных наблюдений, из нескольких разных компаний, Junior прыгают туда-сюда, как кузнечики, Middle чуть дольше задерживаются, но вот как раз Senior задерживаются дольше всех. И по-моему, это логично: сложно выполнять задачи senior-уровня до того, как хорошо ознакомишься с проектом, коммуникации с заказчиками и бизнес-аналитиками также лучше идут, когда ты не воспринимаешься "новеньким".
BobArctor
Чем больше ты "синьор" тем сложнее\дольше "скакать", особенно если к переходу есть список требований (формальный титул позиции не меньше текущего, заработок +n%, стек\и такие-то, культура\методология\область деятельности новой компании такие-то).
У джуна список требований обычно попроще поэтому и переходы они совершают быстрее.