Сколько времени разработчик реально пишет код

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

Что считается «написанием кода», а что уже другое
Что показывают опросы о структуре дня разработчика
Таблица: из чего состоит рабочий день программиста
Пример: доля IDE у одного реального аккаунта DevPace
Почему доля времени в IDE не равна доле написания кода
Как проверить это на собственных данных
Частые вопросы
Итог

Что считается «написанием кода», а что уже другое

Прежде чем спорить о цифрах, стоит договориться о термине. «Написание кода» в узком смысле — это создание нового текста программы: набор новой логики, новой функции, нового файла. В это определение не входит, хотя и происходит внутри той же среды разработки: чтение и понимание уже существующего кода перед изменением, отладка через пошаговое выполнение и логи, код-ревью чужих pull request’ов, написание тестов к уже готовой логике, рефакторинг без добавления новой функциональности. За пределами IDE в это же «не код» попадают встречи, планирование задач, переписка с командой и поиск решения проблемы в браузере.

Разница не педантичная. Если считать «написанием кода» всё время, проведённое в редакторе или IDE, к цифре автоматически прибавляются часы отладки и чтения — деятельности, которая явно ощущается как работа программиста, но не как создание нового кода в узком смысле. Отсюда и разрыв: чем шире определение, тем больше часов в него попадает, и любое сравнение цифр из разных источников без явной оговорки о том, что именно считалось, будет сравнением яблок с грушами.

Что показывают опросы о структуре дня разработчика

Ежегодные опросы вроде Stack Overflow Developer Survey годами задают разработчикам вопрос о структуре рабочего дня, и картина год за годом получается качественно одна и та же: написание нового кода — заметная, но далеко не единственная и не всегда доминирующая часть дня, наравне с ней стоят встречи, код-ревью, отладка, документирование и переписка с командой. Точные цифры от выпуска к выпуску и от методологии к методологии заметно расходятся, поэтому дальше в этой статье намеренно не приводятся конкретные проценты из таких опросов — важна не цифра конкретного года, а сам качественный факт: чем занят разработчик в течение дня — это далеко не только клавиатура и новый код в редакторе.

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

Ту же мысль с другой стороны подтверждает индустриальная работа над метриками продуктивности разработчика: статья Николь Форсгрен, Марго Стори и Крис Маддила с соавторами о фреймворке SPACE (ACM Queue, 2021) прямо указывает, что продуктивность разработчика — многомерное явление, и объём произведённого кода (Activity в терминах фреймворка) — лишь одно из пяти измерений, а не синоним всей работы целиком. Подробный разбор SPACE и второго крупного фреймворка, DORA, — в статье «Продуктивность разработчика: какие метрики имеют смысл»; там же — почему число коммитов и строк кода плохо работает как самостоятельная метрика. Если интересен именно взгляд на уровне команды и процесса поставки, а не отдельного пользователя, — в статье «DORA-метрики: что это и зачем они нужны команде».

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

Таблица: из чего состоит рабочий день программиста

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

Категория	Что в неё попадает	Связь с «написанием кода»
IDE	Редактор кода, среда разработки, встроенные терминалы IDE	Ближе всего к написанию кода, но включает и чтение, и отладку, и тесты
Терминал	Отдельные окна терминала, консольные утилиты, сборка, деплой из командной строки	Инфраструктурная работа вокруг кода, не само написание
Браузер	Документация, поиск решения по ошибке, чтение чужого кода на GitHub	Часто напрямую обслуживает написание кода, но формально это не редактор
Коммуникации	Мессенджеры, почта, видеозвонки	Синхронизация с командой, не написание кода
Трекер задач	Jira, Trello и подобные системы	Планирование и учёт задач, не написание кода
Офисные приложения	Документы, таблицы, презентации	Документирование и планирование, не написание кода
CRM	Специализированные инструменты работы с клиентами	Не связано с написанием кода напрямую
Другое	Редкие или ещё не размеченные приложения	Зависит от конкретного инструмента, не программируется в саму категорию

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

Разбивка времени за день по категориям приложений — IDE, браузер, коммуникации, терминал, трекер задач, офис, CRM и категория «Другое»

Разбивка дня по категориям — агрегированный вид того, чем был занят разработчик в течение дня, без единого числа “часов кодинга” вместо восьми категорий.

Пример: доля IDE у одного реального аккаунта DevPace

Цифры выше — про то, что измеримо в принципе. А вот пример того, как это выглядит на практике: у одного тестового аккаунта DevPace, накопившего около месяца данных, категория IDE в среднем занимала заметно меньше половины активного времени дня — остальное распределялось между терминалом, браузером, коммуникациями и другими категориями. В один конкретный день из этого месяца IDE набрала около 4100 секунд (примерно 1 час 8 минут) из примерно 28400 секунд (около 7 часов 53 минут) активного времени — то есть около 14%. В другой день той же учётной записи доля IDE доходила почти до 35% активного времени.

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

Разбивка времени за день по приложениям внутри каждой категории — детализация до конкретной программы

Более детальный слой той же картины — не просто «категория IDE», а конкретные приложения внутри неё и внутри остальных категорий за день.

Почему доля времени в IDE не равна доле написания кода

Даже если взять самую благоприятную для «написания кода» категорию — IDE — она всё равно не сводится к созданию нового текста программы. Внутри времени, проведённого в IDE, реально происходит несколько разных видов работы: чтение и навигация по существующему коду перед тем, как в нём что-то менять; пошаговая отладка с логами и точками останова, которая может занять часы на исправление нескольких строк; запуск и наблюдение за тестами; правки существующего кода без добавления новой логики. Время на написание кода в самом узком смысле — создание нового — это подмножество времени в IDE, а не всё оно целиком.

Отсюда следует, что даже честная, технически точная метрика вроде доли времени в категории IDE — это верхняя граница возможного времени на написание кода, а не его точное измерение. Более узкую метрику — например, разложить IDE-время на «писал новое» и «читал/отлаживал старое» — DevPace сознательно не строит: это потребовало бы анализа содержимого происходящего внутри редактора (что именно менялось, что открывалось), а инструмент фиксирует только техническую категорию и длительность, не заглядывая внутрь того, что реально происходит на экране. То, что агент делает и не делает с точки зрения содержимого, можно проверить не на слово: агент DevPace открыт исходным кодом, и место в коде, где определяется категория активного окна, доступно для чтения любому желающему.

Как проверить это на собственных данных

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

Сначала стоит посмотреть на разбивку одного обычного дня по категориям — сколько минут пришлось на IDE, терминал, браузер, коммуникации и остальное — и честно спросить себя, совпадает ли это с ощущением от дня. Затем имеет смысл посмотреть не один день, а несколько недель подряд: разброс, похожий на пример выше (14% в один день, 35% — в другой), — это нормальная часть картины, а не сигнал что-то чинить, если он не превращается в устойчивую тенденцию месяцами. Полезно также посмотреть на распределение времени разработчика в связке с ритмом git-коммитов по дням: день с низкой долей IDE и без единого коммита — не обязательно “плохой” день, а иногда день, целиком ушедший в обсуждение задачи, ревью чужого кода или встречи, которые тоже часть работы. О том, как в целом устроен рабочий день разработчика за пределами одной метрики IDE, подробнее — в статье «Рабочий день разработчика: из чего он реально состоит».

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

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

Значит ли низкая доля времени в IDE, что разработчик мало работает?

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

Сколько времени в день должно уходить на написание кода, чтобы это было нормально?

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

Можно ли доверять опросам вроде Stack Overflow Developer Survey в вопросе о времени на код?

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

Итог

Сколько времени программист пишет код, зависит от того, что именно считать написанием кода, и не сводится ни к одной цифре из опроса, ни к одной категории активности. Опросы разработчиков стабильно показывают, что новый код — заметная, но не единственная часть дня наравне со встречами, ревью и отладкой; данные реального тестового аккаунта DevPace показывают, что даже самая близкая к написанию кода категория — IDE — может занимать от 14 до 35% активного времени в разные дни одного и того же пользователя. Ни одна из этих цифр не универсальный норматив — практический смысл в том, чтобы увидеть собственное распределение времени разработчика и сравнивать его с собственной историей, а не с чужим опросом или чужим примером.