18 записей с тегом "data"

VP of Engineering в компании на 300 человек задал прямой вопрос: «Мы обсуждаем sabbatical-политику. HR говорит, что она бустит retention. Финансы говорят, что это 2 месяца потерянного output на каждого взявшего. Кто прав?» Данные, которые мы смогли вытащить, ответили: оба, но величины эффектов разные. Вернувшиеся разработчики достигают полного output за 4-6 недель (не за 8-12 как часто предполагают), и 90-дневный retention для post-sabbatical инженеров измеримо выше, чем у их pre-sabbatical когорты. Сюрприз — качество коммитов на ramp-up неделях выше baseline, не ниже.

Employee Benefits Survey 2023 от SHRM показывает: 22% работодателей в США теперь предлагают формальные sabbatical-программы, против 13% в 2018. Среди техкомпаний цифра прыгает до ~34% — частично конкуренция за retention, частично постпандемийный разбор burnout'а. Но большинство опубликованных данных по ROI sabbatical идут из self-report опросов. Наша IDE-телеметрия даёт то, что опросы не могут: что реально происходит на клавиатуре неделя-за-неделей, когда человек возвращается.

Спросите 100 инженеров про rubber duck debugging — 98 кивнут с видом знающих. Спросите доказательства, что это работает, и большинство сошлётся на The Pragmatic Programmer (1999). Мы можем лучше, чем 26-летний фольклор. На 2100 debugging-сессиях, которые мы инструментировали в 2025-м, инженеры, которые вербализовали баг коллеге, неодушевлённому предмету или диктофону, решали его за 31 минуту медианы — против 48 минут при silent debugging. Сокращение на 35%. Психология называет это self-explanation effect (Chi et al., 1989), и у него 30+ лет репликаций в педагогическом исследовании.

Но эффект не равномерен по типам багов. Для некоторых классов вербализация помогает 42% случаев и не помогает 58%. В статье — что говорит наша IDE-дата о том, когда уточка отрабатывает, а когда — ритуал под видом техники.

Техника Pomodoro предписывает работать 25 минут, 5 — перерыв, повторить. Франческо Чирилло придумал её в конце 1980-х для учёбы. Не для кода. Не для flow-работы, которой занимаются инженеры. Мы сравнили IDE heartbeat-паттерны инженеров, называющих себя пользователями Pomodoro, и тех, кто его игнорирует. Результаты для метода неудобные: строгие пользователи 25/5 Pomodoro в среднем кодили по-настоящему 42 минуты в день. Инженеры, игнорирующие таймер, — 2 часа 12 минут. Для большинства таймер был планово-прерывающей машиной.

Это не статья против Pomodoro. Это data-driven взгляд на то, почему 25 минут — неправильный интервал для кода, и какие интервалы совпадают с тем, как инженеры текут. Cal Newport в Deep Work уже аргументировал это концептуально. Что добавим мы — телеметрия: IDE-данные показывают конкретные breakpoints, где coding-сессии восстанавливаются или не восстанавливаются после прерывания. Формат Pomodoro прерывает ровно не в то место.

Распределённая команда с 5 часами разницы в тайм-зонах имеет медианный lead time 6.8 дней на изменение. Локализованная команда на той же кодовой базе — тот же язык, тот же размер, тот же размер PR — имеет медианный lead time 3.2 дня. Это не погрешность. Это timezone-налог, и он примерно удваивается на каждые дополнительные 3-4 часа разницы. GitLab Remote Work Report 2023 назвал «3-5 часов overlap» sweet spot'ом для async-команд, и наши IDE-heartbeat данные по 100+ B2B-компаниям говорят то же — с дополнительной детализацией, куда именно уходит время.

Это не статья о том, хороша ли удалёнка (да, для многих команд). Это про конкретные механизмы, которыми разница тайм-зон замедляет доставку, и про измерения, которые скажут, платит ли ваша распределённая команда 2×-штраф по lead-time или научилась с ним жить.

В нашем IDE-датасете из 100+ B2B-компаний инженеры AdTech-платформ деплоят на 38% меньше pull request'ов в месяц, чем инженеры в SaaS-тулинге — и при этом приносят больше выручки на человека. Параллельно The Trade Desk раскрыл, что обрабатывает более 13 миллионов ad-запросов в секунду. Масштаб такого порядка переопределяет, что значит «продуктивный». Счётчик PR'ов, который в консюмер-приложении выглядел бы тревожно, абсолютно нормален, когда одна строка конфига деплоится на 10М QPS.

Инженерия в AdTech устроена иначе, и мерить её дженерик DORA-дашбордом значит промахнуться мимо сути. В статье — что реально едят время у data-heavy команд, как выглядят цифры в 14 AdTech-компаниях нашего датасета и какие сигналы продуктивности важнее throughput для RTB, атрибуции и ad-серверов.

Медианный срок работы инженера в B2B-компании — 2.3 года (Stack Overflow Developer Survey 2025). Медианная неожиданность менеджера этого инженера при увольнении — тоже высокая. Мы сопоставили IDE heartbeat, Git-активность и сигналы из таск-трекера с 43 подтверждёнными увольнениями в 11 командах клиентов PanDev Metrics за 2025. Семь поведенческих паттернов проявились в данных за 30-90 дней до письма об увольнении.

Один из них почти никогда не попадает в стандартный список "сигналов выгорания". Из-за него этот пост и существует.

Ваша команда из 40 инженеров держит 34 репозитория. Звучит разумно? Мы видим эту форму часто. Типичный разработчик в такой конфигурации триггерит 11,4 переключения контекста в день между репо — почти все невидимы EM, каждое стоит ~23 минут рефокуса (UC Irvine, Gloria Mark, The Cost of Interrupted Work, 2008, и последующие репликации). Та же команда после миграции в monorepo: 3,2 переключения в день. Продуктивностная математика очевидна; стоимостная — интереснее.

Обе архитектуры работают. Google держит крупнейший известный monorepo (2B+ строк, ~85,000 инженеров). Netflix — тысячи polyrepo. Вопрос не в том, что лучше в вакууме — а что подходит вашему размеру команды, вашему CI-бюджету и вашей терпимости к координационному оверхеду.

Copilot написал 420 тестов для модуля платежей за два дня. Coverage прыгнул с 58% до 84%. Уверенность в релизе? Без изменений, а то и хуже. Исследование 2024 IEEE (An Empirical Study on the Usage of Transformer Models for Code Completion, Ciniselli et al.) показало: LLM-сгенерированные тесты компилируются в 92% случаев, но ловят лишь 58-62% инъектированных мутаций — стандартный исследовательский тест на «этот тест вообще что-то проверяет». Человеческие тесты в том же исследовании — 78%. Разрыв ~20 процентных пунктов в mutation score — реальная история качества AI-тестов, а не цифра coverage, которую все репортят.

Эта статья измеряет, в чём AI-тесты хороши, что они пропускают, и как выстроить pipeline, чтобы AI давал throughput, не разъедая уверенность в релизе.

AI-ревью кода сидит на гребне хайп-цикла. GitHub Copilot, CodeRabbit, Qodo, Graphite и ещё полдюжины стартапов продают будущее, где LLM ловят баги быстрее людей. Классическое исследование Microsoft Research и Bacchelli 2013 года задало бейзлайн, с которым мы сравниваемся десять лет: человеческое ревью ловит ~14% функциональных дефектов, но 68% проблем maintainability. Вопрос сегодня: сдвигает ли добавление LLM хоть одну из этих цифр?

Мы вытащили данные по ревью со 100 B2B-команд между Q1 2025 и Q1 2026 — микс команд с AI-ревью, без, и с гибридом. Паттерн не такой, как рассказывают вендоры.

Каждый руководитель разработки задаёт один и тот же вопрос: сколько времени разработчики реально тратят на написание кода?

Microsoft Research выяснили, что разработчики тратят на код всего 30-40% рабочего времени. Исследование Haystack Analytics 2019 года показало ближе к 2 часам. Наши собственные данные IDE heartbeats по B2B-командам подтверждают медиану в 78 минут в день.

Вот что реально показывают данные и почему это важно.