Telegram Web
Поездка в Питер на длинные выходные (Рубрика #Rest)

Сгоняли семьей на длинные выходные в Питер. Решили съездить на машине и по пути туда жалели о своем решении - ехали вместо предсказанных навигатором шести с половиной часов все десять - на платнике было плотно, были аварии, а все заправки были забиты, пришлось час ожидать заправки недалеко от Питера. Но мы доехали до Лахта Плаза и заселились. В следующие дни удалось
- Посетить Гранд Макет Россия и показать его детям
- Съездить в Новую Голландию, поползать по детскиой площадке в форме большого корабля, купить книжек в их цилиндрическом здании
- Посетить аквапарк "ПитерЛенд", а потом прогуляться по парку 300-летия Санкт-Петербурга
- Еще мы насладились едой в о"Вкусно Дорого", а также "Коза Море"
- Прикольно, что удалось потусить с моим братом и показать ему племянников

Правда, мы решили уехать обратно во второй половине субботы, чтобы доехать обратно комфортно, а не в перманентной пробке на платнике:)

#ForKids #ForParents #Rest
[1/3] What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time (Рубрика #Productivity)

На эту интересную статью 2025 года от компании "Meta" я наткнулся во время подготовки обзора статьи "Enabling the Study of Software Development Behavior With Cross-Tool Logs" (мой обзор: 1, 2 и 3). И хоть деятельность организации "Meta" запрещена на территории РФ, но читать их инженерный whitepaper достаточно интересно. Основная идея этого исследования - это измерение продуктивности разработки софта через метрику Diff Authoring Time (DAT), которая представляет собой активное время разработчика на создание изменений в коде (диффов), которые по сути своей напоминают MR (merge requests). Это время собирается при помощи системы телеметрии, интегрированной с системой контроля версий, IDE и операционной системой .

Ключевая ценность этого исследования для Meta это
- Переход от интуитивных оценок к научному подходу измерения продуктивности на основе DAT
- Измерения DAT направлены не на оценку performance конкретных разработчиков, а на оценку эффекта инструментов и процессов на продуктивность
- Этот подход дает возможность проведения a/b экспериментов изменения тулинга и процессов - по утверждению авторов они уже ее обкатали на 20 проектах, про три из которых они рассказывают в статье
- Важно, что часть экспериментов можно катать с гранулярностью на уровне diffs (эксперименты, что прозрачны для инженеров), а часть на уровне когорт инженеров (те, где изменения явно видны и не позволяют менять подход для разных diffs - например, переключение между версиями IDE)

Забавно, что авторы утверждают, что-то в стиле того, что их исследование впервые в индустрии предоставляет количественные доказательства влияния различных инструментов и методов разработки на продуктивность в реальной корпоративной среде. Видимо, они не читали исследований ребят из Google, например, то, что я упоминал выше от 2020 года:)

Если говорить про струткру модели, то она состоит из следующих частей
1. Основной алгоритм точного сопоставления
Отслеживание активности в IDE: Система фиксирует время работы в интегрированной среде разработки
Интеграция с системой контроля версий: Связывает временные сессии с конкретными коммитами через Sapling (система контроля версий Meta)
Алгоритм сдвига влево: Каждый коммит CHx приписывается к IDE-сессии s(x-1), которая предшествует ему
2. Дополнительные эвристики
Anchor Sessions: Захватывает активность, предшествующую точному совпадению, для более полного покрытия времени разработки
Обработка крайних случаев: Автоматическое исключение checkout'ов и фильтрация нерелевантной активности
3. Система телеметрии с защитой приватности
OS-уровневая телеметрия: Отслеживание активности на уровне операционной системы
Интеграция с инструментами: Плагины для VS Code, Sapling и других инструментов разработки
Неперекрывающиеся измерения: DAT гарантирует, что время между различными диффами не пересекается для одного разработчика

В итоге, мы получаем следующие ключевые свойства модели
- Неперекрываемость: DAT(D123) ∩ DAT(D987) = ∅ для одного пользователя, где D123 и D987 - это два разных diffs
- Ограниченность: DAT не может превышать 24 часа в день
- Агрегируемость: В отличие от других метрик, DAT можно корректно суммировать

Продолжение обзора в следующем посте.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes
7 Habits of Highly Effective Generative AI Evaluations (Рубрика #AI)

Посмотрел на выходных интересное выступление про evaluations от Джастина Мюллера, Principal Applied AI Architect в Amazon Web Services (AWS). Команда Мюллера в AWS помогает клиентам масштабировать рабочие нагрузки с генеративным ИИ, и за время работы он имел возможность изучить более 100 различных попыток создания фреймворков оценки работы моделей. Это выступление прошло недавно в рамках конференции AI Engineer World's Fair. Ключевой идеей выступление было то, что основная проблема при масштабировани genAI решений в недостаточности оценок (evaluations) качества их работы. Несмотря на то, что многие называют основными проблемами стоимость, галлюцинации, точность и производительность, именно отсутствие подходящих evaluation фреймворков чаще всего препятствует успешному внедрению. Для демонстрации этой идеи Джастин рассказал реальный кейс клиента с проектом обработки документов, где точность составляла всего 22%. После внедрения системы оценки за 6 месяцев удалось достичь 92% точности и запустить проект в массовое производство, сделав его крупнейшим на тот момент по обработке документов на AWS в Северной Америке. Для решения этой проблемы с эффективной оценкой моделей автор предлагает следующие семь привычек высокоэффективных людей высокоэффективных genAI evaluations:

1. Скорость выполения (Fast)
- Целевое время выполнения оценки — 30 секунд
- Возможность делать сотни изменений и тестов ежедневно вместо 4-8 в месяц
2. Количественно измеримый (Quantifiable)
- Оценка должна выражаться в конкретных числовых показателях
- Стоит применять усреднение по множественным тест-кейсам для устранения случайных колебаний
3. Объяснимость (Explainable)
- Анализ не только результатов, но и процесса рассуждений модели
- Важность понимания логики как генерирующей модели, так и оценивающей модели
4. Сегментированность (Segmented)
- Разбиение сложных промптов на последовательность простых шагов
- Возможность оценки каждого этапа отдельно и выбора подходящей модели для каждой задачи
5. Разнообразие (Diverse)
- Покрытие всех сценариев использования
- Эмпирическое правило: ~100 тестовых примеров для основных случаев использования
6. Традиционность (Traditional)
- Сохранение использования проверенных методов оценки (из ML)
- Численные оценки, метрики точности баз данных, измерение стоимости и задержки остаются актуальными
7. Золотые стандарты
- Критическая важность создания качественного набора золотых стандартов
- Избегание использования генеративного ИИ для создания золотых стандартов во избежание воспроизведения ошибок

Ключевыми принципами от Джастина являются следующие
- Декомпозиция промптов — разбиение сложных многошаговых промптов на цепочку простых, что позволяет точно определить источник ошибок и оптимизировать каждый этап отдельно.
- Семантическая маршрутизация — интеллектуальное направление запросов к подходящим моделям в зависимости от сложности задачи, что повышает точность и снижает затраты.
- Фокус на выявлении проблем — главная цель оценок не просто измерение качества, а обнаружение конкретных проблем и предложение путей их решения.

В общем, выступления Мюллера - это сборник практических советов о том, как стоит организовывать свой фреймворк оценки GenAI моделей. Эти советы звучат логично, выглядят доступно, а также проверены на опыте работы с крупнейшими рабочими нагрузками в Северной Америке.
Выступление в Вышке перед студентами ФКН (Рубрика #SystemDesign)

Меня позвали поговорить со студентами про System Design и я не смог отказаться. В итоге, сегодня буду рассказывать истории про то
- Как сейчас выглядят процессы разработки внутри компании - со сложными и большими системами и децентрализацией принятия технических решений
- Как мы набираем людей и зачем нам System Design Interview
- Как дальше выглядят процессы после трудоустройства - расскажу про RFC/ADR, ревью архитектуры, общие инженерные вопросы типа reliability, security и так далее и что не всегда все при проектировании выглядит так просто, как на System Design Interview

А в конце я еще планировал поотвечать на вопросы ребят.

P.S.
До этого я уже рассказывал про процессы найма в большие компании и типы интервью на примере Т-Банка. Про System Design у меня тоже было много материалов. Например можно посмотреть в общем про system design в Tinkoff, больше про то, как мы оцениваем прохождение собеседования и как подготовиться к собеседованию или публичные интервью на ArchDays

#Career #HR #Management #Architecture #Software #Leadership #Processes
[2/3] What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time (Рубрика #Productivity)

Продолжая рассказ про этот whitepaper от Meta, чья деятельность запрещена на территории РФ, перейдем к валидации подходом с использованием DAT (Diff Authoring Time). Для этого авторы прповели дополнительные исследования

1. Исследование пользовательского опыта
- Создали ground truth датасет через запись реальной работы разработчиков
- Использовали случайную выборку для минимизации предвзятости
- Получили среднюю точность DAT более 90% по сравнению с реальными данными

2. Крупномасштабный опрос
- Сравнили DAT с оценками разработчиков (968 уникальных диффов)
- Встроили опросы в инструмент Phabricator, который используется для код ревью. Опрос стартует сразу после завершения диффа
3. Дескриптивная статистика
- DAT покрывает 87% всех подходящих диффов
- DAT оказалось стабильной метрикой (использовался 99-го перцентиль winsorized mean для отчетности)
- Авторы отвалидировали DAT, проведя сравнение с метрикой Time Spent by Diff, которая определяется как "averages coding time in a given period by the number of diffs published in that period"
4. Визуализация временных рядов
- Сделали детальную визуализацию того, как сырая телеметрия преобразуется в DAT (изображение будет в финальном посте)
- Сделали кросс-валидацию с авторами изменений (с самими разработчиками)

Дальше авторы рассказывают про 3 конкретных эксперимента, которые они проводили

1. Типизированное мокирование в Hack
Суть эксперимента в том, чтобы внедрить типизацию в инструменты мокирования внутри Hack (внутренняя версия доработанного PHP). Для эксперимента авторы мигрировали часть моков на типы, а часть оставили как есть и дальше сравнили DAT при создании diffs в разных частях кодовой базы. Эксперимент показал как языковые возможности с конкретными показателями продуктивности
- 14% улучшение DAT: Первое количественное доказательство влияния типизации на продуктивность в промышленной среде
- Статистическая значимость: p < 0.001 для всех размеров диффов

2. Авто-мемоизация в React компайлере
Авторы дорабатывали фреймворк React для авто-мемоизации и дальше провели эксперимент, где сравнили DAT при создании diffs с ручной и автоматической мемоизацией.
- Они использовали смешанную модель эффектов для учета конфаундеров через регрессионную модель
- Для нерандомизированных данных они использовали Wasserstein distance для измерений истинной разницы между граппуми
- 33% улучшение DAT: Значительное повышение эффективности при использовании автоматической мемоизации

3. Анализ эффективности от переиспользования кода

Это исследование мне показалось самым интересным, так как авторы оценивали эффект применения кросс-платформенных технологий (у ребя это был React). Правда, для анализа пришлось использовать контрфактический анализ для оценки гипотетического времени разработки без переиспользования кода. На выходе получилось, что
- Кроссплатформа дает больше, чем 50% улучшение относительно разработки без переиспользования
- А это тысячи часов ежегодной экономии DAT через фреймворки переиспользования кода

В итоге, этот подход к использованию метрики DAT привел к следующим эффектам
- Переход Infrastructure команд к культуре, ориентированной на a/b эксперименты
- Принятие решений на основе данных - DAT используется для планирования и приоритизации разработки
- DAT и эксперименты выравняли подходов между продуктовыми и инфраструктурными командами

Если говорить про дальнейшие планы авторов исследования, то они планируют расширение
- Горизонтально - добавление кроме diffs и других артефактов разработки (documents and tasks). Это позволит создать общий фреймворка измерения времени активностей для экспериментов
- Вертикально - поддержка большего количества инструментов (разных IDEs и других инструментов). Это позволит меньше ориентироваться на эвристики и больше на точные измерения.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes
[3/3] What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time (Рубрика #Productivity)

Немного иллюстраций из интересного whitepaper про метрики продуктивности инженеров от Meta, чья деятельность запрещена на территории РФ. Я подробно рассказывал об этой статье в предыдущих двух частях: 1 и 2.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes
Интервью с Андреем Романовским (Рубрика #Management)

Недавно я обедал с Андреем Романовским, руководителем продуктовой разработки Яндекс.Лавки и cto Yango.Tech Retail, а также автром канала Lead’s Notes (@leadsnotes). За обедом мы обсуждали кучу интересных вещей - оказалось, что нам есть о чем поговорить. По ходу дискуссии у нас появилась идея провести совместный стрим, в котором мы хотели обсудить одну из трех тем, представленных ниже

1. Стартапы в корпорациях: как и зачем рождаются, чем отличаются от обычных стартапов, как стоит или не стоит их строить
2. Эффективность и мотивация команд в больших компаниях: что это вообще такое, что работает или не работает, эволюция подходов в процессах и технологиях (от код-ревью и скрама до AI-ассистентов в IDE и сложных матричных структур)
3. Менеджерская карьера и жизнь в компании: как дорасти до c-level позиции, заработать свой первый $1 mln и не сойти с ума, как адаптироваться к зоне растущего размера и сложности

В итоге, мы так и не выбрали тему, поэтому предлагаем вам выбрать вариант, что вам ближе, а дальше мы сделаем онлайн-стрим и поговорим на выбранную тему, а вы сможете позадавать дополнительные вопросы по ходу нашего общения.

#Software #Management #Leadership #Engineering
Amazon CEO Andy Jassy on Agility, AI Strategy, and the Changing Role of Managers (Рубрика #Management)

Посмотрел на выходных интервью Andy Jassy, генерального директора Amazon, которое он дал Adi Ignatius, представителю HBR (Harvard Business Review). Сам Джесси работает в Amazon уже 28 лет и занимает должность CEO с 2021 года, сменив основателя компании Джеффа Безоса. Ранее он руководил подразделением Amazon Web Services (AWS). Интервью было интересным и я решил рассказать суммировать основные идеи этого обсуждения

1. Философия "крупнейшего стартапа в мире"
Джесси представил концепцию работы Amazon как "крупнейшего стартапа в мире". По его мнению, для сохранения стартап-культуры в крупной корпорации необходимы следующие элементы (очень напоминающие leadership принципы Amazon)
- Решение реальных проблем клиентов — нельзя быть просто влюбленными в технологии
- Команда строителей — нужны люди, которые умеют анализировать клиентский опыт и изобретать
- Мышление владельца — сотрудники должны думать так, как если бы тратили собственные деньги
- Скорость — которая имеет непропорционально большое значение для успеха
- Готовность к рискам — опасаясь неудач невозможно создать что-то уникальное

2. Борьба с бюрократией
Джесси отметил важность борьбы с бюрократией, что распространена в больших компаниях и замедляет их. Он поделился своим опытом конкретных мер для борьбы с ней:
- Сокращение управленческих слоев — увеличение соотношения индивидуальных исполнителей к менеджерам минимум на 15%
- Почтовый адрес для борьбы с бюрократией — сотрудники могут напрямую сообщать CEO о бюрократических препятствиях
- Практические результаты — уже изменено 375 процессов на основе более чем 1000 полученных писем (и прочитанных самим Джесси)

3. Возвращение в офис
Нельзя было обойти и обсуждение политики RTO (return to offfice), а точнее возвращения всех сотрудников на 5 дней в офис. Это решение принял Джесси в прошлом сентябре (я про это рассказывал). Он обосновал это следующими причинами
- Улучшение изобретательства — личное присутствие способствует более эффективному сотрудничеству и генерации идей
- Распространение культуры — корпоративная культура лучше передается при личном общении
- Обучение и наставничество — более эффективны при непосредственном контакте

4. Стратегия в области искусственного интеллекта
Джасси представил стратегию Amazon в сфере ИИ, основанную на трех макроуровнях:
- Нижний уровень — для разработчиков моделей (чипы Trainium, сервис SageMaker)
- Средний уровень — для пользователей существующих моделей (сервис Bedrock)
- Верхний уровень — приложения (более 1000 генеративных ИИ-приложений Amazon), но в основном их создают пользователи сервисов AWS
Особое внимание Джесси уделил помощнику по покупкам Rufus, который призван стать персональным консультантом для онлайн-шопинга на Amazon.

5. Лидерство в эпоху неопределенности
Джеси подчеркнул важность сосредоточения на контролируемых факторах в условиях глобальной неопределенности:
- Фокус на клиентах — главная задача состоит в том, чтобы делать жизнь клиентов проще и лучше каждый день
- Контроль управляемого — нельзя контролировать все, но можно управлять тем, что в твоих силах

По мнению Джеси, успешное лидерство XXI века требует:
- Отличного клиентского опыта с успешными финансовыми результатами
- Внимания к устойчивости, разнообразию и долгосрочному мышлению
- Способности адаптироваться к изменяющимся приоритетам

6. Карьерные советы
Джасси поделился ключевыми принципами успешной карьеры:
- Стоит выбирать работу, которой действительно увлечен и в которой можешь преуспеть
- Не надо бояться ошибок, так как самые важные уроки приходят именно из неудач
- Важно иметь правильные установки: трудолюбие, надежность, командный дух и позитивное отношение к жизни
- Важно уметь непрерывно учиться - в динамичной среде прекращение обучения равносильно началу деградации

В общем, хорошее системное интервью, в котором, правда, я не нашел каких-то инсайтов для себя.

#Management #Leadership #Processes #Bigtech #Software #AI
Message from CEO Andy Jassy: Some thoughts on Generative AI

Продолжу тему Amazon и расскажу про сегодняшее письмо Энди Джесси с его мыслями про gen AI. Кажется, что оно неплохо продолжает тему интервью про гибкость, AI стратегию, роль менеджеров, о котором я рассказывал утром. Мне показалось, что о структуре сообщения Энди стоит думать в формате:
- Текущее состояние AI внутри Amazon в общем
- Ключевые проекты: для клиентов, для инженеров, для операци
- Последствия, которые видит Энди Джесси (самое интересное в письме)

Ну и начнем мы с текущего состояния Gen AI
Энди Джесси подчеркивает, что генеративный ИИ активно используется во всех подразделениях Amazon для улучшения клиентского опыта и повышения эффективности работы. Компания осуществляет масштабные инвестиции в эту технологию, считая ее революционной и способной полностью изменить возможности для клиентов и бизнеса. На данный момент Amazon уже разработала или находится в процессе разработки более 1000 сервисов и приложений на базе генеративного ИИ, хотя по масштабам компании это лишь малая часть того, что планируется создать в будущем. Джесси отмечает, что несмотря на значительный прогресс, Amazon находится только в начале пути внедрения генеративного ИИ. Компания планирует в ближайшие месяцы еще активнее развивать это направление, упрощая создание ИИ-агентов и разрабатывая новых агентов для всех бизнес-подразделений.

Продолжим проектами

Проекты для клиентов (b2c, b2b)
- Alexa+ — новое поколение персонального ассистента, который стал значительно умнее
- AI-ассистент для покупок (10+ mln клиентов) — у ассистента есть фичи навроде "Lens", "Buy for Me", "Recommended Size"
- Инструменты для продавцов (500k sellers) — помощь независимым продавцам в создании страниц товаров.
- Решения для рекламодателей (50k advertisers) — набор ИИ-инструментов, упрощающих планирование, создание и оптимизацию рекламных кампаний
Проекты для инженеров (AWS)
Про это хорошо было рассказано в предыдущем посте в части про стратегию AI.
Внутренние операции
- Оптимизация логистической сети с помощью ИИ для улучшения размещения запасов, прогнозирования спроса и эффективности роботов
- Обновленный чат-бот для обслуживания клиентов на базе GenAI
- Создание более интеллектуальных и привлекательных страниц с описанием товаров

Ну и перейдем к самому интересному, а точнее к последствиям, что видит Энди
1) Трансформация работы и жизни через ИИ-агентов — Джесси убежден, что ИИ-агенты (программные системы, выполняющие задачи от имени пользователей) изменят способы работы и жизни людей. Эти агенты смогут выполнять множество задач и в будущем появятся миллиарды таких агентов во всех компаниях и сферах деятельности.
2) Изменение инновационного процесса — агенты изменят масштаб и скорость инноваций для клиентов, позволив сосредоточиться на стратегическом мышлении вместо рутинной работы. Джесси видит агентов как коллег, которые будут становиться мудрее и полезнее с опытом.
3) Изменение структуры рабочей силы — внедрение Gen AI и агентов изменит характер работы в компании. Потребуется меньше людей для выполнения некоторых текущих задач и больше людей для других типов работы. В ближайшие годы Джесси ожидает сокращение общей корпоративной рабочей силы из-за повышения эффективности от широкого использования ИИ.
4) Новые требования к сотрудникам — Джесси призывает сотрудников проявлять любопытство к ИИ, обучаться, посещать семинары и тренинги, экспериментировать с ИИ и участвовать в мозговых штурмах команды. Он подчеркивает, что те, кто примет эти изменения и станет специалистом в области ИИ, будут иметь большое влияние и помогут переизобрести компанию.

Заканчивает эту статью Джесси выражением энтузиазма по поводу прогресса Amazon в области генеративного ИИ и планов на будущее.

#Management #Leadership #Processes #Bigtech #Software #AI
2025/06/19 02:46:13
Back to Top
HTML Embed Code: