тем, кто с воображением)

без воображения? может в менеджмент?)

в менеджмент тем - кто технически слабый.

и в аналитику еще.

технически слабые дата сайнтисты которые ранают sql-ки раз в неделю что бы отчет начальству передать?

"то чувство когда твою работу может выполнить скрипт"

нет, они просто ходят по офису и говорят то и дело разным сотрудникам: "ну как дела? когда закончишь?" и "ну что, разобрался в задаче?", "давай, делай быстрее, срок вчера вышел".

Тогда это не сеньёр в мидл, который решил что он сеньёр.
Джун - усердно работает но проект не продвигается.
Мидл -  усердно работает но проект продвигается
Стронг мидл - чутка работает но проект хорошо продвигается.
Сеньор - весь день сидит пьёт кофе в курилке, за компом час в день, но при этом проект делается на максимальных скоростях.

про сеньера, потому что под ним джуны, которые фигачат код. но продвигается проект именно от сеньера, а не от джунов)

В т.ч.

иными словами. если ты работаешь на проекте, который очень хорошо спроектирован - ты сеньер. довольно хорошо - мидл + . туда сюда - мидл. хреновое говнолегоси копролит - джун.

в целом этот спор про синьеров не синьеров не столь важен. Есть и другие градации. Мол есть люди которым тяжко перепрыгивать между стэками но они идут вглубь - узкие эксперты. Есть люди которые берутся за все но поскольку возможности ограничены знают все по чуть-чуть. Этого хватает для 80% задач и еще на 20 нужны те узкие специалисты. Есть люди которым хорошо дается управление, есть те кто плохо делигирует. Есть те кто любят впадать в analysis paralysis а есть те кто не особо думают над проблемой и "потом разберемся".

Простые градации типа джун мидл синьер подходят только для градации заработной платы/потенциал для ответственности и то в пределах конкретной организации*. Этого недостаточно что бы понять что человек из себя представляет и какую работу он будет выполнять хорошо. Нужен будет ему контроль внешний или "самоорганизуется как нибудь"

В цеом это просто попизделочки без особого смысла, так для развлекухи )

все в бюрократию упирается) важно, насколько команда быстро и дешево разрабатывает проект, и насколько ей приятно это делать.

тоже оч опасное упрощение - "насколько дешево пилить проект".

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

для аутсорса да - там расходы на разрботку это оч большая статья расходов. В условии продуктов у тебя это как минимум меньше 50% бюджета а часто мы говорим о цифрах типа 10-20% бюджета

ну просто ты снижаешь  потолок продукта. да, его до поры до времени можно пилить так, но потом станет невозможно, стоимость, сложность и опасность разработки взлетит экспоненциально

и вот когда речь идет о том что на разработку уходит лишь 10-20% ревенью то оптимизация этих расходов на 10% может дать потенциально меньше прибыли чем скажем оптимизация деливери на 10% (то есть заплатили столько же но получили фичи на 10% раньше).

возможно даже увеличение затрат на разработку при том же наборе фич, при условии предсказуемости планирования и быстрой доставке (инвестиции во всякую автоматизацию, континиус деливери, вот это все) может дать сильно больше опций бизнесу искать доп прибыль

но это конечно при условии если бизнес анализирует что происходит а не просто "так фичу запили" и через пол года на вопрос сколько людей юзают фичу ответ дать не могут