В 2018 году до ИТ-бума на все мои предложения, как сделать задачу и идеальными, я получал 3 вопроса - Зачем это нужно? - Сколько это стоит? - Что будет, если не сделаем?

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

Временами я злился, расстраивался и не понимал, почему рефакторинг ежегодного лендинга не одобряют?

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

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

И вот тут и произошла базовая подмена ценности разработчика.

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

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

Это видно по резюме. Многие кандидаты с опытом 2-5 лет, рассказывая свой опыт через достижения, выдают странную картинку.

Например, внедрение темной темы в приложение уменьшило количество закрытий банковских карт на 20%. А точно это с темной темой связано? Я вот не уверен, а человек очень.

Технические задачи выглядят еще более грустно. Например, разработчик с опытом 5 лет пишет, что перевел лендинг с нативного JavaScript на TypeScript, что позволило упростить разработку. На вопрос: «а что по цифрам?», он ответил, что разработки на лендинге не велось больше, так как он не зашел аудитории. Зачем тогда рефакторили и тратили время, деньги ? Ответа на этот вопрос не последовало.

И это не единичные случаи.

Целые команды жили по принципу выдачи кода без обоснования его надобности.

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

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

В сложившейся ситуации снова нужно давать ответы на 3 вопроса: - Зачем это нужно? - Сколько это стоит? - Что будет, если не сделаем?

Ответов требуют не только от разработчиков, но и от команд. Те, кто не смог ответить - сокращены.

Как не стать жертвой подмены понятий?

1. Принять то, что сам код дорого не стоит. Дорого стоит решение проблем с его помощью.

2.Уметь только переводить требования в код сейчас недостаточно. Нужно уметь разбираться в предмете и бизнесе так, чтобы с помощью кода и технологий делать их эффективнее.

3. Стать инженером. Информационные технологии - отражение реального мира и его процессов. Нужно понимать связь между строчкой кода и тем, что происходит в реальности, как код живет, куда движется, на кого влияет, где крутится и работает.

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

5. Не опускать руки и учиться, адаптироваться и смотреть на свой опыт под другим углом. Будущее за теми, кто двигается, стремится и хочет быть полезным.

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