Сколько времени программисты тратят на код: реальные цифры и как вернуть часы

сен, 6 2025

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

Если хочется цифр, ориентир выглядит так: у отдельных разработчиков доля «чистого кода» колеблется в пределах 20-40% в стабильных командах и может вырастать до 50-70% в ранних стадиях продукта, когда процессов и согласований меньше. В крупной компании с насыщанным процессом эта доля спокойно опускается до 15-30% - из‑за ревью, согласований, безопасности и релизных регламентов.

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

Хотите понять свою реальную картину? Начните с простого замера за неделю: 1) выгрузите календарь и отметьте обязательные встречи; 2) включите трекинг активности IDE (WakaTime, JetBrains Productivity, Code Time для VS Code); 3) соберите метрики по PR: средний размер, время до первого ревью, общее «время жизни» PR, долю правок после ревью; 4) зафиксируйте среднее ожидание сборок/тестов и сколько раз в день вы переключаете задачи. Эти данные быстро покажут, где утекают часы.

Типичные «пожиратели» времени в веб‑разработке: долгие созвоны без решений, крупные PR, медленные тесты и сборки, «узкие горлышки» в ревью, расплывчатые постановки задач и частые прерывания. Хорошая новость - почти всё это чинится процессом. Митинги переводим в асинхрон: короткие RFC в документах и обсуждения в ишью. Ревью - по SLA (например, первый ответ за 2 часа), маленькие PR с одним смыслом, автоназначение ревьюеров через CODEOWNERS. CI ускоряем кэшированием зависимостей, параллельными джобами и инкрементальными сборками. Тесты - параллельный прогон и изоляция «флакки».

Есть и быстрые личные приёмы. Забронируйте 2 блока глубокого фокуса по 90 минут в день и защитите их от встреч. Уберите лишние уведомления, оставьте только упоминания в PR и критические алерты. Держите в работе один таск. Перед ревью прогоняйте чек‑лист: тесты зелёные, линтер/форматер прошли, добавлены метрики и миграции, есть описание для ревьюера. Такие мелочи уменьшают количество «пинг‑понга» и возвращают время на код.

Отдельная фишка - делать код удобным для чтения. Большая часть времени уходит именно на чтение, не на набор текста. Понятные имена, короткие функции, единый стиль через Prettier/ESLint и типы в TypeScript ускоряют ревью и снижают шанс багов, а значит, экономят часы на переделки.

Если хочется быстро прибавить 5-10% к доле кодинга уже в этом месяце, начните с трёх шагов: календарный «санитарный день» (режем/переносим встречи), маленькие PR (до 300-400 строк, один смысл), ускорение CI до «зеленого» за несколько минут за счёт кэша и параллелизма. Дальше - регулярный недельный обзор метрик и точечные правки процесса.

• Почему «писать код» - это не весь рабочий день
• Где теряются часы в веб‑разработке
• Реалистичные диапазоны по ролям и этапам
• Как измерить своё время без микроменеджмента
• Командные практики, которые возвращают время
• Личные привычки, которые реально работают

Где теряются часы в веб‑разработке

Самые большие потери - не в редакторе, а между задачами: ожидание ревью, медленный CI, неясные требования, прерывания, «флаки» тесты. Вот где испаряется время на код и как это выглядит на практике.

• Встречи и согласования. Планирование спринта, уточнения требований, демо. Польза есть, но часто решение можно оформить асинхронно в ишью или RFC. Держите созвоны с чёткой повесткой и таймбоксом.

• Неясные требования = переделки. Когда нет чётких критериев приёмки, появляются «ещё маленькие правки». Лечится Definition of Ready, user story с конкретными кейсами и тестовыми сценариями.

• Крупные PR и задержки ревью. Большие изменения рецензируют дольше и с большей долей правок. Инженерные практики Google рекомендуют маленькие изменения (порядка 200-300 строк) - такие ревью идут быстрее и надёжнее.

• Медленный CI/CD. Долгая установка зависимостей, линт, сборка, интеграционные тесты. Ускоряют кэширование npm/Pod/Gradle, параллельные джобы, инкрементальные сборки, шардирование тестов и таргетированный прогон по затронутым модулям.

• Флаки тесты. Нестабильные тесты ломают поток: прогон зелёный/красный без изменений. В Google оценивали долю flaky на уровне ~1,5% от всех тестов - достаточно, чтобы регулярно стопорить релизы.

• Прерывания и переключения контекста. Исследования профессора Глории Марк показывают: на возвращение к задаче после прерывания уходит в среднем ~23 минуты. Слабые границы календаря и шум уведомлений быстро съедают день.

• Локальные окружения и «дрейф» конфигураций. «У меня работает» превращается в час дебага. Контейнеризированные dev-окружения, devcontainers и единые скрипты запуска уменьшают эти потери.

• Поиск и контекст. Чтение чужого кода, логов, спеков API, Jira/YouTrack обсуждений - это часть работы, но без навигации и актуальной документации на это уходит в разы больше времени.

• Зависимости и сборка фронта. Установка node‑модулей, перестройка бандла, прогрев кешей - классический «ожидательный» блок. Lockfile, pnpm/npm ci, кеш по ключам и prebuilt артефакты заметно ускоряют цикл.

• Ручные проверки. Когда нет автотестов на критические сценарии, команда тратит часы на кликанье, кросс‑браузерные сравнения и регрессы.

Эти узкие места напрямую бьют по сквозным метрикам доставки. Модель DORA выделяет четыре ключевых показателя: частота деплоев, время от коммита до продакшена (lead time), процент неудачных изменений и время восстановления. У «элитных» команд lead time обычно меньше суток и деплои - несколько раз в день. Все задержки выше - это очередь и ожидание.

Почему мелкие партии выигрывают? Закон Литтла прост: среднее время цикла = WIP / пропускная способность. Чем больше незавершёнки и чем крупнее партии (огромные PR, длинные очереди на CI), тем дольше ждёте, даже если скорость печати та же.

1. Замерьте реальные очереди: среднее ожидание ревью, «время до зелёного» в CI, долю перезапусков из‑за flaky.

2. Проверьте размер партий: средний размер PR и его «время жизни» до мерджа.

3. Отследите прерывания: сколько уведомлений и митингов попадает в фокусные блоки.

4. Найдите один «бутылочный горлышко» и уберите его (например, кеш для npm, шардирование тестов или правило на маленькие PR).

Как только вы начнёте видеть очереди и партии на цифрах, ровно там и найдете утекшие часы. Дальше - точечные правки процесса и инструменты под них.

Реалистичные диапазоны по ролям и этапам

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

По ролям в веб‑разработке

• Junior фронтенд/бэкенд: 30-50%. Много времени съедают обучение, чтение проекта и фиксы после ревью. Если команда держит маленькие задачи и у ментора есть слот на быстрые ответы - ближе к верхней границе.

• Middle разработчик: 35-55%. Меньше «блокеров», больше автономности. Сильно зависит от качества постановок и скорости CI.

• Senior: 20-40%. Появляются архитектурные обсуждения, ревью чужого кода, менторинг. В проектах без продуктовой бюрократии доля может подниматься к 40%.

• Team Lead/Tech Lead: 10-25%. Планирование, синки, технические решения, разблокировка команды. Кодят «сериями» - в окна без встреч.

• Full‑stack: 25-45%. Переключения между фронтом и бэком добавляют издержки. Помогают хорошо настроенные шаблоны, общие типы и контракт‑тесты.

• QA Automation (в веб‑командах): 30-60%. Пик - при построении фреймворков тестов и нагрузочных стендов; ниже - в фиче‑фазах с упором на ручную приёмку.

• DevOps/Platform для веб‑продукта: 10-30%. Код - это пайплайны, инфраструктура как код, автоматизация рутин; остальное - инциденты и поддержка окружений.

Фактор дежурств (on‑call) резко двигает процент: неделя с инцидентами легко «съедает» 20-40% времени, которое пошло бы на фичи.

По этапам работы над фичей

• Discovery/уточнение требований: 0-15%. Код почти не пишется. Идеальная зона для прототипов и «спайков» на один‑два часа без долгих коммитов в основную ветку.

• Проектирование/архитектура: 10-25%. Часть времени - на ADR/RFC, схемы, контракты API. Небольшие «скелеты» модулей ускоряют последующую реализацию.

• Реализация: 40-70%. Основная фаза набора кода. Держите PR маленькими (до ~400 строк) - это ускоряет ревью и снижает шанс отката.

• Отладка и стабилизация: 25-45%. Много времени уходит на воспроизведение багов, логи, метрики, фиксы после ревью и прогон автотестов.

• Релиз/деплой: 10-25%. Скрипты, миграции, флаги, чек‑листы, сопровождение релиза.

• Поддержка/техдолг: 15-35%. Миграции зависимостей, рефакторинг, устранение «флакки» тестов, мелкие багфиксы.

Что двигает диапазоны вверх/вниз

• Размер компании и зрелость процесса. Чем больше согласований и регуляций, тем ниже доля «клавиатурного» времени.

• Скорость CI/CD. Медленные сборки и тесты выбивают из потока. Ускорение пайплайна до минут возвращает десятки часов в месяц.

• Размер PR и SLA на ревью. Маленькие PR и быстрый первый отклик (в течение пары часов) заметно повышают пропускную способность.

• Переключения контекста. Исследование Глории Марк (UCI) показало: после прерывания на восстановление фокуса уходит в среднем ~23 минуты. Это прямая потеря времени.

• Дежурства и инциденты. Неделя on‑call - минус значимая часть планового объёма.

Опорные факты, на которые можно смело ссылаться

• Отчёты DORA/Accelerate: у «элитных» команд lead time от коммита до продакшна - менее суток, деплои происходят ежедневно и чаще. Это возможно только при коротких ветках, маленьких изменениях и стабильном CI.

• SmartBear Code Review Study: оптимальный объём ревью - до ~400 LOC за раз, продуктивная скорость просмотра - 200-400 LOC/час. Больше - падает качество и растёт время рассмотрения.

• Google Engineering Practices рекомендуют держать изменения маленькими. Небольшие CL проще читать, быстрее принимаются и реже ломают сборку.

Как применять цифры в планировании

1. Зафиксируйте текущую долю «кода» по роли и этапу. Для обычной продуктовой веб‑команды берите базу: Middle 35-55%, Senior 20-40%.

2. Уточните поправки: on‑call неделя, зрелость процесса, длина пайплайна, размер PR.

3. Планируйте ёмкость спринта из «фокус‑часов», а не из календарных. Резерв 20% оставляйте на незапланированное.

4. Сверяйте метрики раз в неделю: размер PR, время до первого ревью, длительность сборок, процент переделок после ревью.

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

Как измерить своё время без микроменеджмента

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

Основа - только автоматический сбор данных из тех инструментов, которыми вы и так пользуетесь: IDE, Git, CI/CD, таск‑трекер и календарь. Эти источники уже хранят таймстемпы: когда создан PR, когда пришёл первый отзыв, сколько длилась сборка, сколько встреч было за день.

1. Включите трекинг в IDE. Плагин WakaTime поддерживает VS Code, JetBrains IDE, Vim, Neovim, Sublime и другие. Он логирует активность в редакторе по проектам и языкам и показывает поминутную ленту без скриншотов.

2. Соберите метрики по PR. В GitHub/GitLab есть API с полями created_at, merged_at, review событиями. Этого хватает, чтобы посчитать время до первого ревью и «время жизни» PR. GitLens в VS Code упростит просмотр истории прямо в редакторе.

3. Зафиксируйте CI‑времена. Любая CI (GitHub Actions, GitLab CI, Jenkins, CircleCI) сохраняет длительность джоб. Просто выгрузите тайминги или добавьте бейджи/метрики в дашборд.

4. Возьмите цикл времени из таск‑трекера. В Jira есть Control Chart: он считает Cycle Time от «In Progress» до «Done». Этого достаточно, чтобы увидеть, где карточки тормозят.

5. Сверьте календарь. Экспортируйте встречи за неделю, посчитайте часы и их долю от рабочего времени. Это самый честный способ понять «сколько съели созвоны».

Чтобы не утонуть в цифрах, держите набор метрик коротким и полезным для действий. Ниже - минимальный набор для веб‑разработки и проверенные ориентиры из индустрии.

Важно проговорить приватность. Не собирайте скриншоты и тексты, только метаданные: время, длительности, статусы. Доступ - у каждого к своим данным, у команды - только к агрегатам. Это снижает токсичность и повышает доверие к метрикам.

Как построить недельный ритм без микроменеджмента:

• В понедельник поставьте цель: 2-3 фичи, лимит WIP = 1, два фокус‑окна по 90 минут в день.

• В среду проверьте дашборд: нет ли PR старше 2 дней, не замедлилась ли сборка, не выросли ли встречи.

• В пятницу короткий разбор: что дало больше всего задержек (встречи, ревью, CI), одно действие на следующую неделю (например, дробим крупные PR).

Почему этого достаточно? Потому что эти метрики управляемы. Крупные PR - дробим. Медленный CI - кэшируем зависимости и пускаем джобы параллельно. Долгое ожидание ревью - вводим SLA на первый отклик и автоназначение через CODEOWNERS (файл поддерживается в GitHub и GitLab).

Если хотите без кода собрать дашборд, есть готовые решения уровня команды: LinearB и Pluralsight Flow (ранее GitPrime) строят метрики по PR/ревью, GitLab Ultimate показывает DORA‑метрики из коробки. Для персонального уровня обычно хватает пары: WakaTime + дашборд CI.

Два быстрых эксперимента на неделю: 1) ограничьте размер PR до 300-400 строк - увидите рост скорости ревью; 2) разнесите тесты в CI на параллельные джобы - время «красный→зелёный» упадёт в разы. Оба шага обычно дают прибавку к доле реального кодинга уже в первый спринт.

Командные практики, которые возвращают время

Когда мы говорим про скорость в веб‑разработке, команда выигрывает не за счёт героизма, а за счёт системы. Хорошая новость: многие вещи доказаны исследованиями и работают предсказуемо.

Ориентиры удобнее держать в цифрах. DORA (DevOps Research and Assessment) уже много лет измеряет эффективность ИТ‑команд. Их «элитный» уровень задаёт понятные цели для процесса.

Что помогает приблизиться к этим цифрам и вернуть команде время на код - ниже по пунктам.

1) Малые батчи и короткоживущие ветки

• Делаем небольшие PR: один смысл, до 300-400 изменённых строк. Это ускоряет ревью и снижает риск. В руководствах Google по code review прямо советуют держать изменения маленькими - так ревью идут быстрее и качественнее.
• Trunk-Based Development: фича‑ветка живёт менее 1-2 дней, регулярные мержи в trunk. Связь с высокой производительностью подтверждена в отчётах DORA.
• Фича‑флаги: выкатываем код выключенным, включаем по частям, делаем канареечные релизы. Это уменьшает размер «партии» на проде и упрощает откаты.

2) Ревью без затяжек

• Ставим SLA на первый отклик по PR: например, 2 часа рабочего времени. Публичные команды, которые меряют Time to First Review, стабильно сокращают «время жизни» PR.
• CODEOWNERS и автоназначение ревьюеров - чтобы PR не висел «на всех и ни на ком».
• Один ответственный ревьюер + опциональные - понятная модель владения.
• Чек‑лист для автора: зелёные тесты, линтер/форматер, миграции/метрики, описание кейсов. Это снижает «пинг‑понг» и лишние итерации.
• Draft PR для ранней проверки направления - полезно на сложных изменениях.

3) Быстрый CI/CD

• Кэш зависимостей (npm, pnpm, Maven/Gradle), параллельный прогон тестов, разделение пайплайна на быстрый «PR‑путь» и полный «main‑путь» ускоряют обратную связь. Чем быстрее зелёная галочка, тем меньше переключений контекста.
• Инкрементальные сборки и turborepo‑подходы в монорепо уменьшают время сборки больших проектов.
• Стратегия «test pyramid»: больше быстрых unit и интеграционных тестов, немного e2e на критические флоу. Это классика, но она реально сокращает минуты и часы в CI.

4) Асинхронные решения вместо митингов

• Короткие RFC‑доки (1-2 страницы) и ADR (Architectural Decision Record) вместо часовых созвонов. Решения фиксируются, спорим в комментариях, встреча - только если нужно.
• Ежедневка в тексте: один пост в чате/таск‑трекере утром, общий статус - вечером пятницы. Время созвонов освобождаем под фокус‑работу.
• «Неприкосновенные» окна фокуса команды (например, 10:00-12:00) - без встреч и лишних пингов.

5) Предсказуемые окружения

• Эфемерные превью‑окружения на каждый PR (Vercel/Netlify/Heroku Review Apps, Kubernetes namespaces). Менеджер, QA и дизайн смотрят результат без локальной сборки.
• Dev Containers/Codespaces или docker‑образ проекта - одинаковое окружение у всех. GitHub публично пишет, что Codespaces часто сокращает настройку среды «с дней до минут» - это бьёт прямо по онбордингу и контекст‑свитчам.
• Шаблоны репозитория (темплейты конфигов, линтеров, CI) - меньше разнобоя между сервисами.

6) Чёткая «Definition of Done»

• Готово - это когда есть тесты, логирование/метрики, миграции, фича‑флаг и обновлённые доки. Нет - не готово.
• Простая политика релизов: кто мёржит - тот и выкатывает, «you build it, you run it». Это поднимает ответственность и качество изменений.

7) Сокращаем простой на ожиданиях

• Метрики цикла разработки: Time to First Review, Cycle Time (idea → prod), WIP, очередь ревью, средний размер PR. Эти цифры отвечают, где утекает день.
• Политика «никаких блокеров без видимого владельца»: если задача ждёт ревью/решения, на карточке всегда указан человек и срок.

8) Когда застряли - идём в пару

• Парное программирование 60-90 минут на узких местах (сложная баг‑фиксация, критичный рефакторинг). Короче очередь, меньше пересборок, быстрее доезжаем до решения.
• После пары - короткий «design capture»: 3-5 абзацев, что сделали и почему. Это экономит время следующему, кто полезет в этот код.

Как запустить за 2 недели (план)

1. Неделя 1: включить CODEOWNERS, ввести лимит на размер PR, договориться про SLA на первый отклик, выделить окна фокуса. Настроить кэш зависимостей и параллельный прогон тестов в CI.
2. Неделя 2: добавить превью‑окружения для PR, завести шаблоны для PR/Issues с чек‑листом, зафиксировать Definition of Done, перевести часть встреч в короткие RFC. Начать собирать Time to First Review и Cycle Time.

Почему это работает вместе? Малые батчи + быстрое ревью дают короткий цикл. Быстрый CI прибыльно кормит обратной связью. Асинхронные решения и превью‑среды уменьшают созвоны и уточнения. А метрики удерживают процесс в тонусе. В сумме команда реально высвобождает часы для редактора и доводит фичи до продакшена быстрее и стабильнее.

Личные привычки, которые реально работают

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

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

1. План накануне. В конце дня запиши одну главную задачу на завтра и один кусок техдолга. Утром не тратишь 20 минут на «с чего начать».

2. Два фокус‑блока по 90 минут. Один - утром, второй - после обеда. В календаре эти окна заняты, режим DND включён, мессенджеры закрыты (не свёрнуты, а закрыты).

3. Чаты и почта - 3 раза в день по таймеру (например, 11:30, 14:30, 17:30). Без фоновых уведомлений. Срочное - через звонок.

4. Мини‑PR по итогу фокуса. Если задача большая - режем на логические куски. Лучше 3 маленьких PR, чем один на тысячу строк.

5. Чек‑лист перед PR. Линтер, тесты, миграции, описание кейсов и скриншоты UI - прежде чем звать ревьюера.

6. 5 минут на метрики. Сверь IDE‑активность (WakaTime/JetBrains), сколько времени ушло на ревью и сборки, что упёрлось в ожидание.

Полезные микро‑привычки для веб‑разработчика:

• Пре‑коммит/пре‑пуш хуки: husky + lint-staged, быстрые unit‑тесты локально. CI не должен быть первым местом, где ты видишь ошибки.

• Горячие клавиши и сниппеты в IDE. Выдели вечер, выучи 10 горячих клавиш и сделай 5 сниппетов для повторяющегося кода (хуки, запросы, хэндлеры).

• Шаблоны PR и issues. Готовые секции: «Что сделано», «Как проверить», «Риски», «Миграции/скрипты». Ревьюеры быстрее понимают контекст.

• Смотри логи локально. Тренируйся воспроизводить баги без деплоя на стенды: mock‑сервисы, MSW, локальные фикстуры.

• Один таск в работе. Канбан‑лимит WIP = 1. Остальное - в бэклог.

• «Завершение дня». За 10 минут до ухода фиксанул следующее первое действие и закрыл все «висяки». Мозг отдыхает, утром старт быстрее.

Как внедрить это за неделю без стресса:

1. День 1. Включи DND и выруби пуш‑уведомления для почты/чатов. Назначь три «окна связи» в календаре.

2. День 2. Заблокируй два 90‑минутных фокус‑окна на каждый будний день. Добавь статусы «не беспокоить» в Slack/Teams.

3. День 3. Создай шаблон PR и чек‑лист. Сразу добавь его в репозиторий как PULL_REQUEST_TEMPLATE.

4. День 4. Поставь husky + lint-staged, включи fast‑tests локально. Прогоняй тесты по сохранению.

5. День 5. Разрежь крупную текущую задачу на 2-3 небольших PR (по одному смыслу).

6. День 6. Настрой IDE‑плагин для замера активности (WakaTime, Code Time). Заведи простую цель: +30 мин фокуса в день.

7. День 7. Итог: посмотри на календарь, PR‑метрики и IDE‑время. Откорректируй: где забирают время встречи, где тормозит CI, какие привычки зашли.

Нюанс: не стремись к идеалу завтра. Достаточно, чтобы новый ритуал сработал 4 дня из 5. Прогресс здесь линейный: каждый день с фокус‑блоками и маленькими PR возвращает тебе часы живого кодинга.