Одни разработчики клянутся, что лучшее начало дня — 6 утра с кофе и тишиной. Другие не открывают IDE до 10 вечера. Менеджеры спорят: вводить «core hours» или позволить людям работать когда угодно.
Мы проанализировали обширные данные активности разработчиков из более чем 100 B2B-компаний, чтобы узнать, когда разработчики на самом деле пишут код — и имеет ли значение время суток.
У каждого engineering-менеджера есть интуитивное ощущение недельного ритма команды. Понедельник кажется медленным. Пятница — временем сворачивания. Но что на самом деле показывают данные?
Мы проанализировали тысячи часов кодинга от разработчиков из более чем 100 B2B-компаний, чтобы построить карту продуктивности по дням недели — и результаты ставят под вопрос некоторые распространённые убеждения.
Спор об IDE вечен. Фанаты VS Code говорят, что он быстрый и расширяемый. Приверженцы JetBrains клянутся глубокой языковой поддержкой. А теперь Cursor — новый претендент, оседлавший волну AI. Stack Overflow Developer Survey стабильно ставит VS Code на первое место как самый популярный редактор, в то время как JetBrains Developer Ecosystem Survey показывает высокую лояльность среди своих пользователей. Но опросы измеряют настроения, а не реальность.
Но что разработчики на самом деле используют, когда садятся за работу? Не то, что они пишут в Twitter. Не то, что они отметили звёздочкой на GitHub. То, в чём они пишут код, час за часом, день за днём.
У нас есть данные. Тысячи часов отслеженного времени написания кода в 100+ B2B-компаниях, с разбивкой по IDE.
«Добавление рабочей силы к запаздывающему программному проекту задерживает его ещё больше.» Фред Брукс написал это в 1975 году. Пятьдесят лет спустя руководители инженерных команд всё ещё спорят, правда ли это.
Мы проанализировали реальные данные кодирования из 100+ B2B-компаний на PanDev Metrics, чтобы понять, как размер команды соотносится с индивидуальной продуктивностью разработчика. Ответ оказался более нюансированным, чем предполагал Брукс — но его ключевая идея по-прежнему верна.
AI-ассистенты для кодирования за три года прошли путь от новинки до необходимости. GitHub Copilot, Cursor, Cody и десятки альтернатив теперь находятся внутри редакторов разработчиков, предлагая код, отвечая на вопросы и генерируя шаблонный код. По оценкам Deloitte, ~70% enterprise-команд разработки уже используют ту или иную форму AI-ассистированного кодирования.
Но действительно ли они делают разработчиков продуктивнее? Или просто более зависимыми от автодополнения?
Мы проанализировали реальные данные использования IDE из 100+ B2B-компаний, чтобы выяснить, как выглядит AI-ассистированное кодирование на практике.
Вы только что наняли senior-разработчика. Он выходит в понедельник. Когда он выйдет на полную продуктивность?
HR говорит «30 дней». Нанимающий менеджер говорит «пару недель». Сам разработчик говорит «дайте мне кодовую базу и всё будет нормально».
Реальность другая. Данные активности кодирования рассказывают более честную историю о том, как на самом деле выглядит адаптация нового разработчика — и она длится дольше, чем планирует большинство организаций.
У каждого CTO был такой разговор. Вы заходите в кабинет CEO и говорите: «Нам нужно потратить следующий квартал на рефакторинг». CEO спрашивает: «Какая бизнес-ценность?» Вы пытаетесь ответить в терминах, не включающих слова «архитектура», «связанность» или «внедрение зависимостей». DORA State of DevOps Reports последовательно показывают, что команды с большим техническим долгом деплоят ~50% реже и имеют ~2-3x более высокий change failure rate.
CEO не ошибается, задавая этот вопрос. Он не против инженерии. Он просто хочет понять инвестицию в бизнес-терминах. И именно здесь большинство CTO терпят неудачу — не потому что плохо коммуницируют, а потому что у них нет нужных данных.
Вот как это исправить.
Добавьте XP, уровни и бейджи на платформу для разработчиков — и получите две реакции. Одни разработчики загораются: проверяют прогресс каждый день, соревнуются в рейтингах и с гордостью отображают бейджи в своих GitHub-профилях. Другие отшатываются: видят в этом слежку, замаскированную под игровые механики — инфантильную систему, которая сводит их ремесло к числу.
Обе реакции обоснованы. Вопрос не в том, работает ли геймификация в абсолютных терминах. А когда, как и для кого.
Самый распространённый страх инженеров по поводу трекинга активности прост: «Мой руководитель использует эти данные против меня.»
И они имеют основания беспокоиться. Многие организации внедряли «метрики продуктивности» как кнут — выявляя, кто пишет меньше всего кода, кто коммитит меньше всего строк, кто логирует меньше всего часов. Результат предсказуем: разработчики накручивают метрики, нарастает обида, лучшие уходят, а оставшаяся команда оптимизирует видимость занятости вместо реальной эффективности.
Есть лучший путь. Данные могут быть инструментом позитивного подкрепления — и это гораздо эффективнее.
Developer Experience — DevEx или DX — превратился из нишевой концепции в тему для совета директоров. Такие компании, как Google, Spotify и Shopify, имеют выделенные DevEx-команды. Количество вакансий «Developer Experience Engineer» утроилось с 2023 года. JetBrains Developer Ecosystem Survey теперь включает вопросы, специфичные для DevEx, сигнализируя, что индустрия считает это измеримым параметром, а не просто модным словом.
Но что такое Developer Experience? Как измерить нечто, что кажется по своей природе субъективным? И почему VP of Engineering должен об этом заботиться?