Выгорание в IT:
мозг не создан для Jira

Ты садишься за комп в девять, открываешь IDE. Тикет понятный, задача знакомая, оценка два часа. Начинаешь писать, и через три минуты прилетает нотификация в Slack. Ты переключаешься, отвечаешь, возвращаешься к коду. Перечитываешь последние пять строк, потому что забыл, где остановился. Ещё минута, и Jira прислала комментарий к вчерашнему PR. Снова переключаешься, читаешь, возвращаешься.

Ты ещё ничего не сделал, а прошло сорок минут. И ты уже устал. Не от работы, а от переключений. К шести вечера такое ощущение, будто разгружал вагоны, а коммитов всего полтора.

Если тебе это знакомо, ты не один и точно не слабый. Просто твой мозг не рассчитан на ту нагрузку, которую IT-индустрия считает нормой. Давай разберёмся, почему так.

Почему разработчики выгорают быстрее других?

Бухгалтер работает с числами, юрист с текстами, дизайнер с формами. А разработчик работает с абстрактными системами, которые существуют только у него в голове. Ты не видишь свой код, ты его представляешь: архитектуру, зависимости, состояния, edge cases. Всё это живёт в рабочей памяти, а она ограничена физически.

Больше половины. Каждый второй разработчик на твоём стендапе думает, что он недостаточно хорош и что его вот-вот раскусят. Что senior рядом видит, какой он на самом деле «джун». Подробнее об этом я писал в статье про синдром самозванца.

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

Выгорание тут растёт не от объёма работы, а от постоянного когнитивного и эмоционального давления, от которого некуда деться. Потому что отдых в IT - это тоже экраны, тоже код, тоже Telegram. Если ты работаешь не в найме, а на себя, то выгорание фрилансера будет отдельным паттерном: к когнитивной нагрузке добавляется отсутствие границ, нестабильный доход и невозможность «закрыть ноутбук». Часто всё это маскируется под токсичную продуктивность, когда ты не отдыхаешь, потому что не работать тебе стыдно.

Как код перегружает рабочую память?

В 1956 году Джордж Миллер опубликовал работу, которая до сих пор актуальна. Рабочая память человека вмещает 7±2 объекта одновременно. Не 20 и не 50, а семь плюс-минус два. Это аппаратный предел, который никакими лайфхаками не обойти.

А теперь посмотри, что происходит, когда ты ревьюишь чужой merge request. Тебе нужно держать в голове одновременно:

1. Бизнес-логику задачи — что вообще должен делать этот код
2. Текущую архитектуру модуля — как он связан с остальной системой
3. Состояния данных — что приходит на вход, что должно уйти на выход
4. Edge cases — что сломается, если придёт null, пустой массив, дубликат
5. Code style и конвенции команды
6. Контекст предыдущих обсуждений в тикете
7. Свою задачу, от которой ты только что оторвался

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

Был у меня клиент. Андрей, 28 лет, backend-разработчик в финтехе. Пришёл, когда понял, что не может писать код без тревоги. Буквально садился за IDE, и сердце начинало колотиться. Не от сложной задачи, а от любой задачи.

Начинаем разбираться. On-call каждую вторую неделю, и так последний год. Алерты в Sentry приходят в три ночи, в пять, в шесть тридцать. Он просыпался, чинил, ложился, а через час всё повторялось. Утром снова стендап, спринт, код.

За год его HPA-ось, гипоталамо-гипофизарно-надпочечниковая система, застряла в режиме постоянной боеготовности. Кортизол не снижался до базового уровня даже в выходные. Мозг Андрея перестал различать «ты на on-call» и «ты в отпуске». Для него любой момент стал потенциальным алертом.

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

Почему Slack и Jira — идеальные машины выгорания?

Slack сделал одну гениальную и одну разрушительную вещь одновременно: он убрал порог для коммуникации. Написать сообщение, ответить, переключить контекст - всё это теперь мгновенно. Для бизнеса это ускорение, а для мозга катастрофа.

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

Gloria Mark из UC Irvine измерила это точно: после одного переключения контекста человеку нужно в среднем 23 минуты и 15 секунд, чтобы вернуться к прежнему уровню фокуса. А теперь честно посчитай, сколько раз в день переключаешься ты. Прикинь по уведомлениям, я подожду.

Jira добавляет ещё один слой. За тикетом стоит не просто задача — это обязательство под трекингом: story points, velocity, burn-down chart. Каждый незакрытый тикет превращается в маленький стресс. Мозг не умеет «откладывать» незавершённую задачу, и эффект Зейгарник гарантирует, что она будет фоном жужжать в голове, забирая ресурсы рабочей памяти даже когда ты занят другим.

И поверх всего этого спринт. Двухнедельный цикл, в конце которого демо, то есть публичная демонстрация того, что ты сделал. Или не сделал. Для синдрома самозванца это идеальный триггер: каждые две недели наступает момент, когда тебя якобы могут «раскусить».

Ещё одна моя клиентка. Марина, 32 года, тимлид в продуктовой компании. Четыре часа в день у неё уходило на code review, ещё два-три часа на митинги, а на собственный код оставалось то, что осталось. К пятнице она буквально не помнила, что делала в понедельник. Вся неделя сливалась в одно серое пятно из PR-комментариев и Zoom-звонков.

Рабочая память Марины работала на пределе каждый час каждого дня, а контекст переключался десятки раз. Code review требует загрузки чужого контекста, митинг переключает на социальный режим, а код возвращает к абстрактному мышлению. Три принципиально разных когнитивных режима, и так каждый день.

Когда мы начали работать, она описала своё состояние так: «Я как браузер с 200 вкладками. Всё тормозит, но закрыть страшно — вдруг там что-то важное».

Сколько на самом деле стоит одно переключение контекста?

Одно переключение стоит 23 минуты и 15 секунд — столько нужно, чтобы вернуться к прежнему уровню фокуса (Mark, Gonzalez & Harris, UC Irvine, 2005). Потерянное время тут только верхний слой. Под ним лежит attention residue: часть внимания физически остаётся в брошенной задаче, и в новую ты входишь с головой, которая всё ещё дожёвывает предыдущую.

Термин ввела Sophie Leroy из Университета Миннесоты. Она показала одну неприятную зависимость: чем сложнее была прерванная задача и чем дальше она была от завершения, тем больше внимания за ней остаётся. Для разработчика это худший из возможных раскладов. Ты почти никогда не бросаешь работу на точке, где всё закончено, ты бросаешь её посреди недописанной функции.

Дальше арифметика. Если один день честно записывать каждое отвлечение, у большинства выходит 40-80 переключений за рабочий день. Комментарий в PR, вопрос в тред, алерт из Sentry, «глянь плиз на минутку», незапланированный созвон. Ни одно из них по отдельности не выглядит проблемой.

Почему «я привык работать в шуме» — самообман

Люди, которые действительно не теряют в качестве при переключениях, существуют. Их 2.5%, и Watson со Strayer назвали их supertaskers. Остальные 97.5%, включая тех, кто искренне считает себя исключением, теряют скорость и точность, просто не замечают этого изнутри.

Loh и Kanai сделали МРТ людям, которые годами живут в режиме постоянного переключения, и обнаружили пониженную плотность серого вещества в передней поясной коре. Это диспетчерская мозга: она распределяет внимание и ловит ошибки. Диспетчерская без выходных изнашивается.

Ты не только страдаешь от переключений — ты их ищешь

Вот наблюдение, которое повторяется почти у каждого айтишника, с которым я работаю. Рука тянется к Slack не в случайный момент. Она тянется ровно тогда, когда ты открыл легаси-модуль, который страшно трогать, или когда задача сформулирована так мутно, что непонятно, за какой конец её брать.

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

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

Почему код-ревью и грейды делают из тебя самозванца?

IT устроено так, что твоя работа оценивается публично и в цифрах постоянно. Код-ревью выносит каждую ошибку в тред, который навсегда останется в истории репозитория. Грейд превращает компетентность во внешний ярлык, который пересчитывают на каждом performance review. По данным анонимного опроса Blind, где ответили 10 402 человека из FAANG, Microsoft, Uber, Lyft и других компаний, 58% IT-специалистов чувствуют себя самозванцами.

Обрати внимание на совпадение: цифра Blind сходится с российскими данными Proglib из начала статьи, хотя выборки не пересекаются вообще. Разные страны и разные методики дают одну и ту же долю.

Код-ревью: экзамен, который никогда не заканчивается

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

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

За время практики я насмотрелся на эту закономерность достаточно, чтобы говорить о ней уверенно: тревога вокруг ревью почти никогда не связана с реальным уровнем кода. Она связана с тем, как человеку в детстве показывали его ошибки. Тимлид, который ревьюит спокойно и строго по делу, всё равно попадает в старую рану, если дома промах разбирали с интонацией «ну как так можно».

Грейды и стек: компетентность, которую всё время пересчитывают

В медицине или в праве квалификация накапливается. В IT её переоценивают каждые полгода на ревью и каждые пару лет — самой индустрией. По оценке IBM и World Economic Forum, средний срок годности технического навыка сейчас около 2 лет. Фреймворк, на котором ты выстроил карьеру, успевает получить статус deprecated быстрее, чем ты успеваешь почувствовать себя в нём уверенно.

Отсюда эффект, который я вижу у сеньоров чаще, чем у джунов. Джун учит JavaScript три месяца, решает задачи, код работает, всё нормально. Сеньор пишет на нём десять лет, знает про event loop, утечки памяти и оптимизации V8 — и именно поэтому яснее видит границы своего знания. Чем ты опытнее, тем больше у тебя материала, чтобы себя обесценить.

Сам механизм обесценивания — почему мозг записывает успех в случайность, а провал в идентичность, откуда это приходит и на каком уровне памяти хранится — я подробно разбирал в статье про синдром самозванца. Здесь достаточно понять, что делает с этим механизмом индустрия. Она его кормит: ежедневно, через ревью, грейды и стендап, где ты слышишь, сколько успел сделать кто-то другой.

Кризис 35+: почему устаревание стека бьёт по идентичности?

Пик выгорания в IT приходится не на 25 лет со стартапом и 80-часовой неделей, а на 38-42 года (HSE University, Burnout in Tech Professionals Study, 2023). К этому возрасту ты уже всё умеешь и почти всего достиг, и именно тогда вопрос «а дальше что?» становится невыносимым. Устаревание стека здесь работает спусковым крючком, а причина лежит глубже — в том, из чего собрана твоя идентичность.

Механизм такой. Ты начал программировать в 20, потому что получалось и за это платили. К 37 «разработчик» перестало быть тем, что ты делаешь, и стало тем, кто ты есть. Джеймс Марсиа называл это identity foreclosure — идентичность, принятая без перебора альтернатив. Она не создаёт проблем ровно до того момента, пока держится.

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

Вот почему кризис 35+ невозможно просто переждать. Мозг обрабатывает угрозу смысловой опоры теми же контурами, что и угрозу жизни. Он не спорит с тобой о карьерных перспективах, он включает сирену — и делает это ровно в тот момент, когда ты читаешь release notes очередного фреймворка.

Почему смена стека даёт облегчение, но не решает проблему

Первый импульс при кризисе всегда одинаковый: что-то поменять. Выучить Rust, уйти в ML, попробовать менеджмент, свалить на фриланс. Я видел этот заход десятки раз, и результат почти всегда один: 3-6 месяцев на новизне, потом та же тревога в новых декорациях.

Один клиент, backend с пятнадцатью годами на Java, предложил мне на первой встрече: «Может, мне в ML перейти, там сейчас бум?» Я спросил, перестанет ли он бояться устареть после перехода. Он помолчал и ответил честно: «Нет. Через пять лет там тоже всё поменяется».

Пока внутри работает убеждение «моя ценность = мои технические навыки», любой технологический сдвиг будет читаться как личная угроза. Rust, Go, очередной AI-инструмент — вообще не имеет значения. Значение имеет только то, что программа продолжает считать тебя равным твоему стеку.

Отдельная ветка — когда код физически перестал приносить удовольствие: садишься, открываешь IDE, и вместо интереса пустота. Там работает уже дофаминовая система и рецепторная даунрегуляция, а не идентичность; подробный разбор — в статье о том, почему код перестал радовать.

Как выжить в IT без выгорания?

Окей, с диагнозом ясно. Рабочая память ограничена, context switching разрушителен, Slack работает как дофаминовая ловушка, Jira как трекер тревоги, а on-call как генератор хронического стресса. Поверх всего этого — ревью, которое читается как оценка тебя, и стек, который стареет быстрее, чем ты успеваешь в нём обжиться. Что со всем этим делать?

Сначала о том, что не работает. «Больше отдыхай», «займись спортом», «найди хобби не за компьютером». Это советы из мира, где мозг считают бензобаком, который достаточно просто заправить. Но мозг не бензобак, и нервная система, которая год работала в режиме on-call, от похода в зал не перезагружается.

Отдых необходим, но его одного мало. Проблема не в количестве энергии, а в том, как нервная система обрабатывает нагрузку. Если она научилась воспринимать любую задачу как угрозу, отпуск не поможет: ты вернёшься, откроешь Slack, и тревога окажется на месте. О том, чем отличается истощение от выгорания, я рассказывал в статье про дофаминовую ловушку.

Снизить когнитивный шум

Первое и самое конкретное: убери из поля зрения всё, что не требует немедленной реакции. Уведомления Slack оставь только по DM и упоминаниям, почту проверяй два раза в день, а в Jira заходи по расписанию, а не по каждому пушу. Это не про продуктивность, это нейрогигиена.

Каждое убранное уведомление - это несостоявшийся context switch. Это 23 минуты, которые остались у префронтальной коры на реальную работу. Помножь на 10-15 убранных пушей в день, и получишь 3-4 часа чистого фокуса, которые ты раньше даже не замечал, как терял.

Защитить рабочую память

Code review лучше делать утром, а код писать после обеда, или наоборот, но не вперемешку. Переключение между review-режимом и coding-режимом одно из самых дорогих для мозга, потому что это два принципиально разных процесса: аналитический в review и генеративный в коде.

Батчинг звучит как скучное слово, но именно он спасает рабочую память. Группируй однотипные задачи: все PR в один блок, все митинги в один временной слот, весь код в защищённый от прерываний интервал. Делать так стоит не потому что «продуктивнее», а потому что каждое переключение типа задачи стоит тебе когнитивных ресурсов, которые чашкой кофе не восстановишь.

Вынуть код-ревью из зоны оценки

Есть конкретное упражнение, и у большинства оно даёт эффект с первой недели. Перед тем как открыть ревью, назови про себя, что именно сейчас оценивается: дифф, а не ты и не твой грейд. Звучит наивно, согласен. Но задача упражнения не в том, чтобы убедить тебя логикой, а в том, чтобы вставить паузу между триггером и автоматической реакцией. В этой паузе и появляется выбор.

Само по себе упражнение паттерн не сотрёт. Оно даёт доступ к моменту, в котором паттерн запускается, а дальше уже можно работать с тем, что там лежит. Обычно под ним обнаруживается что-то куда более раннее, чем текущая команда и текущий тимлид.

Разделить себя и стек

Проверка, которую можно сделать прямо сейчас. Скажи вслух: «Я — не моя работа». Если внутри ничего не шевельнулось, у тебя с этим порядок. Если сжалось и следом всплыло «а кто я тогда?» — вот она, программа, которая превращает каждый технологический сдвиг в вопрос выживания.

Дальше нужно найти момент, когда эта связка записалась. У одного клиента — 12 лет и фраза отца «мужчина — это то, чего он добился». У другого — 9 лет и мама, которая хвалила исключительно за оценки. Формулировки разные, смысл одинаковый: ты ценен, пока полезен. К IT это отношения не имеет, IT просто дало старой программе идеальный полигон, где полезность измеряется каждый спринт.

Когда связка ослабевает, происходит любопытная вещь: люди почти никогда не уходят из профессии. Тот самый backend с Java остался в IT, но впервые за 15 лет начал бегать, вернул в жизнь друзей и записался на курсы столярки. Не потому что «нужно хобби», а потому что идентичность перестала помещаться в одну строку резюме.

Перезаписать паттерн реагирования

Вот здесь начинается то, что не вписывается в статьи про продуктивность.

Тот самый Андрей, backend-разработчик с on-call, не перестал тревожиться после того, как поменял настройки уведомлений. Его нервная система уже записала паттерн: любой сигнал равно угроза. Звук Slack стал триггером, открытие IDE триггером, и даже тишина триггером, потому что тишина перед on-call алертом обычно была недолгой.

Это уровень подсознания, имплицитная память, и логикой она не стирается. Ты не можешь объяснить своей HPA-оси, что ты больше не на on-call. Она не слушает аргументы, она слушает опыт.

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

А Марина, у которой неделя сливалась в одно серое пятно, через работу с подсознанием обнаружила, что её неспособность сказать «нет» новым задачам связана вовсе не с рабочей этикой. Под этим лежала программа из детства: «если я не буду полезной, меня бросят». Каждый PR на review, каждый незапланированный митинг, каждая чужая задача, которую она брала на себя, были не ответственностью, а страхом отвержения, замаскированным под лидерство.

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

Дело в IT-выгорании вовсе не в объёме работы. Мозг работает на пределе когнитивной нагрузки, нервная система при этом сидит в хроническом стрессе, а подсознание добавляет слой тревоги поверх всего остального. Убери любой из этих трёх компонентов, и система станет устойчивее. Убери подсознательный слой, и два других перестанут быть смертельными.

Частые вопросы