[2/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx)

Продолжим рассмотрение статьи про developer productivity обсуждение проблем опросов, которые часто используются для ответов на вопросы о продуктивности.

Представим опрос про связь самооценки продуктивности инженеров и воспринимаемого уровня качества кода. Даже получив результаты опросы, у нас эффекты, что мешают вывести причинно-следственную связь между качеством кода и продуктивностью
1) Time-invariant effects - эти эффекты имеют тот же самый эффект в разные моменты времени, например, уровень образования респондентов
2) Respondent-independent time effects - это эффекты, которые влияют на респондентов одинаково, например, сезонные эффекты или крупные инициативы на всю компанию
3) Non-differentiated response effects - это эффекты, когда респонденты склонны давать одинаковый ответ на все вопросы. У одного респондента это может быть средний вариант ответа на все вопросы, а у другого самый высокий.
Но в панельном исследовании есть возможность устранить эти эффекты, анализируя данные за разные промежутки времени, а также есть возможность попробовать установить не только корреляции, но и причинно-следственные связи. Дальше авторы описывают связанные научные работы и показывают как обычно использовались time-series данные и что их можно использовать для ответов на часть вопросов, изначально поставленных в исследовании. Правда, эти эти способы не использовались раньше для анализа developer productivity, а также они не подходят для того типа данных, что используют авторы этого исследования.

Дальше авторы переходят к рассказу о методах панельного исследования, где в качестве источников данных используются
1) Данные из логов использования внутренних инструментов, навроде, данных о редактировании файлов, билдах, работе в системе codee review и так далее. Важно отметить, что эти данные содержат хорошо гранулированную историю о работе инженеров, что точно измерять поведение инженеров и характеризовать используемые ими рабочие практики и задачи, которые они выполняют при этом.
2) Данные лонгитюдных исследований (опросов), которые проводятся посредством EngSat (engineering satisfaction survery). Это долговременные исследования в виде опросов, ответы на которые собираются каждый квартал у трети инженеров. Подробнее про них в отдельном whitepaper "Measuring Developer Experience With a Longitudinal Survey", про который я уже рассказывал.

Дальше описываются зависимые и независимые переменные, которые используются в модели исследования и объясняется как мы строим модель, чтобы ее можно было ответить на изначальные вопросы исследования. В качестве зависимых переменных используются самооценки продуктивности инженеров, которые взяты из опросов. С одной стороны именно эту переменную исследовали в других исследованиях и выявили некоторую корреляцию между субъективным и объективными исследованиями. В качестве объективных метрик были взяты следующие три категории метрик
1) The amount of output (per quater) - тут было 2 метрики: total number of changelists и total lines of code
2) The amount of time per item (changelist) - тут было 2 метрики: median active coding time, median well-clock coding
3) The amount of time for non-productive activities - тут было 2 метрики: median wall-clock review time и median wall-clock merge time

Для анализа авторы собрали данные 6 последовательных кварталов с 2018Q1 по 2019Q2. Для анализа у исследователей накопилось порядка 2к точекк и дальше они построили модельку, что на рандомно выбранных 10% данных для валидации получили 83% precision и 99% recall. Причем основным предиктивным фактором оказался Median Active Coding TIme, что кажется логичным.

На этом этот пост заканчивается, а в следующий раз я расскажу про независимые переменные и модельку целиком.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Andrew Ng Explores The Rise Of AI Agents And Agentic Reasoning | BUILD 2024 Keynote (Рубрика #AI)

Три месяца назад Andrew Ng выступал с keynote докладом про AI Agents и агенсткие размышления. Мне доклад понравился и я решил поделиться саммари с основными мыслями

1) AI как трансформационная технология
Эндрю сравнивает AI с "новым электричеством", подчеркивая его потенциал для создания прорывных приложений. Основной фокус смещается к прикладному уровню, где генерируется основная ценность, благодаря возможности быстрого прототипирования (создание MVP за дни вместо месяцев).
2) Эволюция стек-технологий ИИ
Выделены три слоя:
- Инфраструктура - полупроводники, облачные платформы
- Базовые модели - trainings, foundation models
- Application слой - быстрорастущий сегмент с примерами вроде чат-ботов и автоматизированных рабочих процессов
3) Gen AI как катализатор
Создание приложений с AI возможностями в некоторых случаях ускорилось в 100 раз: создание приложений типа распознавания речи или анализа изображений теперь занимает 3 дня вместо года. Ключевой вызов - оценка эффективности моделей, где внедряются параллельное тестирование и автоматизированные циклы обратной связи.
4) Агентские рабочие процессы — новая парадигма
Представлены 4 шаблона проектирования:
- Reflecation: Итеративное улучшение кода через автоматизированную критику (пример: генерация Python-скрипта с проверкой юнит-тестами).
- Tool use (API calls): Интеграция с внешними сервисами (возврат платежей, отправка email).
- Planning (decide on steps for task): Последовательное выполнение сложных задач (генерация изображения → анализ позы → коррекция).
- Multi-agent collaboration: Коллаборация специализированных агентов (аналитик + дизайнер + тестировщик).
5) Vision Agent - кейс применения
Платформа Landing AI демонстрирует:
- Автоматическую индексацию видео с выделением ключевых кадров (пример: поиск "лыжник в воздухе" среди 10 часов записи).
- Распознавание контекста: Поиск объектов по сложным описаниям ("черный чемодан с царапиной у ручки").
- Генерацию метаданных для тренировки custom-моделей.
6) Тренды будущего
- Революция в обработке изображений/видео по аналогии с текстовым ИИ.
- Рост мультимодальных агентов, способных комбинировать текст, изображения и API-вызовы.
- Смена парадигмы разработки: смещение от hand-coded алгоритмов к оркестровке автономных агентов.

В заключении своего рассказа Эндрю призывает разработчиков экспериментировать с агентскими фреймворками, прогнозируя взрывной рост приложений в компьютерном зрении и мультимедийной аналитике. Ключевой месседж: "Сейчас лучшее время создавать ИИ-продукты, где 90% работы выполняют агенты, а люди фокусируются на высокоуровневом дизайне".

#AI #ML #Engineering #Software #Architecture #SystemDesign #DistributedSystems

[1/2] The learning trap. How Byju's took Indian edtech for a ride (Ловушка обучения) (Рубрика #Management)

С большим интересом я прочитал эту книгу осени 2023 года, в которой подробно рассказано о махинациях гиганта индийского edtech сектора Byju's. Если говорить про саму компанию, то когда-то оценка компании составляла 22 млрд долларов, а сейчас она буквально ничего не стоит. Отдельно отмечу потерянную при переводе игру слов в английском названии книги - основное приложение BYJU's называлось "The Learning App", а автор в своем названии обыграл это через "The learning trap" и получилось очень точно и красиво. Книгу написал журналист Прадип Сахи, который задавал вопросы по поводу бизнес-модели компании и когда она была на коне, но когда начались проблемы он решил оформить свое журналисткое расследование в остросюжетную книгу. Здесь Прадип раскрывает агрессивные маркетинговые тактики, корпоративные провалы и финансовые махинации под руководством основателя Биджу Равендрана, чья империя рухнула из-за обвинений в мошенничестве, неустойчивой бизнес-модели и токсичной корпоративной культуры. К 2025 году BYJU'S столкнулась с процедурой банкротства, потерей 95% стоимости и судебными исками в Индии и США, став поворотным моментом для всего сектора. Последствия включают скептицизм инвесторов, усиление регуляторного контроля и переоценку гиперроста.

Основные моменты истории отмечены ниже
1) BYJU'S когда-то начиналась с офлайн-репетиторства ооснователя компании, Byju Raveendran (Бью Равендрана), в Керале, которое к 2015 году трансформировалось в цифровую платформу. Компания использовала пробелы индийской системы образования, позиционируя себя как инструмент для «средних учеников». Пандемический спрос на онлайн-обучение подстегнул рост: в 2020–2022 гг. BYJU'S поглотила конкурентов, включая Aakash Educational Services ($1 млрд), Epic! ($500 млн) и Great Learning ($600 млн).
2) Стратегия компании основывалась на страхе упустить возможность (FOMO) получения хорошего образования, практиковались следующие вещи
- Хищнический маркетинг: запугивание родителей обещаниями гарантированных результатов с участием звезд (например, Шахрукх Кхана или Леонель Месси)
- Манипуляции метриками: завышение числа подписок через «самопокупки» сотрудников и быстрые возвраты средств.
- Культ личности: харизма Равендрана маскировала операционные проблемы, а его выступления сравниваются с «религиозными проповедями».
3) В компании не было профессионального менеджмента и управления финансами
- Безответственное лидерство: Равендран игнорировал совет директоров, единолично одобряя сделки, включая кредит $1,2 млрд в 2021 г.
- Творческий учет: задержка отчетности за 2022 финансовый год скрыла рост убытков на 81%, аудированная отчетность задерживалась на годы, аудиторы публично отказывались от работы с BYJU's
- Токсичная культура: сотрудники отдела продаж сталкивались с нереальными целями, что привело к массовым увольнениям и психическим расстройствам.

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

#Edu #SelfDevelopment #Management #Leadership #Processes

[2/2] The learning trap. How Byju's took Indian edtech for a ride (Ловушка обучения) (Рубрика #Management)

Продолжая историю компании BYJU's (1 и 2) стоит рассказать о моменте, когда агрессивный рост дал сбой и к чему все это привело.
По мнению автора книги к падению привели следующие проблемы
1) Долговая спираль (2023–2024)
- Рост ставок: повышение ставок ФРС увеличило стоимость долларовых займов BYJU'S.
- Коллапс залогов: BlackRock снизил оценку компании до $1 млрд к декабрю 2023 г., а партнеры заморозили образовательные кредиты.
- Распродажа активов: продажа Epic! и Tynker принесла гораздо меньше, чем было потрачено на их приобретение на пике во времена ковида
2) Юридические проблемы
- Банкротство в США: Судья в США признал перевод средств «прямым мошенничеством», инициировав расследование против Равендрана.
- Процедура несостоятельности в Индии: NCLT начал процесс банкротства в 2024 г., а кредиторы вернули малую долю средств.
- Расследования: индийские органы начали изучать отмывание денег, а против Равендрана действуют запреты на выезд.

Все это повлияло не только на BYJU's, что был лидером edtech сектора, но и на остальные компании
1) Отток инвестиций
- Обвал оценок: Unacademy и Vedantu потеряли больше половины стоимости, а глобальные фонды (Sequoia, SoftBank) сократили вложения.
- Жесткий аудит: инвесторы теперь требуют аудированную отчетность и планы выхода на прибыльность.
2) Регуляторные изменения
- Защита потребителей: Edtech Consortium ввел обязательные возвраты и «периоды охлаждения».
- Этический кодекс: с 2024 г. запрещены гарантии успеха в рекламе и таргетинг на несовершеннолетних.
3) Перестройка рынка
- Гибридные модели: PhysicsWallah и upGrad развивают офлайн-центры, сочетая их с цифровым контентом.
- Нишевая фокусировка: стартапы вроде Scaler и Masai School сместились на профессиональное обучение, избегая K-12 (школьников).
4) Системные последствия
- Ответственность основателей: дело Равендрана стимулировало реформы Закона о компаниях.
- Зрелость сектора: доля edtech на индийском рынке образования ($180 млрд) упала до 3,8% (с 6,2% в 2022 г.).

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

P.S.
Кажется, что российские edtech компании тоже после ковида подсдулись, хотя и не так ярко, как BYJU's.

#Edu #SelfDevelopment #Management #Leadership #Processes

Predictive Synthesis of API-Centric Code (Рубрика #AI)

Я продолжаю изучать темы, связанные с AI в SDLC, что наталкивает меня на статьи вроде "Predictive Synthesis of API-Centric Code" 2022 года. В этой статье Daye Nam и остальные представляют новый подход, enumerative program synthesis для работы с API обработки данных, таких как PyTorch, NumPy и Pandas. Этот подход объединяет человеческую интуицию программирования с автоматизированным синтезом, используя сочетание глубокого обучения (deep learning) и традиционных методов поиска. Ниже я приведу некоторые ключевые моменты статьи

1) Композиционная модель для предсказания последовательностей API
Ключевая идея заключается в том, что код, ориентированный на API, можно синтезировать путем предсказания последовательностей вызовов функций API композиционным способом. Авторы предлагают два варианта моделей:
- First-of-Sequence (FOS): Предсказывает первую функцию API в последовательности на основе свойств входных/выходных тензоров.
- Full-Sequence (FUS): Генерирует всю последовательность вызовов API, необходимых для преобразования входных данных в выходные.
Обе модели используют рекуррентные нейронные сети (RNNs) для кодирования форм тензоров (tensor shapes) и эмбеддингов API, что позволяет им изучать шаблоны по примерам входных и выходных данных.

2) Интеграция с перечислительным поиском (Enumerative Search)
ML-модели интегрируются в перечислительный синтезатор для сокращения пространства поиска. Приоритизируя последовательности API, предсказанные нейронными моделями, время синтеза сокращается в 6–10 раз по сравнению с базовыми методами, такими как DeepCoder.

3) Обработка сложных структур данных
В работе представлены графовые кодировки (graph-based encodings) для представления фреймов данных (dataframes) и тензоров, что позволяет нейронным сетям понимать структурные преобразования. Это особенно важно для таких API, как pandas, где операции включают изменение формы данных, объединение и агрегацию таблиц.

Детали реализации
Датасет: Модели обучаются на синтетических примерах входных и выходных данных, сгенерированных путем выполнения случайных последовательностей вызовов API. Для pandas AutoPandas использует 1.4 миллиона точек данных, охватывающих 119 функций.
Embedding Layers: Кодируют функции API и формы тензоров в плотные векторы.
RNN Layers: Обрабатывают последовательности эмбеддингов для предсказания следующего вызова API или всей последовательности.
Graph Neural Networks (GNNs): Представляют фреймы данных как графы с узлами (столбцы/строки) и ребрами (отношения между ними).

Улучшения алгоритма поиска
Подход объединяет символьное исполнение (symbolic execution) с ML-ориентированной приоритизацией. Для каждого кандидата вызова API система проверяет семантическую корректность (например, совместимость форм тензоров) и использует оценки уверенности модели для приоритизации исследования.

Интересно, что эта whitepaper повлияла на последующие работы
1. Развитие ML-ориентированного синтеза программ
Методология статьи повлияла на инструменты вроде AutoPandas, который использует генераторы на основе нейронных сетей для синтеза преобразований фреймов данных.
2. Вывод типов (Type Inference) и автозавершение кода
Поздние работы, такие как Type4Py и DeepInfer, опираются на идею использования ML для семантических предсказаний

Ограничения и открытые вопросы
- Обобщение на неизвестные API: Модели испытывают трудности с обработкой API, не включенных в обучающие данные; это требует повторного обучения моделей.
- Масштабируемость для длинных последовательностей: Точность предсказаний снижается для последовательностей длиной более 3–4 шагов (что решается иерархическим обучением с подкреплением)
- Интерпретируемость: Black box нейронных моделей затрудняет отладку; это стимулирует исследования в области explainable synthesis.

Интересно, что эта whitepaper была написана до засилья авторегрессионных моделей типа GPT всех версий и больше полагалась на RNN сети, получая пристойные результаты.

#AI #ML #Engineering #Software #Architecture #SystemDesign #DistributedSystems

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

Research Insights Made Simple #9 "What Do Developers Want From AI?" (Рубрика #AI)

В этой серии подкаста речь идет про whitepaper "What Do Developers Want From AI?", про который я уже писал раньше. Для его обсуждения я позвал в гости Николая Бушкова из RnD центра Т-Банка. Николай занимается исследованиями инженерной продуктивности и глубоко погружен в темы того, как AI может улучшать инженерные процессы. Кстати, здесь можно подробнее почитать про RnD центр Т-Банка и о направлении инженерной продуктивности.

Мы обсудили следующие темы
1. Введение в тему: AI и разработчики
2. Метафоры технологических изменений (параллели с электрификацией)
3. Три уровня AI-улучшений (параллели с автомобильной промышленностью)
4. Подходы к измерению продуктивности (комбинация опросов и логов)
5. Code review и роль AI (примеры из практики)
6. Проблемы документации и технического долга
7. Платформенный подход к инструментам
8. Агентные системы и метауровень
9. Исследования продуктивности и сотрудничество (примеры из Google и Т-Банка)

Также мы упоминали и другие научные статьи, которые хорошо ложились в тему дискуссии
1) "Measuring developer goals" от Google - мы его обсуждали в предыдущей серии Research Insights вместе с Сашей Кусургашевым, а также у меня было краткое саммари по нему
2) "Resolving code review comments with ML" от Google - пока я про нее не писал, но скоро будет обзор
3) "BitsAI-CR: automated code review via LLM in practice" от ByteDance, по ней тоже будет обзор
4) "Defining, Measuring, and Technical Debt" от Google - мы его обсуждали в одной из серий Research Insights вместе с Димой Гаевским, а также у меня было краткое саммари этой статьи
5) "Build Latency, Predictability, and Developer Productivity" от Google - у меня было краткое саммари этой статьи

Эпизоды доступны на Youtube, VK Video, Podster.fm, Ya Music.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

Какие каналы я читаю для получения релевантной информации (Рубрика #Stories)

Я уже рассказывал откуда я беру интересные научные статьи, но это специфический вид контента:) А сегодня я хотел поделиться тем, как я получаю более приземленные знания по интересующим себя темам. Для этого я собрал список таких каналов

#Economics
- @hoolinomics - экономические обзоры с юмором и глубиной, нравится подача автора и школа мысли относительно разбора экономических ситуаций
#AI
- @ai_newz - новости из мира AI, которые подаются с пылу с жару, автор канала сам прикладывает руку к SOTA моделям Meta, а также хорошо знает происходящее в индустрии
- @gonzo_ML - канал с разбором ML whitepapers. Я люблю сам читать whitepapers, но они в основном про software engineering. А вот про ML я знакомлюсь с научными новостями через этот канал.
- @seeallochnaya - хороший канал с AI/ML тематикой, где выходят глубокие и интересные посты с разборами технологий и новинок
- @theworldisnoteasy - крутой канал с обсуждением будущего и футуристичными статьями, очень хорошо расширяет кругозор
#Engineering
- @rockyourdata - много информации про data engineering за рубежом, про Snowflake, Databricks и другие cloud native решения, включая open source, что позволяют увидеть как происходит сдвиг от канонического DWH в сторону Lake House и Data Mesh
- @it_arch - хороший канал по архитектуре Максима Смирнова, которого я знаю как компетентного архитектора. Максим постит индустриальные новости вокруг enterprise, solution и software architecture
- @databaseinternalschat - чат про базы данных - в этом канале есть разработчики популярных баз данных и с ними можно обсудить сложные вопросы работы планировщика, транзакций, оптимизаций и т.д.
- @backend_megdu_skobkah - в чате много ребят, что исполняют роль техлидов/архитекторов в своих компаниях, поэтому можно обсудить сложные вопросы
#T-Tech
- @kod_zheltyi - технические новинки от Т-Технологий - хороший источник новостей из мира российского бигтеха (а конкретнее Т-Технологий)
- @tbank_education - канал про образование от Т Технологий

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

#AI #Software #Engineering #Economics

Самоучитель UML, 2 издание (Рубрика #Architecture)

Иногда я все-таки очищаю свои книжные полки от старых книг, обычно этот момент наступает, когда у меня не остается места для новых книг. Именно с такой целью я снял книгу Александра Леоненкова 2006 года издания, в которой он рассказывал про UML 1.5. Эта книга была пересказом стандарта на русский язык в вольной форме. С тех пор стандарт убежал до версии 2.5.1, которая вышла в декабре 2017 года, но проблема с языком гораздо глубже ... В этом посте я немного расскажу и про книгу и про свое отношение к языку UML.

Около 20 лет назад я только начинал свою профессиональную карьеру как программист. Я учился на третьем курсе Физтеха и уже начал получать какие-то деньги за написание кода. Я писал код и до этого, он был так себе, а еще я делал это бесплатно. Но когда я понял, что это теперь моя профессия, то я решил подойти к делу серьезно и подучить теорию (это мой стандартный подход к изучению чего-то нового). Забавно, что на свой первый личный компьютер я заработал на стройке Nix, где работал на летних каникулах первого курса. Личный компьютер позволил мне проще погружаться в мир разработки, а опыт работы на стройке помог понять, что лучше работать головой, а не руками. Но вернемся к изучению теории. В университете мы учили C++ и ассемблер (признаюсь, ассемблер прошел мимо меня). На работе надо было писать на html, js, css, php, а еще знать немного linux:) Ну а для себя я решил разобраться с архитектурой и проектированием систем. Так я стал счастливым обладателем нескольких книг по UML, а также книги "Совершенный код" Макконнела, про которую я уже писал. Одной из книжек по UML был именно этот самоучитель Леоненкова, который был хоть и нудноват, но зато неплохо и на русском рассказывал про унифицированный язык моделирования UML. Книга состояла из трех частей:
- Основы UML
- Диаграммы концептуального, логического и физического моделирования
- Анализ и проектирование с использованием UML и IBM Rational Rose 2002

В основах UML автор рассказывал про процедурное программирование, потом объектно-ориентированное программирование, а потом переходил к объектно-ориентированному анализу и проектированию. Причем все это сопровождалось историческим анализом и объяснением как разные методологии разных людей потом оказались сшиты в унифицированный язык моделирования. Про это рекомендую посмотрть подкаст с Гради Бучем, создателем языка, про который я рассказывал раньше. Потом автор погружался в рассказ о моделях реального мира, метамоделях из UML, а после переходил к основным типам диаграмм, про которые я расскажу отдельно в следующем посте. После диаграмм автор рассказывает про использование IBM Rational Rose 2002, которая как раз является делом рук Гради Буча и его компании Rational, которую когда-то выкупил IBM. Гради про это интересно рассказывает в упомянутом выше подкасте.

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

P.S.
В текущий момент эта книга просто раритет. Читать ее никакого смысла уже нет:) Но вот изучить виды моделей из UML может быть полезно, поэтому дальше я расскажу про них

#DistributedSystems #Architecture #Software #Engineering #SystemDesign

Обложка книги "Самоучитель UML, 2 издание". Отмечу, что автор очень тонко уловил будущее языка UML, который при переходе от версии 1* к 2* сместил фокус с людей на машины, так как у мейнтейнеров языка была идея фикс писать описание на UML, а дальше из этого генерировать код. Это привело к падению популярности языка UML, так как люди почти перестали его использовать для общения между собой, а вот использовать его для указания машинам как генерировать код на языках программирования так и не начали:)