Жаворонки vs совы: когда пишется лучший код?
Одни разработчики клянутся, что лучшее начало дня — 6 утра с кофе и тишиной. Другие не открывают IDE до 10 вечера. Менеджеры спорят: вводить «core hours» или позволить людям работать когда угодно.
Мы проанализировали обширные данные активности разработчиков из более чем 100 B2B-компаний, чтобы узнать, когда разработчики на самом деле пишут код — и имеет ли значение время суток.
Методология
PanDev Metrics фиксирует IDE heartbeats с временными метками, давая точную картину того, когда происходит кодинг. Мы проанализировали:
- Обширные данные активности из продакшн-сред
- Активных B2B-разработчиков из более чем 100 B2B-компаний
- Тысячи часов IDE-активности, разбитые по времени суток и дню недели
- Тип активности: только чистые сессии кодинга (без встреч, без браузинга)
Мы разделили разработчиков на утренних (пик активности до полудня), дневных (пик с полудня до 17:00) и вечерних (пик после 17:00) на основе того, когда была наибольшая концентрация их кодинг-сессий.
Вывод №1: Вторник — самый продуктивный день
При агрегировании кодинг-активности по всем разработчикам вырисовывается чёткий недельный паттерн:
Вторник стабильно показывает самый высокий объём кодинга, за ним вплотную идут среда и четверг. Понедельник начинается медленнее — вероятно, из-за стендапов, sprint planning и разбора почты. Пятница заметно проседает. Суббота показывает некоторую активность от отдельных энтузиастов. Воскресенье — самый низкий день с большим отрывом.
Это совпадает с тем, что многие engineering-менеджеры чувствуют интуитивно: основная глубокая работа происходит в середине недели. Теперь за этим стоят данные.
Почему вторник?
Понедельник поглощает организационные издержки начала новой недели. К вторнику разработчики уже загрузили контекст, выявили блокеры и получили ясную картину задач. «Понедельничное переключение контекста» реально и измеримо.
Спад пятницы — это не просто лень. Это рациональный паттерн: разработчики избегают начинать сложные задачи, которые не успеют закончить до выходных. Code review, документация и мелкие фиксы обычно заполняют пятницу.
Вывод №2: Окно 10:00–12:00 — пик кодинга
В нашем датасете самая высокая концентрация кодинг-активности приходится на позднее утро: с 10:00 до полудня. Есть вторичный пик в раннем послеобеденном времени: с 14:00 до 16:00, с заметным провалом на обеденное время.
Небольшой, но значимый кластер активности появляется вечером: с 20:00 до 23:00 — это разработчики, которые либо предпочитают поздние часы, либо возвращаются к работе после личных дел.
Преимущество утра
Утренние сессии кодинга, как правило, длиннее и более сфокусированные. Разработчики, начинающие кодить до 10:00, показывают более длительные непрерывные отрезки по сравнению с теми, кто начинает после обеда. Это не значит, что утренние разработчики пишут лучший код — но они пишут код более длинными и глубокими сессиями.
Это имеет прямые последствия для планирования встреч. Если ваше самое продуктивное окно кодинга — с 10:00 до 12:00, а вы заполняете его стендапами, 1-on-1 и «быстрыми синками» — вы режете пиковую производительность.
Вывод №3: Вечерние кодеры существуют — но они в меньшинстве
Примерно 15-20% разработчиков в нашем датасете показывают значительную кодинг-активность после 18:00. Эти вечерние кодеры делятся на две категории:
- Совы по природе — их активность начинается поздно и пикует поздно
- Работающие в две смены — они кодят днём, берут перерыв и возвращаются вечером
Паттерн двойной смены вызывает больше опасений с точки зрения выгорания. Устойчивая вечерняя работа поверх полного рабочего дня часто указывает либо на чрезмерную нагрузку, либо на дневную среду, слишком перегруженную встречами для глубокой работы.
Вывод №4: Работа на выходных — сигнал тревоги
Наши данные показывают, что кодинг-активность на выходных в целом низкая — воскресенье наименее активный день с большим отрывом. Но она не нулевая.
Когда мы смотрим на команды, где кодинг на выходных стабильно выше среднего, мы часто обнаруживаем:
- Приближающиеся дедлайны или перегруженные спринты
- Дежурные обязанности, которые вторгаются в личное время
- Разработчиков, которые чувствуют, что могут сосредоточиться только на выходных, потому что будни перегружены встречами
Эпизодический кодинг на выходных — не проблема. Систематический кодинг на выходных — симптом. Engineering-менеджерам стоит мониторить этот паттерн — не для наказания, а чтобы разобраться, что мешает достаточной глубокой работе в рабочее время.
Вывод №5: Окно «потока» у каждого своё
Хотя агрегированные данные показывают пик в 10:00, индивидуальные разработчики варьируются значительно. Некоторые из самых продуктивных разработчиков в нашем датасете (по общему количеству часов кодинга) имели пик активности в нетипичное время: раннее утро (6-8:00), поздний вечер (21-23:00) или концентрированный 4-часовой послеобеденный блок.
Ключевой вывод: навязывание единообразного расписания разнообразным рабочим паттернам имеет свою цену. Обязательные стендапы в 9:00 наказывают вечерних разработчиков. Политика «никаких встреч после 15:00» предполагает, что продуктивный период у всех во второй половине дня.
Лучший подход, который мы видели в высокоэффективных командах: защитите 3-4-часовое окно общего пересечения для коллаборации и позвольте людям структурировать остаток дня вокруг своего естественного ритма.
Что говорят исследования
Наши выводы согласуются с более широкими исследованиями хронотипов и когнитивной производительности:
- Исследования циркадных ритмов показывают, что ~60-70% людей имеют пик когнитивной активности в позднее утро, но индивидуальные различия значительны
- Эффект «остаточного внимания» (Leroy, 2009) объясняет, почему кодинг после встречи менее продуктивен — разум всё ещё обрабатывает информацию со встречи
- «Deep Work» Кэла Ньюпорта (2016) утверждает, что 3-4 часа по-настоящему сфокусированной работы в день — максимум для большинства интеллектуальных работников. Наши данные подтверждают, что это справедливо и для профессиональных B2B-инженерных сред
- Stack Overflow Developer Survey сообщает, что большинство разработчиков считают себя сторонниками утренней или поздне-утренней работы — что согласуется с наблюдаемым нами пиком в 10:00
Наши данные добавляют новое измерение: в профессиональных B2B-средах эти паттерны воспроизводятся в масштабе. Это не лабораторное исследование — это реальное поведение при продакшн-кодинге.
Практические рекомендации для engineering-менеджеров
1. Сопоставьте расписание встреч с пиками кодинга
Посмотрите, когда пикует кодинг-активность вашей команды (PanDev Metrics показывает это в дашборде активности). Затем посмотрите на расписание регулярных встреч. Если есть значительное пересечение — вы уничтожаете продуктивность.
Действие: переместите стендапы на раннее утро или поздний день. Заблокируйте окно 10:00–12:00 как «maker time».
2. Следите за соотношением вторник-пятница
Здоровая команда показывает умеренное снижение от вторника к пятнице. Если кодинг в пятницу падает ниже 50% от уровня вторника — разбирайтесь. Частые причины: перегрузка встречами, проблемы с объёмом спринта или выгорание.
3. Следите за ползучей работой на выходных
Отслеживайте кодинг-активность на выходных на уровне команды. Восходящий тренд на протяжении нескольких месяцев — ранний тревожный сигнал. Устраняйте корневую причину (объём, встречи, нереалистичные дедлайны), пока это не стало проблемой удержания.
4. Уважайте разнообразие хронотипов
Если ваши данные показывают, что некоторые члены команды стабильно наиболее продуктивны вечером — подстройтесь. Асинхронная коммуникация, записанные стендапы и гибкие core hours ничего вам не стоят и могут значительно повысить результативность.
5. Используйте данные, а не предположения
Самая частая ошибка, которую мы наблюдаем, — менеджеры, выстраивающие рабочие политики на основе собственных предпочтений. Менеджер-жаворонок, устанавливающий начало в 8:30, покажет худшие результаты, чем тот, кто смотрит на реальные данные активности и оптимизирует процессы вокруг них.
Итог
Разработчики наиболее продуктивны по вторникам, в позднее утро, во время непрерывных отрезков работы. Но индивидуальные различия огромны. Самые умные engineering-лидеры не навязывают единую политику «продуктивных часов» — они измеряют реальные паттерны и оптимизируют вокруг них.
Вопрос не в том, «когда разработчики должны работать?» Вопрос: «когда они работают лучше всего и как мы можем защитить это время?»
Узнайте, когда ваша команда действительно кодит. PanDev Metrics показывает паттерны активности в реальном времени по часам и дням — чтобы вы могли защитить самые продуктивные окна вашей команды.