Прокрастинация разработчика:
тикет висит 3 дня

Утро понедельника, стендап позади. Ты сказал: «Буду делать JIRA-1247, там на пару часов», и все кивнули. Открыл IDE, посмотрел на задачу, прочитал описание один раз, потом ещё раз. Открыл связанный PR, поглядел на код и закрыл его.

Дальше открылся Slack: ты ответил на три сообщения, которые спокойно дотерпели бы до вечера. Потом Hacker News, статья про Rust, хотя сам ты пишешь на Python. Налил кофе, вернулся к IDE, ещё раз посмотрел на тикет. И закрыл IDE.

К среде тикет всё ещё в «In Progress». Зато ты успел кучу другого: ответил на все сообщения, помог джуну, написал документацию, которую никто не просил, и даже пофиксил баг, на который наткнулся случайно. Ты не бездельничал, работал по 10 часов в день. А JIRA-1247 так и стоит нетронутым.

Знакомо? Тогда ты не одинок и точно не ленивый. У тебя специфическая проблема, и она связана с тем, как устроен мозг разработчика.

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

Почему задача на 2 часа висит 3 дня?

При обычной прокрастинации ты лежишь на диване и смотришь YouTube вместо работы. У разработчика всё иначе: ты работаешь 10 часов, но не над тем, над чем нужно. Ты продуктивен и делаешь полезные вещи, просто не ту вещь.

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

Возьмём Кирилла, 25 лет, джуниор-фронтендер в стартапе. Он получил тикет «реализовать интеграцию с платёжной системой»: три строчки описания, без макетов, без спецификации API, без acceptance criteria. PM добавил: «Ну ты разберёшься, ты же умный».

Кирилл не разобрался, и дело не в том, что он тупой. Его мозг получил задачу без границ и просто не смог начать. Он не знал, с чего стартовать, что считается «готово» и какие edge cases учитывать. А спросить было нельзя, ведь «я же должен сам разобраться». В итоге три дня он фиксил CSS-баги и писал юнит-тесты для компонентов, которые и так работали.

Его мозг при этом вёл себя рационально: выбирал задачи с чёткими границами, понятным результатом и мгновенным фидбеком (зелёный тест = дофамин). А задача без границ лежала в бэклоге его тревоги и подбрасывала кортизол каждый раз, когда он смотрел на JIRA-доску.

Как сложный код перегружает рабочую память?

Рабочая память, это оперативка мозга, а не жёсткий диск и не долговременное хранилище. Это то, что ты удерживаешь в голове прямо сейчас, и у неё жёсткий лимит: 7±2 элемента, а для некоторых задач и того меньше.

Теперь представь типичную задачу на рефакторинг и то, что приходится держать одновременно:

1. Текущую архитектуру компонента
2. Целевую архитектуру после рефакторинга
3. Зависимости — кто вызывает этот код и что сломается
4. Типы данных и контракты API
5. Edge cases, которые ты уже знаешь
6. Edge cases, которые ты подозреваешь, но не уверен
7. Тесты, которые нужно обновить
8. Стилистические требования команды
9. Дедлайн и приоритет задачи

Девять элементов, лимит уже превышен. А ты ведь ещё даже не начал писать код.

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

Во втором варианте мозг вообще отказывается загружать контекст, и это и есть прокрастинация. Ты смотришь на задачу, а мозг говорит: «Нет, мне столько не поместится», и переключает тебя на то, где память не перегружена. Slack, Hacker News, рефакторинг простого компонента, где в голове три вещи, а не девять.

Вдобавок после каждого переключения контекста мозгу нужно 23 минуты, чтобы вернуться к прежнему уровню концентрации. Открыл Slack на 30 секунд, потерял 23 минуты, и это не слабоволие, а нейрофизиология. Исследование Марка, Гудит и Клока из UCI показало, что после прерывания программисту требуется в среднем 23 минуты 15 секунд, чтобы снова погрузиться в задачу.

Отдельная история, это unclear specs. Когда тикет написан в три строчки без acceptance criteria, мозг получает задачу с открытыми границами. Он не может построить план, потому что не знает, что считается результатом. Без плана нет последовательности шагов, а без шагов рабочая память не понимает, что загружать первым.

Для амигдалы неопределённость равна угрозе, и это не преувеличение. Нейробиологически мозг обрабатывает неоднозначную информацию как потенциально опасную. Чёткая задача «исправить цвет кнопки с #333 на #1C1917» даёт ноль стресса. А unclear spec вроде «улучшить UX формы оплаты» включает амигдалу, выбрасывает кортизол, и вот ты уже читаешь Hacker News.

Почему разработчики прокрастинируют иначе?

У разработчиков есть три триггера, которых нет у большинства других профессий. Это не считая выгорания в IT, которое тоже усиливает прокрастинацию, но это отдельная тема. Если ты работаешь на себя, добавляется ещё один слой: выгорание фрилансера, где нет внешнего ритма и каждый день нужно заново себя поднимать. А у части разработчиков за хронической прокрастинацией стоит не лень и не страх code review, а СДВГ у взрослых и прокрастинация: дефицит дофамина, который делает «обычные» задачи нейрохимически невозможными.

Code review anxiety

Ты написал код, он работает, тесты проходят. Открываешь PR, и начинается: сердце чуть быстрее, ты проверяешь уведомления каждые пять минут. А когда появляется первый комментарий «Why not use reduce here?», внутри всё сжимается.

Code review anxiety живёт там, где мозг не различает «критику кода» и «критику меня». Для подсознания твой PR равен тебе самому, и каждый комментарий читается как оценка тебя: как профессионала, как личности, как человека, который вообще имеет право сидеть в этой команде.

Откуда это? Из детства, конечно: из школы, где красная ручка учителя означала «ты неправильный», из семьи, где результат равнялся любви, из первого code review на стажировке, когда сеньор написал 47 комментариев и ни одного «good job».

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

Страх сломать прод

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

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

Объективно риск минимальный: есть staging, есть откат, есть мониторинг. Но амигдала работает не с объективными данными, а с ощущениями. А ощущение у Игоря такое: если я трону этот код, случится катастрофа.

Когда мы разобрали ситуацию, корень оказался не в коде. Игорь вырос в семье, где старший брат «всегда всё ломал», а сам он был «ответственным». Мама говорила: «Хорошо, что хоть ты у меня нормальный». Быть тем, кто не ломает, стало его идентичностью. И теперь, 36 лет спустя, перед каждым рискованным изменением его мозг слышит: «Ты же ответственный, не ломай».

Подмена задач

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

Мозг выбирает задачи по простому принципу: минимум неопределённости, быстрый фидбек и низкий риск оценки. Зелёный тест даёт мгновенный дофамин, закрытый баг тоже, а помощь джуну добавляет ещё и социальное одобрение.

А задача, от которой зависит спринт? Высокая неопределённость, отложенный фидбек, риск получить 30 комментариев на code review и ноль дофамина прямо сейчас. У неё попросту нет шансов против зелёных тестов. Подробнее о близком механизме читай в материале про паралич решений.

Как начать делать без борьбы с собой?

Сначала о том, что не работает. Pomodoro, блокировка сайтов, «съешь лягушку первой», для разработчика это как пластырь на segfault. Кровотечение он остановит на пять минут, но причина-то в коде, а не в пластыре.

А вот что работает, если учитывать, как устроен мозг программиста.

Разбить неопределённость на вопросы

Вместо «сделать фичу X» составь список конкретных вопросов, именно вопросов, а не задач. «Какой формат ответа API?», «Какие состояния ошибок обрабатывать?», «Кто отвечает за edge case, когда пользователь offline?»

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

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

Начать с самого маленького файла

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

Не «рефакторить модуль платежей», а «открыть файл payment_processor.py и прочитать первые 50 строк». Всё, это весь план: прочитать 50 строк. Рабочая память загружается мягко, контекст нарастает, и через 15 минут ты уже видишь, что нужно менять. Не потому что заставил себя, а потому что мозг уже внутри задачи.

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

Отделить себя от кода

Code review anxiety лечится на двух уровнях. На поверхности достаточно напоминать себе, что комментарии про код, а не про тебя. Ревьюер пишет «rename this variable», и это просто «переименуй переменную», точка, а не «ты плохой программист».

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

Работа с корневой программой

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

Такая программа записана не в префронтальной коре, а глубже, в имплицитной памяти и лимбической системе, там, где хранятся не факты, а ощущения. Менять её нужно на том же уровне, и именно для этого существует Метод Прямого Доступа. Не аргументами, не списком задач и не блокировкой Hacker News.

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

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