На этой должности вы будете плохим разработчиком

Вы никогда не думали, что вас могут уволить не из-за того, что вы глупый и плохой разработчик, а из-за того, что все процессы в организации построены так, что вы на данной позиции априори будете кривым и плохим! И единственный вариант перестать быть кривым — сменить ответственный участок, за который вы отвечаете.
zzstvsh0fmzj_pvq-s2dfwl9l1y.jpeg

Если вы работали в больших компаниях (больше 30 разработчиков), вы могли бы заметить, что на определенных участках ответственности разработчики меняются гораздо чаще, чем на других. И что самое интересное, часто разработчиков увольняют за некомпетентность, нарушение трудовой дисциплины (ругается с тех-диром, лидом), и общий пофигизм (перегорание). И знаете, в этом есть определенная закономерность.

Почему вы становитесь плохим разработчиком


В каждой компании есть разные участки ответственности. Кто-то пилит новые фичи, кто-то дорабатывает существующие, кто-то занимается развитием и оптимизацией инфраструктуры, а кто-то поддерживает легаси системы и исправляет ошибки, которые в них существует. И если мы говорим о вероятности стать плохим разработчиком, мы переходим к легаси системам, и чем эти системы меньше связаны с клиентами, и сильнее связаны с внутренним офисом, тем эта вероятность выше.

Легаси системы не сексуальны


Допустим проходит месяц, идет представление того, что разработчики по командам успели сделать.

  • Продуктовые команды показывают новые фичи, все довольно хлопают, как стало круто.
  • Команды доработки существующего функционала показывают, как они круто исправили ошибки и недочеты, которым клиентами насиловали саппорт и отдел продаж (все в восторге).
  • Команда развития инфраструктуры показывает, что они смогли оптимизировать работу и теперь мы сможем сэкономить 4–5 тысяч долларов в месяц на серверах (тех-дир в экстазе).
  • Команда поддержки легаси систем, говорит, что они исправили формирования отчета для бухгалтерии, если шли невалидные данные от контрагентов (Всем пофиг).


Т.е. у окружающих, в том числе владельцев бизнеса, появляется четкое понимание, что одни ребята развивают продукт, экономят средства, снимают боль клиентов, а кто-то делает какую-то второстепенную фигню.

Легаси системы наказывают твой зад


Представьте, что вы разрабатываете новый функционал, и почему-то начинают гореть сроки. Владелец бизнеса идет к продукту и начинает насиловать продакта, что все плохо, что ужасно. Продакт принимает основной гнев, и уже как-то начинает «ребята давайте быстрее, у нас горят сроки и прочее». Причем все понимают, что это новый функционал, срыв сроков — это обычное дело, поэтому относятся с пониманием. Т.е. разработчиков никто напрямую не прессует.

Если мы говорим про легаси ситемы, то чаще всего ситуация выглядит так. В лида заходит какой-то из отделов (продажи, бухгалтерия, маркетинг итд). И говорят, вот у нас проблема её надо починить. Лид передает разработчику и забывает про это дело.

Условно через неделю в лида снова заходит руководитель отдела маркетинга, продаж и говорит — какого хера вы не починил этот косяк. Мы не можем так работать, «нам что зайти выше?!». Лид заходит в разработчика и говорит «Какого хрена меня тут прессуют из-за того, что ты тут что-то не можешь сделать. Давай уже исправь это».

Легаси системы не дают тебе ценность


Представьте идет распределение премий. В первую очередь их получат те, кто внес «вклад» в развитие продукта. Ведь они крутые ребята, которые развивают продукт, делают новые фичи и прочее. Клиенты довольны, продажи довольны, эти ребята — герои.

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

Плюс нужно понимать, что если вы сделали новую фичу, то все видят, что есть фича, вы её сделали — вы молодцы. Когда мы делаем какой-то фикс по легаси, то результат этого труда забирает себе отдел маркетинга, продаж, поддержки –, но не вы.

Легаси системы недопускают ошибок


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

Когда мы говорим про легаси модули, то они должны работать правильно. Поэтому очень часто происходят кейсы, когда разработчик вносит правки в систему, которую он не очень хорошо понимает. Отдел тестирования ловит какой-то баг, разработчик фиксит его, потом тестирование ловит еще какой-то баг и так далее. Или не дай бог ошибка попадет на прод, и уже руководитель какого-то отдела зайдет условно в лида и скажет «Какого хрена вы там наделали, у нас ничего не работает».

В итоге, в первом случае — ошибка, это допустимая ситуация. Во-втором, вы мудак, что допустили ошибку и все сломали.

Разработчика с легаси систем легко уволить


Представьте, что появляется мысль, что кто-то из разработчиков плохо работает, и его нужно уволить. Лид заходит в ПМ спрашивает про увольнение. ПМ скажет «Вы там что сдурели, у нас и так горят сроки, если вы сейчас уволите Макса, мы точно не успеем. Я прямо скажу тех-диру, что это ваш косяк, и пусть он уже вас трахает. Лид думает, что действительно трахать будут его, поэтому он откладывает данное увольнение». А там уже и Макс одумается, либо еще что-то произойдет.

Если мы говорим про легаси системы, то никто особо не будет заступаться за такого разработчика. Ведь если он работает хорошо, ничего просто не происходит. Если он работает с ошибками — то он мудак, который вредит работе другим отделам.


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

© Habrahabr.ru