Каждый рейтинг «топ языков программирования», который вы видели, основан на звёздах GitHub, опросах Stack Overflow или вакансиях. Ни один из них не измеряет, на что разработчики реально тратят своё время.

Мы измеряем. Вот рейтинг, основанный на тысячах часов реального времени кодирования в IDE по 200+ языкам программирования, отслеженных у активных B2B-разработчиков в 100+ B2B-компаниях.

Одни разработчики клянутся, что лучшее начало дня — 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-профилях. Другие отшатываются: видят в этом слежку, замаскированную под игровые механики — инфантильную систему, которая сводит их ремесло к числу.

Обе реакции обоснованы. Вопрос не в том, работает ли геймификация в абсолютных терминах. А когда, как и для кого.

Самый распространённый страх инженеров по поводу трекинга активности прост: «Мой руководитель использует эти данные против меня.»

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

Есть лучший путь. Данные могут быть инструментом позитивного подкрепления — и это гораздо эффективнее.