What Makes a Great Developer Experience? (Рубрика Productivity)
Интересный доклад Макса Канат-Александра с DPE Summit 2025 (подробнее про саммит здесь). Макс рассказывает про трех китов хорошего опыта разработчиков 1. Cycle time - сколько времени проходит от идеи до работающего результата 2. Focus - сколько у разработчика непрерывного времени на работу без дёрганий 3. Cognitive load - сколько лишнего нужно держать в голове, чтобы сделать полезную задачу
Идея в том, что почти любую проблему инженерной продуктивности можно разложить по этим трём осям по мнению Макса. А он знает толк в DevEx, так как он занимался этим всю инженерную карьеру
- как главный архитектор Bugzilla
- работая над Code Health в Google
- отвечая за Developer Experience в LinkedIn
- а сейчас он Executive Distinguished Engineer в Capital One (банк чьей моделью бизнеса вдохновлялись при создании Тинькофф) Поэтому мне взгляд Макса на productivity кажется не абстрактной теорией, а опытом полученным на практике.
Главная мысль доклада в том, что отличный developer experience - это не про красивый интерфейс внутреннего портала разработки. Это про системное снятие барьеров, которые замедляют инженера, выбивают его из фокуса и заставляют тратить мозг не на продукт, а на инфраструктурный шум. Макс по сути говорит: если улучшение не сокращает цикл, не защищает фокус и не снижает когнитивную нагрузку, то его ценность для DevEx сомнительна.
А теперь про инсайты
1️⃣ Скорость - это не мантра "работайте быстрее" От призывов ускориться или поднажать появляется только стресс, а для реального ускорения надо ускорять внутренние циклы разработки (между внутренними этапами цикла), например можно сделать
- Быстрее ревью
- Меньше и понятнее PR
- Короче сборки
- Прозрачнее CI/CD
- Быстрее локальную обратную связь Настоящая скорость рождается не из героизма, а из хорошо настроенной системы.
2️⃣ Фокус - это недооценённый актив Каждое прерывание стоит дорого. Непонятная ошибка, внезапный статус-митинг, кривой tooling, шумные алерты - всё это рвёт контекст. А восстановление контекста часто занимает заметно больше времени, чем само прерывание. Интересна мысль про то, что developer productivity часто тонет не в больших проблемах, а в постоянной мелкой фрагментации внимания.
3️⃣ Когнитивная нагрузка - главный скрытый налог Если для обычной продуктовой задачи инженеру нужно помнить особенности пяти пайплайнов, трёх систем мониторинга и семи способов доставки, то проблема не в инженере. Плохой DevEx часто выглядит именно так: разработчик пришёл делать бизнес-фичу, а вместо этого изучает внутренний зоопарк платформенных решений.
Из доклада можно извлечь очень практичные советы для технических руководителей 1) Оптимизируйте не лозунги, а путь работы Смотрите не на абстрактную "производительность", а на конкретные бутылочные горлышки: сборка, ревью, тесты, деплой, ожидание доступа, диагностика падений. 2) Убирайте фазу угадывания Если CI/CD падает с сообщением уровня "something went wrong", вы создаёте анти-DevEx. Хорошая система не просто сообщает о сбое, а помогает сразу понять причину и следующий шаг. 3) Берегите инженерный фокус как ограниченный ресурс Линейных инженеров не стоит без необходимости тащить на статусные синки. Контекст-свитчинг - один из самых дорогих видов потерь в разработке. 4) Снижайте вариативность базовой платформы Один стандартный CI, один понятный observability stack, единый способ запуска типовых сценариев - это не "ограничение свободы", а способ вернуть командам внимание к продукту. 5) Не путайте внутренний портал платформы с решением проблемы Склеить 20 плохих процессов в один красивый UI - не значит улучшить DevEx. Иногда лучший интерфейс - это вообще отсутствие ручного шага.
P.S. У Макса есть много интересных выступлений, например, про "Developer Experience in the Age of AI Coding Agents" я уже рассказывал
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign