Если верить стереотипам, разработчик — это человек, который приходит на работу и до вечера пишет код. Иногда его отвлекают на кофе или баги, но в целом картинка в массовом сознании простая: программист = кодер.
Но стоит спросить самих разработчиков, как проходит их обычный рабочий день, и выясняется, что код — это небольшая часть того, чем они занимаются. Всё остальное время уходит на встречи, обсуждения, поддержку, согласования, контекст-переключения и попытки хоть ненадолго сохранить фокус.
И это не ощущения «кажется, я сегодня ничего не написал», а данные исследований.
В статье собрали и разобрали исследования Microsoft и других компаний, чтобы понять, из чего на самом деле состоит рабочий день разработчика и почему измерять продуктивность количеством строк кода давно пора перестать.
Исследование Microsoft: реальная и идеальная рабочая неделя разработчика
В 2024 году Microsoft Research опубликовала исследование Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks. В нём приняли участие почти 500 разработчиков. Их попросили описать две версии рабочей недели: реальную и идеальную.
В среднем, по данным Microsoft:
на написание кода уходит около 10–15% времени;
примерно столько же занимает отладка и исправление ошибок;
коммуникации и встречи съедают больше времени, чем программирование;
остальное — это code review, документация, поддержка, согласования, настройки, помощь коллегам.
Проще говоря, рабочий день разработчика — это не длинный поток сосредоточенной работы, а лоскутное одеяло из мелких активностей, между которыми приходится постоянно перескакивать. Когда тех же людей спросили об идеальной неделе, картина изменилась:
программирование должно занимать в два раза больше времени;
архитектура и проектирование — заметную часть недели;
встречи — реже и короче;
рутина — по возможности автоматизирована;
больше времени на глубокую, сосредоточенную работу без отвлечений.
На графике все это выглядит следующим образом:
Главный инсайт Microsoft
В Microsoft Research обнаружили прямую связь: чем сильнее разрыв между идеальной и реальной неделей, тем ниже удовлетворённость и ощущение собственной продуктивности.
Разработчик может быть занят с утра до вечера, но при этом уходить с работы с ощущением, что «ничего по-настоящему важного сегодня не сделал». Именно это чувство — когда день был заполнен, но пуст — становится почвой для стресса и выгорания.
Что говорят другие исследования
Последнее исследование Microsoft не единственное, где описываются подобные наблюдения.
В исследовании Today was a Good Day (Meyer et al.) наблюдали за ощущениями разработчиков через интервью и дневники. Оно показало, что хороший день по их мнению — это тот, где удалось поработать, не разрываясь между задачами. Плохой день, наоборот, почти всегда состоит из встреч, срочных вопросов, неожиданных просьб и постоянных переключений контекста. Код в такие дни тоже пишется — просто фрагментами и без ощущения прогресса.
Отчет IDC смотрит на ту же проблему с индустриальной точки зрения. Аналитики изучали, на что разработчики тратят рабочее время в компаниях разного масштаба. В отчете сделали вывод, что программирование редко занимает больше 20% недели. Основную часть времени съедают поддержка существующих систем, тестирование, работа с инфраструктурой, документация и операционные задачи.
SonarSource в исследовании How Much Time Do Developers Spend Actually Writing Code? добавляют важную деталь. Большая часть инженерной работы — не создание нового функционала, а работа с уже существующим кодом: рефакторинг, исправление багов, улучшение качества, борьба с техническим долгом. Это сложная, интеллектуальная работа, но она редко воспринимается как «настоящая разработка».
Cortex в своём отчёте о продуктивности делает акцент на скрытые потери. Ожидания ответов и другие блокеры, переключения контекста отнимают до 15 часов в неделю. Это почти два рабочих дня, которые формально есть, но фактически исчезают.
Почему миф «разработчик = кодер» опасен
Этот миф влияет не только на ожидания бизнеса и менеджеров, но и на самоощущение разработчиков. Когда человек начинает считать, что его ценность равна количеству написанного кода, всё остальное превращается в раздражающий шум. Встречи бесят, помощь коллегам воспринимается как отвлечение, а документация кажется бессмысленной тратой времени.
Но в реальности современная разработка — это сложная система взаимодействий. Код — её ядро, но не единственный элемент.
«Разработчика отличает не только умение писать код, но и инженерное мышление. Даже простая задача вроде добавления кнопки требует множества решений: как её реализовать, как она будет использоваться и каким окажется её жизненный цикл в продукте. Человек, который просто пишет код, сделает кнопку. Инженер задаст десятки вопросов — о смысле, инструментах, последствиях и контексте.
Здесь же становится важна коммуникация: задачи почти никогда не бывают полностью понятны с первого раза. Прежде чем дойти до разработчика, они проходят через десятки других людей. В идеале всё это подробно и понятно описано в задаче — в Jira или другом инструменте. Но в реальности так почти не бывает, поэтому разработчику необходимо общаться с аналитиками, дизайнерами и другими участниками процесса», — отметил Дмитрий Фырнин, технический директор и сооснователь SENSE.
Что разработчики готовы отдать автоматизации и AI
Исследование Microsoft и другие отчёты показывают: разработчики вовсе не боятся, что AI-инструменты их заменят. Но они не хотят, чтобы он делал за них интересную часть работы.
Зато с радостью готовы делегировать:
документацию;
шаблонный код;
тесты и проверки;
анализ логов;
настройку окружений;
рутинные DevOps-задачи.
То есть всё то, что мешает сосредоточиться на решении более сложных инженерных задач. Архитектуру, сложные решения, дизайн систем разработчики хотят оставить себе. И это логично, ведь именно за это разработчики обычно и любят работу.
Итог
Иногда, чтобы сделать день разработчика лучше, достаточно убрать один лишний митинг – или делегировать рутинные задачи (например, написание документации) ИИ.
Выводы в исследовании Microsoft и других работах сходятся в одном: рабочий день разработчика перестал быть «днём программирования». Это день, в котором код конкурирует за внимание со встречами, поддержкой, коммуникациями, ожиданиями и организационным хаосом. Разработчики хотят больше создавать и меньше обслуживать процессы, и это желание напрямую связано с их мотивацией и качеством работы.
P.S. А из чего состоит ваш рабочий день и каким бы хотели видеть его в идеальном мире?
Комментарии (22)
panzerfaust
19.12.2025 09:01Выводы в исследовании Microsoft и других работах сходятся в одном: рабочий день разработчика перестал быть «днём программирования». Это день, в котором код конкурирует за внимание со встречами, поддержкой, коммуникациями, ожиданиями и организационным хаосом
И будет только хуже. Раньше, если зашиваешься, был вариант расширить команду. А сейчас у манагеров будет железобетонная резолюция: у вас же ИИ есть, вы ж теперь 1000х эффективные, не хныкайте.
DevSokol
19.12.2025 09:01Интересно ваше мнение, уход от чистого написания кода к более глобальным функциям — это хуже?
panzerfaust
19.12.2025 09:01Хуже когда на вас накинут еще задач по коду, еще совещаний, еще дежурств на проде, еще разборов инцидентов, еще коммуникаций с "незаменимыми" идиотами. И все под предлогом того, что у вас есть ИИ и у вас теперь Х9000 продуктивность. Риторика незаменимых эффективных ведет ровно к этому. И уж кому как ни Micro$oft это знать.
themen2
19.12.2025 09:01Каким глобальным? Колупаться потом в этом месиве от ИИ, если ему дать таску целиком? Он пока годиться для атомных хорошо описанных ему задач
antonb73
19.12.2025 09:01Давайте скажем честно - все эти совещания, согласования и прочая паразитарная нагрузка, это недостаток управления, дефект, который идёт от самого верха. Когда учредитель не решает производственные проблемы, а решает свои эмоциональные, то он продуцирует вниз по иерархии активность, которая не нужна производственному процессу, а нужна только учредителю и его эмоциональному статусу.
За свою жизнь видел мало примеров, когда учредитель понимал, что бизнес - это не удовольствие, не статус, это работа, часто неприятная, но это созидание - будь то товары или услуги, неважно.Как только владелец стремится получить удовольствие от владения и управления бизнесом - жди беды.
DevSokol
19.12.2025 09:01А что вы еще подразумеваете под паразитарной нагрузкой? Все, что не связано с написанием кода по ТЗ?
И еще не очень понимаю про связь эмоциональных проблем и активности, связанные с производственным процессом, что вы тут имеете в виду?antonb73
19.12.2025 09:01мильён статей в интернет на эту тему....
Скрытый текст
Менеджеры часто имитируют полезную деятельность в проектах, создавая видимость активности и контроля, в то время как реальный прогресс остаётся минимальным. Основной тезис: вместо того чтобы способствовать решению задач, они потребляют ресурсы команды, требуя от специалистов подробных объяснений, переформулировок и согласований, при этом сами не обладают достаточными компетенциями для принятия решений.forbes+3
Признаки имитации деятельности
Менеджеры активно обсуждают задачи, требуют объяснений и пояснений, но не принимают реальных решений.skillbox+1
Затрачиваются значительные усилия команды на демонстрацию процессов, а не на результат.wikipedia+1
Вместо делегирования и доверия к специалистам, менеджеры инициируют бесконечные согласования и созвоны, блокируя эффективность.lifehacker+1
Причины и последствия
Такая практика часто вызвана микроменеджментом и недостатком доверия к команде.webmart+1
Специалисты, способные решать задачи самостоятельно, вынуждены тратить время на объяснение очевидного и ожидание решения менеджера.skillbox
В итоге снижается мотивация команды, а реальные результаты откладываются или вообще не достигаются.b17+1
Примеры из практики
Менеджеры могут месяцами обсуждать стратегию, не приводя к конкретным действиям или результатам.forbes
В IT-проектах часто наблюдается ситуация, когда менеджер требует от разработчиков объяснить задачу "на пальцах", хотя сам не способен принять решение, кто её выполнит.iampm+1
Таким образом, имитация полезной деятельности менеджерами проявляется в создании видимости активности, потреблении ресурсов команды и блокировании реального прогресса, что противоречит эффективному управлению проектами.lifehacker+2
https://www.ikirov.ru/news/21229-imitatsiya-burnoy-deyatelnosti-na-rabote-raspoznat-i-presech
https://iampm.club/blog/10-samyh-bolshih-problem-proektnogo-menedzhera-v-it-i-kak-s-nimi-borotsya/
https://www.anylogic.ru/blog/imitatsionnoe-modelirovanie-v-upravlenii-proektami/
https://rostbk.com/o-kompanii/stati/zachem-nuzhny-menedzhery-proektov/
https://www.businessstudio.ru/articles/article/imitatsionnoe_modelirovanie_kak_effektivnyy_instru/
https://www.reddit.com/r/managers/comments/1d88hc7/managers_whats_stopping_your_team_from_getting/
https://www.cnews.ru/articles/2023-11-02_pm_kak_arhitektor_kak_upravlyat_haosom
https://delovoymir.biz/sindrom-ibd-kak-postavit-pravilnyy-diagnoz-v-2023-godu.html
и да, я думаю так же, и более того, лично я написал тезисы по которым ИИ нашёл материалы, а не наоборот.
Ioshi-ta
19.12.2025 09:01Если верить Яндексу, то каждый разработчик у них пишет очень много страниц кода за день, а Яндекс топ, так о чем Вы ?
NerveFalcon
19.12.2025 09:01Как у вас всё сложно. В компаниях с небольшим штатом разработчиков очень многое отдаётся на ответственность каждого специалиста и согласовывается скорее общее направление и крайне важные для пользователя части задачи. На это уходит 10-20 минут на пару дней работы. С учётом того, что у нас все ценят свое время, согласование происходит за 1, максимум 2, обсуждения.
Если задача маленькая, например, баг в вёрстке - то прямо в задаче описывается текущее поведение и ожидаемое. Больше никаких согласований, в превалирующем количестве случаев, не требуется.
Metotron0
19.12.2025 09:01Всё остальное время уходит на встречи, обсуждения, поддержку, согласования, контекст-переключения и попытки хоть ненадолго сохранить фокус
Занятно, у меня на галере вообще не так. Изредка бывают созвоны, но это примерно час в два месяца. Обычно я могу работать хоть ночью. Например, сейчас сесть и что-нибудь поделать, когда все остальные вовсе в офлайне.
На самом деле, я бы хотел, чтобы и у меня были созвоны. Сидеть целый час, слушать что-то, листать хабр, а мне бы за это платили. Но приходится получать деньги только за то, что я пишу код.
День состоит из созвонов у аналитиков, менеждеров, руководства, а я простой "разработчик". Недавно в подкасте слушал, что "большинство наших задач — это придумывание чего-то нового, поэтому нельзя оценить время заранее", грустно улыбнулся. Кто-то в этом мире таки пишет что-то новое.
Yago
19.12.2025 09:01На самом деле, я почти никогда не встречал компании, которые изолировали разработчиков только до написания кода. Везде была лазейка в стиле "проявляешь инициативу - получаешь разнообразнее задачи и больше ответственности".
Это может быть ответственность как техническая из разряда "я писал код и придумал как его улучшить", так и процессная из разряда "у меня предложение по флоу задач и документированию нашего функционала, кажется, у нас просадка в полизводительнлсти из-за этого", так и продуктовая из разряда "да я вот видел в похожих проектах делали этот момент иначе, и, кажется, мы сэкономим много времени без текущего переусложнения".
Другое дело, нужно ли это самому разработчику, и готов ли он ввязываться в эти приключения. На самом деле, зависит от атмосферы в команде. Где-то она задает плодотворный темп и дает возможность проявлять инициативу сотрудникам, а где-то лишь делает вид и действует по принципу "я - начальник, ты - дурак". В плодотворной атмосфере легче начинать такие движения, а плохая лишь загубит на корню любое желание проявлять инициативу. Но первоначальный шаг должен быть все равно от желающего роста.
MilPavel
19.12.2025 09:01Хороший разработчик разбирается в предметной области, знает как должно быть и как быть не должно, предлагает заказчику решения и функционал, который может потребоваться для решения задач заказчика, а заказчик даже и не знал о таком. Все нюансы заказчик не сможет описать и рассказать. Разработчик, должен сам их изучить, видеть, как пользуются его продуктом, оперативно корректировать даже до обращения пользователей.
Yago
19.12.2025 09:01А зачем тогда разработчику нужен заказчик, если он сам прекрасно знает, как развивать продукт? Сделал бы свой да занимался им.
Вы описали роли продуктолога и аналитика, но никак не разработчика. Из-за такого смешения ответственности и осуперменивания разработчиков и происходит описанное в статье. Это уже не разработка, а хаос. Разработка это как раз воплощение идей в коде и архитектуре приложения.
MilPavel
19.12.2025 09:01В статье описывается постоянные совещания, потому что разработчики не понимают, как должно быть. Заказчик тоже не понимает. Наконец, через много итераций, получается приемлемое решение.
AlexK999
19.12.2025 09:01Как правило созвоны превалируют из за отсутствия налаженных процессов и отсутствия четких требований к продукту.
ALT0105
19.12.2025 09:01Это не моя область, но скажу. Когда мне нужно было разработать машинный код (программу в машинном коде) для моего устройства, сделанного для работы с машиной, для которой в то время не было даже ассемблера (Электроника Д3-28, 1981 год), я взял документацию по машине (систему команд процессора, до сих пор помню - код 0514 это NO OPERATION), изучил и написал. Если бы были в тот момент менеджеры любого уровня, я бы их послал ... в настоящее время. Их не было и я сделал то, чем горжусь. А ребенок, который был в коляске, с которым я гулял, читая справочник программиста Д3-28, сейчас программист (главный)
IVA48
19.12.2025 09:01Сначала важно отметить, работает ли трудяга в одиночку над всем проектом "От и До" или он в коллективе, где чёткое разделение обязанностей и специализация между исполнителями и все под единым управлением. В этих вариантах принципиально важное отличие и свои метрики. Если же говорить в общем, то Время Кодирования (непосредственная разработка кода) может соизмеряться с Этапом проектирования (который более важен и первичен) всей программной архитектуры или даже быть значительно меньше его, если детализация проектирования будет спущена на уровень отдельных процедур языка программирования. Здесь кодирование, конечно же, включает и процесс локальной отладки своей части работы. А тестирование на уровне под-систем и в целом системы все цело зависят от качества исполнения предшествующих этапов. Соизмеримое со всеми предыдущим этапами займёт и время разработки подробной (детальной) рабочей документации и документации для пользователей программного продукта.
broondulyak
19.12.2025 09:01работаю уже почти 20 лет, много разных компаний повидал и НИГДЕ я не тратил даже 30% дня на непонятные встречи (даже в забюрократированных гигантах). Большинство дней трачу 30 минут на ежидневный митап, остальное время - разработка.
Yago
Замечал, что чем больше хаоса в процессах компании, тем меньше удается писать код. Основное время начинает занимать варево в этом хаосе либо попытках его упорядочить. И упорядочивание хаоса в рамках команды довольно реально, если все понимают свои роли и цели. Но на межкомандном взаимодействии часто идет просадка и давление. А частое межкомандное взаимодействие нередко порождает расплывчатая изначальная цель функционала, который хочет инициатор.
Подобная статистика майкрософта лишь говорит о довольно посредственных процессах и отсутствии понимания ключевых результатов при разработке.
Для себя считаю идеальным 50/50 после примерно 15 лет в разработке. В периоды джуномиддловости эта пропорция была скорее в 80/20 в сторону кода. И важно, чтобы время было гармонично распределено: полдня - углубленный код, полдня - созвоны. Когда ты раз в час меняешь деятельность и переключаешься из кода в созвоны, ничего хорошего не получается. Помню, даже был инициатором dnd-времени в одной компании, где договорились разработку не тревожить в первую половину рабочего дня. Конечно, не всегда это срабатывало, но в целом, было поспокойнее.
DevSokol
«Варево в хаосе» — какое точное определение))
Хаос вообще отлично умеет съедать ресурсы в любой системе, не только в разработке. А если говорить про «посредственные процессы», то здесь, скорее, речь не столько о качестве управления, сколько о реальности больших организаций. Как бы ни были выстроены процессы, с ростом компании почти неизбежно появляется больше согласований, ожиданий и коммуникаций, чем хотелось бы — и это начинает ощущаться на уровне отдельных команд.
Про баланс между кодом и остальной работой тоже во многом согласен. Код — это важная часть ремесла, но по мере роста роль разработчика всё больше смещается в сторону инженерной работы в широком смысле: принятия решений, коммуникаций, работы с неопределённостью. Уровень, на котором человек просто реализует задачу по чёткому ТЗ, действительно чаще остаётся на джуновской стадии. Дальше разработчик становится частью общего механизма разработки, а не изолированным исполнителем.
И да, мысль про крупные блоки времени абсолютно справедливая. Не столько важно, сколько процентов уходит на код или созвоны, сколько то, как именно они распределены по дню. Когда есть возможность выделить цельные фокусные окна, эффективность и качество работы заметно растут.
SanCHEESE
Хаос ведет к ереси, это база из вахи