Есть довольно популярное мнение, что разработчики выгорают потому, что программирование само по себе очень сложное. Мол, сидишь целый день, смотришь в код, решаешь какие-то абстрактные задачи, мозг кипит, отсюда и все проблемы.
Отчасти это правда. Разработка действительно не самая простая деятельность. Нужно держать в голове логику, данные, зависимости, странное поведение системы, чужие решения, свои решения, которые ты уже успел пожалеть, и еще миллион мелочей.
Но если честно, чаще всего выжигает не сам код.
Код как раз может быть нормальной частью работы. Иногда даже приятной. Сел, разобрался, написал, проверил, увидел результат — красота. Проблемы начинаются там, где вокруг этого кода появляется хаос.
Давайте разбираться.
1. Разработчика выматывает не сложность, а неопределенность
Сложная задача — это нормально. Более того, многим разработчикам как раз интересны сложные задачи. Есть проблема, есть ограничения, есть время подумать, есть возможность выбрать решение.
А вот когда задача звучит как "сделайте нормально", "почините, оно как-то странно работает" или "надо срочно, детали потом" — вот тут начинается веселье.
Разработчик не телепат. Он не может залезть в голову заказчику, менеджеру, пользователю и понять, что именно там имелось в виду. Но при этом часто от него ожидают результата так, будто все очевидно.
В итоге вместо разработки начинается археология:
- что вообще должно произойти;
- кто этим будет пользоваться;
- где это уже было описано;
- почему в задаче одно, в макете другое, а на созвоне сказали третье;
- кто принимает решение;
- что считать готовым результатом.
И вот это выматывает сильнее, чем сам код.
2. Постоянная смена приоритетов ломает голову
Сегодня задача срочная. Завтра она уже не срочная, потому что появилась еще более срочная. Через два дня возвращаемся к первой, но теперь там новые требования. Через неделю выясняется, что вообще надо было делать третий вариант, потому что бизнес "чуть переосмыслил концепцию".
Звучит знакомо (вопрос, конечно же, актуален для разработчиков)?
Для человека со стороны это может выглядеть как обычный рабочий процесс. Ну подумаешь, поменяли приоритеты. Бизнес живой, рынок меняется, все дела.
Но для разработчика каждая такая смена — это не просто "переключился и пошел дальше". Нужно снова загрузить контекст в голову, вспомнить, где остановился, понять, что уже сделано, что теперь неактуально, что надо переделать, что может сломаться.
Контекст в разработке — штука дорогая. Его нельзя включить за секунду, как лампочку.
Когда тебя дергают каждые пару часов, ты вроде бы весь день работал, но вечером смотришь на результат и понимаешь: сделал мало, устал сильно, а завтра будет то же самое, а сегодня был только понедельник.
3. Созвоны ради созвонов, встречи ради встреч тоже не помогают
Созвоны и встречи нужны. Иногда без них никак. Быстро обсудить непонятный момент со всеми участниками процесса, синхронизироваться, принять решение — нормальная рабочая история.
Проблема начинается, когда созвоны и встречи превращаются в замену мышления.
Вместо того чтобы нормально описать задачу — созвон. Вместо того чтобы принять решение — встреча и мозгоштурм. Вместо того чтобы зафиксировать договоренности — опять созвон, после которого каждый понял всё по-своему. Потом еще одна встреча, чтобы обсудить, почему после прошлого созвона ничего не стало понятнее.
И вот ты сидишь, слушаешь обсуждение, где 40 минут люди ходят кругами вокруг одной и той же проблемы, а потом в конце звучит гениальное: "Ну давайте пока сделаем как-нибудь, потом поправим".
В этот момент где-то в мире грустит один разработчик. Возможно, сразу несколько.
4. Ответственность есть, влияния не всегда
Еще один неприятный момент: разработчик часто отвечает за результат, но не всегда может влиять на решения, которые к этому результату приводят.
Например, сроки уже продали. Архитектуру уже утвердили. Дизайн уже согласовали. Клиенту уже пообещали. А потом приходит разработчик и говорит: "Ребята, тут так не получится". И внезапно он становится человеком, который мешает двигаться вперед.
Хотя по факту он просто первым увидел, что мост заканчивается посреди реки.
Самое выжигающее — когда ты заранее предупреждаешь о проблеме, тебя не слушают, потом проблема случается, и тебе же приходится её разгребать. Причем часто в срочном режиме и с вопросом: "А почему мы раньше об этом не подумали?".
Действительно, почему.
5. Легаси само по себе не зло. Зло — легаси без контекста
Про легаси любят говорить так, будто это всегда старый ужасный код, написанный древними шаманами в состоянии морального падения.
На самом деле легаси — это просто код, который уже живет в проекте. Иногда он нормальный. Иногда странный. Иногда очень странный. Но чаще всего проблема не только в коде, а в отсутствии контекста.
Почему это сделано именно так? Кто это писал? Какие ограничения были на тот момент? Можно ли это трогать? Что сломается, если мы это поменяем? Есть ли тесты? Почему вот эта функция называется "newFinalFix2" и используется в пяти местах, где по логике её быть не должно?
Когда ответов нет, любая правка превращается в саперную работу.
И вот тут снова появляется хаос. Не "сложная инженерная задача", а именно хаос: отсутствие документации, отсутствие владельца решения, страх тронуть лишнее, неожиданные побочные эффекты и вечное "только аккуратно, там всё связано".
6. Срочность убивает качество, а потом качество убивает продукт
Почти в любой команде бывают моменты, когда надо быстро. Это нормально. Запуск, важный клиент, критичный баг, бизнесовая необходимость.
Проблема начинается, когда "быстро" становится постоянным режимом.
Сначала мы быстро делаем одну фичу. Потом быстро чиним последствия. Потом быстро допиливаем костыль. Потом быстро добавляем еще один костыль к первому костылю. Потом кто-то говорит: "Надо бы это нормально переделать", но времени нет, потому что уже горит следующая задача.
И вот через полгода команда живет внутри конструкции, где каждый новый шаг страшно делать, потому что непонятно, что отвалится.
Выгорел ли разработчик от кода? Не совсем.
Он выгорел от постоянного режима пожара, где качество сначала приносится в жертву скорости, а потом все удивляются, почему стало медленно, дорого и больно. А могут ещё и к разработчику в итоге прийти с претензиями, нельзя что ли было нормально сделать?) Ведь срок “вчера” – не помеха.
7. Хаос делает результат невидимым
В нормальной работе есть приятное чувство: была задача, ты её сделал, стало лучше. Это очень важно. Человеку нужно видеть результат своего труда.
Но в хаосе это чувство часто пропадает.
Ты целый день что-то чинил, переключался, уточнял, переделывал, ждал ответов, разбирался, почему требования снова поменялись. Формально ты работал. Фактически ты тушил мелкие пожары и пытался удержать проект от развала.
А в конце дня возникает ощущение, что ничего полезного не сделал.
Это очень неприятная штука. Потому что усталость есть, а удовлетворения от результата нет.
8. Что с этим делать?
Полностью убрать хаос невозможно. Разработка — это не лаборатория в вакууме. Есть бизнес, люди, сроки, деньги, клиенты, ошибки, неожиданные изменения. Всё это будет всегда.
Но хаос можно хотя бы не превращать в стиль управления.
Если вы руководитель, тимлид, менеджер или человек, который влияет на процесс, то помогает довольно базовая гигиена:
- нормальное описание задач;
- фиксация договоренностей после обсуждений;
- понятные приоритеты;
- адекватное планирование;
- возможность сказать "так не получится" без превращения в врага народа;
- время на технический долг;
- уважение к контексту разработчика;
- меньше созвонов и встреч, которые можно заменить текстом;
- честный разговор о рисках до того, как всё загорелось.
Это не магия и не какая-то невероятная корпоративная методология. Это базовая гигиена работы.
А если вы обычный разработчик, то тут всё сложнее. Вы не всегда можете поменять процессы в компании, отменить бессмысленные созвоны или заставить бизнес нормально ставить задачи. Но кое-что сделать всё равно можно:
- фиксировать важные договоренности письменно;
- проговаривать риски до начала работы, а не когда уже всё горит;
- не стесняться задавать "глупые" вопросы, если задача мутная;
- декомпозировать непонятное на понятные куски;
- не брать на себя молча ответственность за решения, на которые вы не влияли;
- не героически тащить постоянный пожар как будто это ваша личная обязанность.
И главное — не превращайте постоянный пожар в личную норму. Если хаос разовый, это работа. Если хаос каждый день и всем вокруг нормально, то вопрос уже не только в задачах, а в месте, где вы работаете.
Если коротко: разработчики редко выгорают от того, что им "приходится писать код". Чаще они выгорают от среды, в которой писать этот код становится невозможно без постоянного стресса.
Код можно починить. Хаос вокруг кода — сложнее.
Подписывайтесь на SkylinnTime - https://dzen.ru/skylinntime. Здесь будем говорить про IT, разработку и игровую индустрию без сказок про лёгкие деньги, но и без лишнего нытья. Пишет практикующий Senior Fullstack web developer и teamlead, который всё это видит не только со стороны красивых вакансий.