В Испании все разработчики — сеньоры
Экстраполяция IT
Рынок разработчиков сейчас очень раздут и перегрет, даже несмотря на то, что качество среднестатистического разработчика падает. Интернет-мем «украинский сеньор» был актуален еще десять лет назад и сейчас он заиграл новыми красками. Раньше такими сеньорами можно было стать, потрудившись над парой проектов лет пять-шесть, то сейчас восьмимесячный разработчик вполне чувствует в себе силы претендовать на позицию выше новичка, а те ребята, которые уже пороху нюхали пару лет уверены, что любой аутсорс-проект им по силам. Немало копий было сломано, рассуждая на тему того как же сравнить крепко стоящего на ногах разработчика с тестировщиком или, упаси боже, дизайнером. Это даже не принимая во внимание различия в профессиональных навыках внутри отдельно взятого подразделения, допустим, владеющих разными языками разработчиков.
Давайте вспомним основной предмет манипуляции нерадивых разработчиков и управленцев персоналом. По общепринятым стандартам, основное отличие «джуниора» от «мидла» считается возможность выполнять задачу самостоятельно. За джуном все глаз да глаз, когда миддлу можно поручить задачу и быть уверенным, что тот ее выполнит. «Сеньор» же вполне в состоянии увидеть задачу, а не просто ее выполнить, в отличие от предыдущих двух. Казалось бы, вполне простые и очевидные правила, но их неоднозначность и скрытый смысл некоторых задач дают волю алчным и тщеславным разработчикам неоправданно быстро идти вверх по карьерной лестнице.
Ведь действительно, правильно поставленная задача сильно облегчает понимание того, как она может быть сделана. И разработчик, которому задачу поставили крайне туманно или запутанно, скорее всего решит ее неправильно. В результате получается, что процесс правильной постановки задачи вселяет ложную надежду растущего опыта в молодого разработчика. Еще одной заусеницей для понимания собственного уровня мастерства молодого разработчика является случайная череда несложных задач. Решив пятую подряд однотипную задачу у молодого и перспективного начинает пропадать запал, монотонная работа начинает казаться скучной и неинтересной. Создается ложное ощущение того, что испытуемый перерос подобного рода задачи и вполне в состоянии справляться с задачами посложнее.
Отличить сферического сеньора в вакууме от кубического миддла в газообразном состоянии крайне сложно. Тот разработчик, что уже утвердился как «середнячок», начинает иметь свое мнение на предмет того, с чем он еще не сталкивается. Допустим, стратегический выбор инструмента или архитектуры приложения. Взрослые программисты решают за него каким языком, какой парадигмой и каким инструментом пользоваться, насаждают технологии и навязывают процесс ведения проектом. Конечно же, наш середнячок недоволен. Это как в совершенно любом государстве – все, кто умеет управлять страной, уже давно работают таксистами, продавцами и мерчендайзерами, а у власти сидят сплошные идиоты и тупицы. Такие вот мидлы начинают высказывать свое мнение по поводу и без повода, и в некоторых достаточно редких случаях оказываются правы. В тех случаях, когда они не правы, их подстраховывают взрослые мудрецы своевременно присекая неправильные стратегические решения, а если мнение гуру совпадает с мнением середнячка, то у последнего возникает ощущение, что он может все то, что могут и взрослые мастодонты от программирования. В итоге имеем гипертрофированное чувство собственной мудрости.
Естественно, работая в одном и том же коллективе, закрытыми глазами можно с уверенностью сказать кто тут сеньор Помидор, а кто просто Чипполино. И добиться несправедливого прыжка выше головы в фирме, где твои навыки известны всем и даже повару, крайне тяжело. Поэтому более выгодной стратегией таких разработчиков является частая смена компаний с целью продать себя дороже в следующей компании.

Рекрутерам же, крайне выгодна такая стратегия разработчиков. Она увеличивает количество проведенных собеседований и нанятых разработчиков и, соответственно, размер рекрутерских бонусов. Директорам аутсорсинговой компании и отделу продаж тоже выгодно иметь такой вот поток разработчиков. Как и намеренное завышение уровня разработчика — заказчики постоянно требуют разработчиков, постоянно жаждут сеньоров и готовы за них платить.
В итоге получаем вполне очевидное равновесие Нэша, в котором отклонение от уже устоявшейся стратегии неизбежно приведет к уменьшению выигрыша (в данном случае — зарплаты или прибыли). Хотя в целом ситуация достаточно паршивая, но как отойти от равновесия Нэша не придумал даже сам Нэш.