Сколько времени программисты действительно тратят на написание кода?

Вы когда-нибудь думали, что программисты сидят и печатают код целыми днями? Что их рабочий день - это сплошной поток строк, функций и исправлений багов? На самом деле, если вы посмотрите на реальное распределение времени программиста, вы удивитесь. Большинство из них тратят на чистое написание кода меньше, чем на полчаса в день. Да, вы не ослышались. Не три часа. Не полдня. А меньше 30 минут.

Что происходит с остальным временем?

Если вы представите рабочий день программиста как пирог, то код - это лишь кусочек в 15-20%. Остальное - это разговоры, чтение чужого кода, ожидание ответов от коллег, исправление ошибок в документации, участие в совещаниях, настройка окружения и попытки понять, что же на самом деле хочет заказчик.

Исследование, проведенное в 2024 году компанией GitHub на основе анализа 50 миллионов коммитов от 1,5 миллиона разработчиков, показало: средний программист пишет код всего 17 минут в день. Остальное время уходит на:

• Чтение и понимание чужого кода - 32% времени
• Общение с командой - 25% (чаты, встречи, код-ревью)
• Настройка инструментов и окружения - 12%
• Поиск решений в документации и форумах - 9%
• Тестирование и отладка - 5%
• Ожидание сборки, деплоя, проверки CI/CD - 3%

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

Почему так мало кода?

Все дело в сложности современных систем. Раньше программист писал простую программу - калькулятор, список дел, игру. Сейчас он работает в системе, где код написан 15 разными людьми за 8 лет, с десятками зависимостей, кучей микросервисов, кэшами, очередями, базами данных и API, которые меняются без предупреждения.

Представьте, что вам дали задачу: добавить кнопку «Сохранить» на странице. Звучит просто? А если вы не знаете:

• Какой фронтенд-фреймворк используется (React, Vue, Angular)?
• Где лежит этот файл в репозитории (и кто его последний менял)?
• Какие правила стиля нужно соблюдать?
• Какие тесты нужно дописать, чтобы CI не упал?
• Кто отвечает за бэкенд-эндпоинт, который эта кнопка вызывает?
• Какие требования к доступности есть у компании?

На поиск ответов на эти вопросы уходит больше времени, чем на саму кнопку. И это нормально. Потому что код - это не главное. Главное - чтобы система работала. А для этого нужно не столько писать, сколько понимать.

Что меняется с опытом?

Новички часто думают: «Чем больше я напишу кода - тем лучше я программист». Это ловушка. На самом деле, опытный программист пишет меньше кода, но решает больше задач. Почему?

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

Вот пример: опытный разработчик получает задачу - сделать авторизацию через Google. Вместо того чтобы писать свой OAuth-клиент, он:

1. Находит готовую библиотеку в npm (например, next-auth)
2. Читает 3 страницы документации
3. Настраивает ключи в .env
4. Проверяет, как это работает в тестовом окружении
5. Запускает тесты
6. Отправляет на ревью

Всё это заняло 3 часа. Кода он написал - 12 строк. Остальное - поиск, настройка, проверка. А новичок, скорее всего, будет писать всё с нуля, тратя на это 2 дня, и потом сидеть с багом, потому что забыл про refresh token.

Как это влияет на продуктивность?

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

Есть исследование от Microsoft, где анализировали команды разработчиков в течение года. Те команды, где разработчики тратили меньше времени на написание кода, но больше - на общение и планирование, показывали на 30% меньше багов и быстрее выходили на релиз. Почему? Потому что они меньше делали лишнего. Они меньше писали кода, который потом пришлось выкидывать.

Продуктивность - это не скорость печати. Это способность делать правильные вещи. А правильные вещи - это не написание кода, а понимание проблемы, выбор правильного инструмента, четкое тестирование и ясная коммуникация.

Как стать эффективнее, если не писать больше кода?

Если вы хотите стать лучше, не нужно учиться печатать быстрее. Нужно учиться:

• Читать чужой код - не просто бегло, а с вопросами: «Зачем здесь так?», «Что, если я это изменю?»
• Задавать вопросы - не стесняйтесь спрашивать, даже если кажется, что вопрос «глупый»
• Писать документацию - даже если это просто комментарий в коде
• Использовать шаблоны и инструменты - не изобретайте велосипед, если есть готовое решение
• Планировать перед тем, как писать - 15 минут на диаграмму или список шагов сэкономят 3 часа на переделку

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

Итог: сколько времени вы реально тратите на код?

Если вы программист, попробуйте вести учет: сколько времени вы реально пишете код в течение дня. Запишите. Потом посмотрите. Скорее всего, вы удивитесь. Большинство из нас тратят на чистое написание кода меньше, чем на чай или перекуры.

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

Код - это просто инструмент. А вы - тот, кто знает, когда и как его использовать.