Книжный куб

[1/2] Behavioral Interview Discussion with Ex-Meta Hiring Committee Member (Рубрика #Management) Интересное обсуждение поведенческих интервью в бигтех компаниях. Оно само выполнено в виде интервью, которое берет Stefan Mai у Austen McDonald, бывшего senior engineering manager в Meta, а также члена комитета по найму там же. Собственно, в этом интервью Остин делится своим опытом и рассказывает свои мысли относительно поведенческих интервью. Мне эта запись понравилась, так как я часто сам провожу интервью инженеров и руководителей и знаю о чем речь не понаслышке. Вот что я вынес для себя из этого интервью 1) Остин считает, что поведенческие интервью требуют тщательной подготовки, причем подготовка дает возможность стать лучшим инженером в будущем из-за глубокой рефлексии об опыте и достижениях в прошлых проектах. Мне кажется, что навыки рефлексии - это ключ к ежедневному росту над собой, но это обычно не слишком приятно, поэтому люди избегают таких размышлений, а подготовка к интервью помогает им найти силы для этого дела 2) Поведенческие интервью важных для высоких грейдов, как инженерных, так и менеджерских. Компании оценивают прошлые успехи и поведение и используют это как экстраполяцию будущих результатов кандидата 3) Поведенческие интервью варьируются в зависимости от грейда, в приведенном видео Остин приводит примеры таких различий 4) У компаний есть критерии для оценки кандидатов, например, инициативность, настойчивость, ... 5) Крупные компании стремятся уйти от субъективных решений, поэтому формализуют критерии оценки 6) Как и всегда первое впечатление очень важно, поэтому важно правильно начать интервью и не обосраться. Автор рекомендует подготовить ответы на вопросы, которые с большой вероятностью будут заданы в начале интервью: "Расскажи о себе", "Расскажи о своем любимом проекте". Ответы на эти вопросы позволят задать првильный тон всей встрече. 7) Часто для проведения интервью используют стандартные схемы, например, STAR (Situation - Tasks - Actions - Results) или CARL (Context - Actions - Results - Learning), причем Остину нравится CARL больше STAR за счет последнего пункта про извлеченные уроки, а также он рекомендует меньше тратить времени на рассказ о контексте и больше на само действие и результаты 8 ) Стандартизированный подход (STAR / CARL / ваш любимый) может мешать непринужденной беседе и выглядеть неестественно, это решается тренировкой интервьюеров Продолжение рассказа во втором посте. #Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

Кто получит «Мандат Неба»? Динамика «гонки вооружений» LLM одним слайдом. «Гонка вооружений» на рынке больших языковых моделей (LLM) определяется просто: все стараются получить максимально высокую точность при минимальной цене. А а «фронтир» отражает лучшие на данный момент варианты по сочетанию этих двух параметров. Диаграмма показывает [1], как разные версии языковых моделей (от OpenAI, Deepseek, Google «Gemini», Anthropic и др.) соотносятся по: • стоимости (ось X): цена за миллион токенов - чем правее точка, тем дешевле использование модели (ниже стоимость за миллион токенов). • качеству (ось Y): рейтинг LMSys Elo - чем выше точка, тем сильнее модель (лучшее качество ответов/результатов).

На диаграмме видны две основные "границы эффективности" (pareto frontier): 
•  Синяя линия от OpenAI, показывающая их модели
•  Оранжевая линия от Gemini 2, которая, судя по надписи, предлагает "лучше, дешевле, круче"
•  Более дорогие и мощные модели в верхней левой части (например, различные версии GPT-4) 
•  Средний сегмент в центре (Claude 3.5, Gemini 1.5) 
•  Более доступные модели в правой части (Amazon Nova Lite, Gemini 1.5 Flash)

Ключевые выводы (по состоянию на февраль 2025) • Чемпион в соотношении цена-производительность - Gemini 2.0 Flash Thinking (лучше, чем DeepSeek r1 (по ELO) и дешевле • Стоимость возможностей GPT-4 упала в 1000 раз за 18 месяцев • Скорость роста возможностей моделей просто немыслимая – так не бывает, … но так есть! PS Спецы из Google DeepMind полагают, что они близки к получению «Мандата Неба» ("Mandate of Heaven" (天命, Тяньмин)) [2]. Когда говорят, что компания имеет "Mandate of Heaven" в сфере ИИ, это означает, что она занимает лидирующую позицию не просто благодаря рыночной доле, но и благодаря признанию её технологического превосходства и инновационного лидерства. Но вряд ли конкуренты согласятся 😊 #ИИгонка

Я люблю читать канал "Малоизвестное интересное", так как там периодически, бывают очень интересные мысли. Они позволяют мне самому чуть шире взглянуть на происходящее на переднем краю технологических возможностей, а иногда этот взгляд не шире, но как будто под другим углом:) Конкретно в этом посте мне понравилась интересная визуализация и вообще график качество/стоимость для LLMs, а также фронтир возможностей OpenAI, DeepSeek и Gemini моделей.

[2/2] Squad Health Check и сравнение его с DORA Metrics, SPACE, DevEx (Рубрика #Management) Продолжая сравнение разных подходов к оценке эффективности команд, расскажу про оставшиеся параметры по которым их можно сравнивать. 3) Ограниченная масштабируемость и анализ трендов - SHC затрудняет агрегацию результатов по нескольким командам - частота опросов, список ответов и многое другое команды могут кастомизировать под себя. Это приводит к проблемам при отслеживании тенденций - DORA Metrics хорошо масштабируется между командами и предоставляет четкий анализ трендов для оценки производительности с течением времени. - SPACE разработан для анализа продуктивности как на уровне отдельных сотрудников, так и на уровне всей организации, что делает его масштабируемым и эффективным для анализа трендов. - DevEx предлагает структурированный подход к измерению опыта разработчиков в разных командах, что позволяет последовательно отслеживать улучшения в таких областях, как состояние потока и обратная связь. 4) Применимость полученных данных - SHC иногда приводит к выводам, что бывают слишком общими или расплывчатыми для того, чтобы их можно было напрямую преобразовать в конкретные действия. Обсуждения могут сосредотачиваться больше на симптомах, чем на их причинах. - DORA Metrics: Определяет конкретные област, например, MTTR (mean time to recover), которые можно улучшить с помощью целевых вмешательств, таких как оптимизация CI/CD. - SPACE предоставляет данные, связывая метрики с конкретными аспектами продуктивности (например, проблемы в коммуникации). Это позволяет легко понять как их использовать для оптимизации - DevEx сосредоточен на изменениях в инструментах и процессах разработчиков, которые напрямую повышают продуктивность и удовлетворенность. 5) Чрезмерный акцент на моральном духе - SHC сильно акцентирует внимание на моральном духе команды, удовольствии от работы и сотрудничестве, но может упускать из виду важные бизнес-результаты или техническую эффективность. - DORA Metrics отдает приоритет метрикам производительности разработки, которые влияют на эффективность разработки, а через нее на бизнес-результаты. - SPACE уравновешивает моральный дух с другими аспектами (например, эффективностью и потоком), обеспечивая учет как благополучия команды, так и бизнес-целей. - DevEx фокусируется на улучшении опыта разработчиков в целом при согласовании с организационными целями (например, ускорение вывода продукта на рынок). 6) Ресурсоемкость - SHC требует подготовки фасилитаторов для эффективного проведения обсуждений. Регулярное проведение оценки может быть трудоемким для команд под давлением сроков. - DORA Metrics позволяет автоматизировать сбор данных с CI/CD систем, что делает менее ресурсоемким использование системы после внедрения. - SPACE достаточно сложен из-за многомерной природы данных, которые надо подтянуть из внутренних систем компании, но после первоначального внедрения может работать без супер-больших вложений - DevEx cосредоточен на автоматизации рабочих процессов и улучшении инструментов разработки, находится где-то посередине между DORA и SPACE. В заключение можно сказать, что хотя Squad Health Check отлично подходит для обсуждения проблем внутри команды и улучшения межличностных отношений, он уступает DORA Metrics, SPACE Framework или DevEx Framework в объективности измерений, техническом фокусе, масштабируемости и применимости данных. Организации должны выбирать фреймворк исходя из своих целей — будь то улучшение морального духа команды или повышение технической эффективности. #Management #Devops #Management #Leadership #Processes #SRE #Software #Metrics #Productivity

[1/2] Squad Health Check и сравнение его с DORA Metrics, SPACE, DevEx (Рубрика #Management) Буквально на днях наткнулся на древний инструмент опросов от Spotify. Этот концепт был опубликован в далеком 2014 году, через пару лет после публикации знаменитой модели Spotify со всякими гильдиями, сквадами и другими забавными названиями. Эту модель придумал Henrik Kniberg и популяризировал красивыми мультиками и комиксами, что стали виральными. Несмотря на попытки прикрутить модель в лоб, это мало у кого получалось, а потом и создатели сказали, что сами отошли от нее и адаптировали свои процессы под новую реальность. Собствено, Squad Health Check появился больше 10 лет назад, но он до сих пор используется в Spotify. Если упрощать, то squad health check - это инструмент самооценки, разработанный для agile команд,. Он используется для оценки и улучшения динамики команды, производительности и общей эффективности путем отслеживания различных измерений здоровья команды с течением времени. Основными фичами этой системы являются 1) Traffic light system (светофорная система): члены команды оценивают различные измерения с помощью простых цветных индикаторов, что позволяет легко визуализировать общее состояние команды. 2) Dimensions evaluated (jцениваемые измерения): общие измерения включают доставку ценности, простоту выпуска, веселье, здоровье кодовой базы, моральный дух команды и сотрудничество. Их можно настраивать в соответствии с конкретными потребностями команды. 3) Open discussions (открытые обсуждения): результаты используются для содействия обсуждениям проблем и успехов, помогая командам определять области для улучшения и создавать выполнимые планы. 4) Historical tracking (историческое отслеживание): со временем команды могут отслеживать свой прогресс и определять тенденции или повторяющиеся проблемы. В общем, этот подход был хорош для 2014 года, но с тех пор успели появиться DORA (DevOps Research and Assesment) metrics (подробности в посте про книгу Accelerate), SPACE framework (подробности в посте) и DevEx (подробности в посте), которые шагнули сильно дальше. Если сравнить их между собой то получим примерно следующее (метод Squad health check я буду для краткости называть SHC) 1) Субъективность vs. Объективность. - SHC сильно зависит от субъективных самооценок участников команды. Это может привести к предвзятым или непоследовательным результатам, так как разные люди могут по-разному интерпретировать вопросы или не быть полностью честными. - DORA Metrics предоставляет объективные, количественные данные о параметрах разработки (например, deployment frequence или lead time). - SPACE: Сочетает субъективные и объективные данные, но благодаря своей структуре минимизирует предвзятость, объединяя такие метрики, как удовлетворенность, с измеримыми показателями производительности, которые можно получить через логи/метрики из систем (activity часть SPACE) - DevEx: Похожим на SPACE образом пытается сбалансировать субъективность и объективность. 2) Отсутствие фокуса на технических метриках - SHC делает акцент на моральном духе команды, сотрудничестве и процессах, но не уделяет внимания техническим метрикам, таким как частота развертываний или качество кода. - DORA Metrics сосредоточены на технических параметрах разработки, что делает его очень полезным для оптимизации DevOps/SRE практик - SPACE охватывает технические аспекты (например, эффективность и поток) наряду с благополучием команды, предоставляя более целостное представление о продуктивности. - DevEx прямо рассматривает технические препятствия (например, неэффективность инструментов), которые влияют на производительность и удовлетворенность разработчиков. Продолжение сравнения этих разных подходов в следующем посте. #Management #Devops #Management #Leadership #Processes #SRE #Software #Metrics #Productivity

[4/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering) Продолжая рассказ про эту крутую книгу, поднятый в постах 1 и 2 и 3, здесь я расскажу про четвертую и пятую часть книги под названием "Инструменты" и "Заключение". IV. Tools (инструменты) 16. Version control and branch management (Управление версиями и управление ветками) В этой главе авторы описывают, как Google использует управление версиями, а точнее свой монорепозиторий, для управления огромными объемами кода. Авторы объясняют стратегию управления ветками, которые обеспечивают непрерывную интеграцию и совместную разработку. По-факту, это версия TBD (trunk based development) 17. Code search (поиск кода) Глава сосредоточена на инструментарии, который делает навигацию по огромному кодовому базису эффективной. Она объясняет, как мощные возможности поиска имеют решающее значение для понимания и поддержки крупных систем 18. Build systems and build philosophy (Системы сборки и философия сборки) Авторы рассказывают про инфраструктуру сборки и практики, включая инкрементальные сборки и автоматизацию. Этот раздел детализирует, как системы сборки Google спроектированы для скорости и масштаба 19. Critique: Google’s code review tool (критика: инструмент обзора кода Google) Интересная глава про внутренний инструмент, используемый для облегчения обзора кода. Обсуждение охватывает его сильные и слабые стороны, а также влияние на рабочий процесс и эффективность разработчиков. 20. Static analysis (статический анализ) В этой глава объясняется, как автоматизированные инструменты анализируют исходный код для обнаружения ошибок или отклонений от стандартов до запуска кода. Этот активный подход является ключевым для поддержания качества кода в масштабе. 21. Dependency management (управление зависимостями) Эта глава рассказывает про методы обработки зависимостей в огромной кодовой базе. Предоставляет стратегии для минимизации конфликтов и поддержания целостности системы по мере эволюции кода. Подробнее про концепт можно почитать на сайте build системы Bazel 22. Large-scale changes (крупномасштабные изменения) В этой главе авторы обсуждают методы и инструменты для безопасного применения широкомасштабных изменений по тысячам файлов. Глава сосредоточена на планировании, автоматизации и минимизации рисков при обработке крупномасштабных изменений кода. Ясно, что такие возможности во многом основаны на использовании монорепы. 23. Continuous integration (непрерывная интеграция) Эта глава детализирует практики и инфраструктуру, которые позволяют интегрировать изменения в коде часто и надежно. Непрерывная интеграция показана как необходимая для раннего обнаружения проблем в процессе разработки. Если хочется описания попроще, то рекомендую книгу "Grokking Continuous Delivery" ("Грокаем continuous delivery") тоже от ребят из Google, про которую я уже рассказывал 24. Continuous delivery (непрерывная доставка) Здесь речь идет про конвейеры и автоматизацию, которые обеспечивают быструю и надежную развертывание изменений. Эта глава подчеркивает, как оптимизированные процессы доставки поддерживают постоянные инновации, сохраняя при этом стабильность. Книга "Grokking Continuous Delivery" тут тоже отлично подходит 25. Compute as a service (вычисления как сервис) Описывает, как Google использует масштабируемые вычислительные ресурсы для поддержки разработки, тестирования и развертывания. Объясняет, как эта «инфраструктура как сервис» лежит в основе многих инженерных практик Google. V. Заключение Здесь авторы подводят итоги и отмечают, что инженерия программного обеспечения — это непрерывный процесс, который сочетает культуру, хорошо определенные процессы и передовые инструменты. Также авторы размышляют о выученных уроках, подчеркивая, что хотя не все практики будут применимы к каждой организации, принципы адаптивности и устойчивого развития являются универсальными. #Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps

Обложки книг "Drive: The Surprising Truth About What Motivates Us" и "Драйв"

Драйв (Drive: The Surprising Truth About What Motivates Us) (Рубрика #Management) Недавно я прочитал эту классическую книгу Даниэля Пинка, которая была написана в конце 2000-х годов. В то время она звучала свежо и бросала вызов традиционным представлениям о мотивации, особенно подходу «кнут и пряник», основанному на вознаграждениях и наказаниях. Дэниель смешал фокус на внутренней мотивации, а не внешних стимулах. Автор хорошо вплетал в свое повествование результаты исследований ученых, таких как Дэниеля Канемана и его книгу "Thniking, Fast and Slow" (подробности в моем посте) или Дэна Ариели и его книгу "Predictably Irrational" (подробности в моем посте). По-факту, Дэниэль Пинк предлагает модель мотивации 3.0, которая основывается на трех столпах 1) Автономия: Желание контролировать свою работу и принимать собственные решения. Пинк подчеркивает, что автономия способствует вовлеченности и креативности, позволяя людям самостоятельно направлять свои усилия. 2) Мастерство: Стремление улучшать свои навыки и достигать совершенства в значимых задачах. Это требует постоянного обучения и упорства. 3) Цель: Необходимость вносить вклад во что-то большее, чем собственные интересы. Связь работы с более высокой миссией усиливает мотивацию и удовлетворение. Пинк противопоставляет эти внутренние мотиваторы внешним, таким как денежные вознаграждения, которые эффективны только для простых механических задач. Для сложной, творческой или когнитивной работы внешние стимулы могут даже снижать производительность, подавляя креативность и внутренний интерес. В итоге, по Пинку есть 3 модели мотивации 1) Мотивация 1.0 — выживание 2) Мотивация 2.0 — вознаграждения/наказания 3) Мотивация 3.0 - внутренняя мотивация на основе автономии, мастерства и цели Собственно, надо стремиться с мотивации 3.0, но для этого компании должны «платить достаточно, чтобы убрать деньги с повестки дня», чтобы сотрудники могли сосредоточиться на более значимых стимулах. Чем-то эти уровни мотивации напоминают пирамиду Маслоу Пинк выделяет два типа поведения у людей 1) Тип X - внешне мотивированные 2) Тип I - внутренне мотивированные. Поведение типа I более устойчиво, так как опирается на возобновляемые внутренние ресурсы, такие как страсть и любопытство. Книга Пинка написана очень просто и достаточно популярна, но к ней и ряд замечаний 1) Автор по кругу повторяет мысли про автономию, мастерство и цели без особых изменений и развития темы 2) Автор упоминает исследования, что поддерживают его мысли, но почти не упоминает исследования, которые могли бы опровергнуть его выводы, создавая впечатление предвзятости. 3) Некоторые рецензенты считают описание мотивации на рабочем месте слишком упрощенным. Например, Пинк предполагает, что развитие внутренней мотивации автоматически улучшит производительность, игнорируя такие факторы как обучение сотрудников или различия в индивидуальных целях. 4) Центральный аргумент о переходе к внутренней мотивации кажется некоторым критикам преувеличенным. Они отмечают важность внешних стимулов во многих рутинных или некреативных профессиях, которые Пинк практически не рассматривает. 5) Многие рецензенты указывают на то, что *Drive* лишь популяризирует уже существующие психологические теории (особенно теорию самодетерминации), не добавляя существенных новых идей. 6) Книга критикуется за недостаток конкретных шагов по внедрению идей в реальной практике. 7) Акцент на автономии как ключевом факторе мотивации может быть неактуален для всех культур. Критики отмечают ограниченную применимость модели Пинка в странах с более строгими рабочими структурами или другими культурными нормами. Рекомендую почитать на тему разнообразия культур книгу "The culture map" Итого, книга отлично популяризировала тему внутренней мотивации, но она достаточно поверхностна - с нее можно начать но для серьезного погружения в тему стоит почитать более фундаментальную литературу. #Psychology #Economics #Brain #SelfDevelopment

Иллюстрации из статьи "Cross-layer Enterprise Architecture Evaluation"

Cross-layer Enterprise Architecture Evaluation: An Approach to Improve the Evaluation of TO-BE Enterprise Architecture (Рубрика #Architecture) Продолжая изучать статьи по архитектуре, я наткнулся на статью про подходы к оценке целевого состояние корпоративной архитектуры. Статья уже довольно старенькая, но ключевые слова, что интересовали меня в ней оказались. Если обобщать эту статью, то авторы фокусируются на процессе оценки, но описывают и процессы EA (enterprise architecture) в общем, а также показывают как процесс evaluation выглядит в разных подходах, а потом предлагают свой:) Все конечно выглядит супер-бюрократично и мало применимо, но знать про эти концепции может быть полезно Ребята описывают процесс EA в общем 1) Infortmation technology strategic planning - фактически это стратегическая часть для создания vision в плане развития IT для поддержания миссии и стратегии всей компании 2) Enterprise architecture planning - это часть с планированием корпоративной архитектуры, что состоит из построения версии AS-IS, построения целевой версии TO-BE, а такжее создания плана для преодоления разрыва между этими состояними 3) Enterprise architecture execution - эта часть корпоративных архитекторов обычно уже не интересует, так как с их стороны "пули вылетели" Процесс оценки архитектуры появляется на втором шаге и важен он тем, чтобы убедиться, что в целевой архитектуре учтены все quality attributes (атрибуты качества). Но все усложняется тем, что в корпоративной архитектуре ребята любят слои и предлагают размышлять отдельно про stgrategy, business, information, application, technology. А предыдущие подходы к оценке целевой корпоративной архитектуры хоть и предлагали некоторые атрибуты качества и способы их измерения делали это не консистентно. Это как в Простоквашино: почему Печкин злой был - у него велосипеда не было. А тут не было консистентного подхода к оценке, но авторы этого исследования предлагают свой процесс. Надо критерии оценивать сквозь все уровни и по следующей методологии 1) Recognition phase - здесь предполагается, что quality attributes уже известны в компании, поэтому надо просто подобрать для них критерии оценки, изучая стандарты, референс модели и документацию. Важно сделать это по всем уровням, упомянутым выше 2) Analysis phase - для каждого из критериев, определенных на предудущем этапе, надо определить метрики для измерения 3) Mapping phase - здесь надо сделать маппинг артефакты из EA на индикаторы для измерения quality attributes. Если артефактов нет для оценки какого-то из атрибутов качества, то надо запустить процесс его создания (звучит бюрократически) Вот такие бенефиты авторы выделяют в своем подходе

- This approach improves the comprehensiveness and integrity of the evaluation by considering the details of all EA layers. - This approach allows us to examine and determine the maturity level of each layer of the EA. Therefore, the evaluation of EA plans with different scopes is possible by this approach. - This approach can improve the EA plan by applying all criteria, metrics and corresponding indicators defined in the process of evaluation the EA plan. - This approach simplifies tracing of EA imperfections.

В конце статьи авторы приводят натужный пример со сквозным оцениванием атрибутов качества в домене безопасности, но он выглядит игрушечным. #Whitepaper #Architecture #EA #Software #Engineering #SystemDesign #Engineering

The Engineering Unlocks Behind DeepSeek | YC Decoded (Рубрика #AI) Интересный 13 минутный разбор DeepSeek R1 от ребят из Y Combinator, который фокусируется не на хайпе, а на инженерных вещах. Основные моменты разбора такие 1) Deepseek анонсировала логическую модель R1, которая обеспечивает сопоставимую производительность с OpenAIo1 при меньших затратах. 2) Это вызвало панику в социальных сетях и снижение рыночной капитализации Nvidia на 600 миллиардов долларов. 3) Но DeepSeek - это не новый игрок на рынке. Они публикуют результаты своих исследований и модели весов, в отличие от других крупных лабораторий, таких как OpenAI и Google DeepMind. И многие результаты уже были опубликованы ранее, например, они оптимизировали обучение в fp8 и исправление накопления ошибки 4) Важно различать модели DeepSeek-R1 и DeepSeek-V3 - DeepSeek V3 обеспечивает производительность, сопоставимую с GPT-4 и другими базовыми моделями. • R1 является reasoning моделью, построенной на основе V3, и достигает производительности, сравнимой с OpenAI o1 и Google Gemini Flash 20. 5) В V3 они использовали архитектуру, что активирует только 37 миллиардов параметров для каждого предсказания, что экономит массу вычислений, а также использовали технологии multi-head latent attention (mla) для уменьшения объема памяти и увеличения пропускной способности. 6 ) Для R1 они придумали интересную схему обучения с подкреплением (reinforcement learning) 7) Часть хайпа вокруг R1 была свзяана с доступностью модели через веб-сайт и приложение Deepseek. Сама модель предлагала сравнимую производительность за небольшую часть стоимости других моделей. 8 ) Большая часть шумихи связана с ошибочными представлениями о стоимости обучения, сумма была указана для финального обучения модели без 9) Методы DeepSeek можно воспроизвести для создания своих моделей, например, Лаборатория Калифорнийского университета в Беркли применила эти методы для создания небольших reasoning моделей всего за 30 долларов. 10) Так как это видео от Y Combinator, то они заканчивают идеей о том, что на переднем краю развития AI есть место для новых игроков, которые могут подвинуть старожилов за счет оптимизации рабочих нагрузок GPU, улучшения софта и так далее. А все это приводит к уменьшению стоимости внедрения AI в конечные продукты, что делает текущий момен подходящим временем для создания стартапа. #AI #Engineering #Software #ML #Architecture

Measuring developer productivity: A clear-eyed view (Рубрика #Management) Интересная интервью на тему developer productivity, которое брал Кент Бек у Аби Нода,. Оба джентельмена - уважаемые люди в среде разработчиков - Кент Бек - автор XP (extrem programming), подписант Agile Manifesto, адепт TDD (test driven development). Недавно я рассказывал про его интересное выступление "Tidy First", а до этого делал подробный разбор этой свежей книги "TIdy First" Аби Нода - cооснователь и генеральный директор DX - платформы аналитики для оценки и улучшения продуктивности и опыта разработчиков. Также Аби - соавтор исследований про Developer Experience, про которые я рассказывал раньше: "DevEx: What Actually Drives Productivity" и "DevEx in Action" Инетереса этому интервью придавало то, что Кент Бек всегда выступал последовательным критиком метрик вокруг developer productivity, а Аби Нода строит на этом свой бизнес. И вот, что они обсудили 1) Goodhart’s Law (Закон Гудхарта) В интервью подчеркивается, что когда метрика становится целью, она теряет свою эффективность — это основная идея закона Гудхарта. Это приводит к тому, что чрезмерная зависимость от одной числовой метрики может привести к искажению стимулов, из-за чего команды будут стремиться «обойти систему», а не реально улучшать качество работы. Аби Нода про это знает, поэтому у него целая четверка метрик, что балансируют друг друга: speed, effectiveness, quality, impact. Отдельно Аби отмечает три важных момента при внедрении системы измерения developer productivity

- Communicating and following through on being an ally to developers - Never measuring metrics like diffs per engineer at the individual level - that's something we stipulate in our framework and build into our product - Using it within this basket of metrics - developer experience is as important as speed, and quality balances both

2) Developer experience (опыт разработчиков) Основное внимание уделяется созданию поддерживающей и комфортной среды для разработчиков. Вместо того чтобы просто измерять результаты, акцент делается на предоставлении разработчикам необходимых инструментов, процессов и культуры для их успеха, что в итоге повышает продуктивность и качество работы. 3) Using benchmarks (использование бенчмарков) Аби Нода предлагает использовать отраслевые или внутренние бенчмарки как ориентир для понимания того, где находится команда относительно лучших практик. Однако подчеркивается, что бенчмарки следует адаптировать к уникальному контексту команды, так как различия в типе проектов, составе команды и рабочей культуре требуют гибкого подхода. Это очень важные ремарки относительно бенчмаркинга - если сравнивать теплое с мягким, то получить осмысленные результаты не получиться 4) Implementing metrics (реализация метрик) При проектировании и внедрении метрик продуктивности акцент делается на сбалансированном подходе, который избегает узкой фокусировки только на количественных результатах. Лучшие практики включают определение метрик, которые эмпирически обоснованы, и использование их как ориентиров для постоянного улучшения, а не как самоцели. Общая рекомендация — применять рефлексивный и итеративный процесс разработки метрик с учетом обратной связи от разработчиков и руководства. В общем, получилось как по мне, отличное интервью, где Кент и Аби прошлись по ключевым болевым точкам измерения продуктивности и остались при своих, сойдясь на том, что Аби со своей платформой делает нормальные вещи, а также со скепсисом Кента относительно неправильного использования метрик большинством на рынке разработки софта. P.S. Я подписан на рассылку от платформы Аби Нода GetDX, где попадаются хорошие материалы на тему продуктивности инженеров. Рекомендую. #Productivity #Engineering #Metrics #DevOps #DevEx #Software

Обложки для книг "The Creative Programmer" и "Креативный программист", а также внутренняя сторона обложки со схемой креативности от автора

The Creative Programmer (Креативный программист) (Рубрика #SelfDevelopment) Недавно я прочитал эту книгу Ваутера Гренефелда про креативнрость в программировании. Суть в том, что Ваутер рассматривает разработку как творческую деятельность, сравнимую с созданием музыки, а не просто технический процесс. Мало того, автор утверждает, что креативность можно развивать и даже дает практические советы о том, как это делать. Книга в оригинале вышла в издательстве Manning, а на русский переведена издательством "Питер". Читал я на русском и особых проблем не заметил. Если возращаться к самой книге, то автор выделяет следующие столпы креативности - Technical knowledge (технические знания): без hard skills в инженерии никуда - сложно быть креативным без знания технической базы. Я уже как-то рассказывал про путь в сторону staff engineer и как прокачивать харды для становления крутым IC (individual contributor) - Collaboration (сотрудничество): это то, что обычно называют soft skills, а точнее тут про эффективное общение в команде и обмен идеями. Недавно у меня был доклад как раз на эту тему - Constraints (ограничения): часто именно наличие ограничений стимулирует инновации для их преодолениея - Critical thinking (критическое мышление): сомнение в предположениях и улучшение решений. У меня есть целая подборка ресурсов про критическое мышление - Curiosity (любознательность): стремление к постоянному обучению и разнообразным интересам - Creative state of mind (творческое состояние ума): развитие концентрации и внутренней мотивации - Creative techniques (творческие техники): методы, такие как использование метафор и мозговой штурм Если обобщать основные мысли, то - Креативность возникает из соединения идей из разных дисциплин, что автор иллюстрирует историческими примерами - Автор поощряет "хорошее воровство" идей (адаптация концепций) в противовес простому подражанию - Ваутер говорит про баланс между внутренней мотивацией (например, любопытством) и внешними факторами (например, сроками) - это по его мнению повышает продуктивность В последней главе есть много креативных практик из инструментария писателя, художника и инженра. Поэтому желающий повысить свою креативность может взять эти инструменты и начать их практиковать. А для отслеживания прогресса можно взять Creative Programming Problem Solving Test, позволяющий отслеживать и измерять прогресс в развитии креативности. P.S. Вопросы креативности в software engineering очень важны, например, ребята из Google исследовали их и недавно написали интересный whitepaper "Developer Productivity for Humans, Part 8: Creativity in Software Engineering", который я уже разбирал раньше. #Thinking #Engineering #SelfDevelopment #Software #Brain

Residuality Theory, random simulation, and attractor networks (Рубрика #Architecture) Недавно прочитал этот whitepaper Barry O'Reilly, который он написал еще в 2022 году. Я решил изучить этот whitepaper после двух выступлений автора, о которых я уже рассказывал ранее 1) An Introduction to Residuality Theory 2) The Philosophy of Architecture Мне показались его выступления на тему его resudiality theory интересными и я прочитал paper, про который хочу рассказать кратко ниже 1) Барри придумал новый подход к архитектуре софта, который фокусируется на создании систем, способных адаптироваться к непредвиденным вызовам и сложностям. 2) Предыдущие подходы в основном основывались на requirements management и risk management, которые должны были конвертировать неизвестные неизвестные во что-то более управляемое, но конечно не могли это сделать 3) Подход автора включает в себя random simulation как ключевой компонент для выявления и решения потенциальных проблем заранее. 4) Random simulation включает в себя моделирование различных случайных стрессоров для наблюдения за паттернами и прогнозирования потенциальных "residues" или новых состояний, возникающих из этих стрессоров (метод Монте-Карло) 5) Анализ стрессоров выглядит примерно так: инженеры выявляют и анализируют случайные стрессоры, с которыми софт может столкнуться в предполагаемой среде. Это помогает в проектировании систем, способных справляться с неожиданными событиями или ситуациями. 6) Под влиянием различных стрессоров система стремится к устойчивым состояниям, аттракторам. Выявление этих аттракторов помогает понять, как система будет вести себя в различных условиях. 7) Гиперлиминальность описывает как упорядоченная система (софт) живет внутри неупорядоченной (бизнес-среда). Эта концепция включает в себя понимание перехода от текущего состояния к новому состоянию (residue) из-за стрессора. Одновременно, автор определяет hyperliminality coupling так

If two nodes in a network each have a relationship with a third node, then those two nodes are very likely to have a relationship. Therefore, if a stressor in the wider hyperliminal system interacts with two software components, then those two components can be considered coupled.

😍 Если кратко описывать основные утверждения теории автора, то они выглядят так

1. Enterprise software systems are ordered systems that live in disordered environments - hyperliminal systems. 2. These systems will experience stress that they have not been designed for because the disorderedenvironment is by definition unpredictable. 3. The system’s future is a function of residue, whatever is left over after it is stressed.

9) Архитектуру Барри описывает, используя Boolean Networks (Kauffman Networks), где есть три параметра NKP (N - количество нод, K - наибольшее количество связей ноды в сети, P - bias в сторону конкретного результата при обработке сигнала). Барри матчит это на архитектуру софта так - N - относится к программным компонентам - K - описывает связи или вызовы между компонентами - P - увеличивается при использовании контрактов, схем, политик или уменьшении сложности кода (количества ветвлений в нем) Собственно, эти параметры определяют какие аттракторы будут в сети и сколько их будет. Для описания всего это добра нужны adjacency matrices для маппинга компонентов одного типа между собой, а также incidence matrices, где описывается маппинг стрессоров на компоненты 9) Процесс использования подхода выглядит так - Сначала надо спроектировать наивную архитектуру и провести random simulation для нее - Дальше надо использовать incidence matrices для отображения стрессоров относительно residues, процессов, потоков и компонентов программного обеспечения. - Стоит разделять стрессоров на обучающие и тестовые наборы для валидации процесса проектирования и расчета индекса остаточности (Ri). В общем, residuality theory направлена на создание более устойчивого софта путем предвидения и решения будущих проблем в дополнение к учету функциональных требований. #Architecture #Software #SystemDesign #Engineering #DistributedSystems

AI Trends for 2025 (Рубрика #AI) Недавно глянул это семиминутное видео от Martin Keen, IBM Fellow, который за много лет в IBM проявил себя как изобретатель (больше 400 патентов), технический руководитель, исследователь в AI, а также создатель контента на канале IBM Technology. В этом коротком видео он рассказывает о своем видении трендов в AI на 2025 год. Ксатати, в прошлом году он тоже делал такое видео на 2024 год, поэтому можно пойти и сравнить насколько его прогнозы попали в точку. Но давайте вернемся к прогнозам на этот год. 1) Agentic AI - это важный тренд на создание многошаговых планов и их исполнения с использованием доступных инструментов. Правда, пока современные модели испытывают трудности с логическим мышлением и выполнением сложных планов 2) Inference time compute - модели уже используют больше времени во врем inference, улучшая логический вывод. Это позволяет настраивать и улучшать систему без необходимости обучать/тюнить базовую модель. 3) Very large models - в этом году мы предположительно пробьем 1 трлн параметров в foundational models 4) Very small models - будут активно развиваться модели меньшего размера, которые могут работать на ноутбуках и телефонах. 5) More advanced use cases - ИИ улучшит качество обслуживания клиентов, IT operations и автоматизацию. 6) Near infinite memory - Современные модели ИИ имеют контекстные окна в миллионы токенов. Дальше будет больше и, например, условные чат-боты смогут сохранять и использовать всю доступную информацию по пользователю. 7) Human in the loop augmentation - Чат-боты могут превосходить врачей в диагностике, но в паре с экспертами они могут быть эффективнее. Для этого нужны более совершенные системы для интеграции ИИ в рабочие процессы. Мы, например, активно интегрируем свой Nestor во все процессы вокруг SDLC (software development lifecycle) для повышения продуктивности инженеров #AI #ML #Trends #Software #Engineering

Data завтрак в Т-Банке в начале января 2025 года (Рубрика #Data) Наконец-то я смог посмотреть доклады с data-завтрака, что был почти месяц назад. На нем выступл Дима Аношин, автор канала "Инжиниринг данных" (@rockyourdata), а также Валера Поляков, наш директор по данным. Я немного поучаствовал в организации мероприятия, но посетить не смог из-за того, что летел домой из Шри-Ланки. А темы были интересные: - Дима рассказывал о том, как выглядят data проекты в западных компаниях и на каких технологиях они строятся, благо у Димы есть опыт работы в Amazon, Microsoft и целом ряде компаний поменьше - Валера рассказывал про эволюцию подходов Т-Банка к работе с данными с начала времен и до текущего момента. Ну давайте я кратенько расскажу про каждый из докладов 1) Современные облачные решения для аналитики и их значимость для бизнеса от Димы Аношина - Начал Дима с рассказа о значении аналитики для увеличения прибыли и снижения затрат. - Дальше он рассказал о концептуальных аналитических решениях, которые базово состоят из источников, систем хранения и обработки данных. - Дима поделился 11 реальными проектами, в которых он участвовал за последние десять лет. По этим проектам было наглядно видны тренды - переход от on-prem в cloud, переход от all-in-one в separate storage и compute, восход облачных аналитических решений snowflake и databricks, оформление роли data engineer как людей, что делают инфру под dataops 2) История платформы данных в Т: от SAS до PaaS от Валеры Полякова История развития инфраструктуры данных с 2007 года. - Эпоха SAS (2007 - 2011): Работа с проприетарными инструментами SAS до перехода на Greenplum. - Эпоха Greenplum (2012 - 2016): Переход на MPP базы данных, выбор Greenplum, масштабирование инфраструктуры. Тут еще был поворот не туда с SAP BO в 2014 году:) - Эпоха роста сложности (2017 - 2021): Здесь компания активно росла и предел масштабирования для одного кластера Greenplum был достигнут. Дальше рост через был внедрение мультикластерности и собственных решений для репликации данных. Это привело к стремительному росту нагрузки и сложностей с управлением данными. - Эпоха изменений (2022 - 2026): Эпоха изменений, что принесла современные подходы -- Демократизация инженеринга данных и платформизация. -- Переход к облачной нативности платформы данных с использованием мультитенантной архитектуры. -- Внедрение концепции "данные как продукт" с акцентом на метрики качества. - Изменения несут за собой новые вызовы, с которыми мы работаем прямо сейчас -- Вопросы стандартизации данных между доменами. -- Важность централизованных практик для методологии работы с данными. -- Баланс между тактическими задачами и стратегическим развитием. В общем и целом, data-завтрак по моему мнению получился отличным, доклады плотными - надеюсь, что это превратится в традицию и мои коллеги из платформы данных еще не раз будут радовать нас интересными и полезными мероприятиями. P.S. В конце прошлого года я рассказывал доклад про эволюцию архитектуры в Т, который очень похож по структуре и логике повествования на Валерин доклад. В итоге, я ловил моментами дежавю, когда слушал этот доклад про эволюцию платформы данных:) #Engineering #Data #Architecture #Storytelling

The Rise of Vertical AI in Accounting (Рубрика AI) Прочитал на выходных интересную статью про AI в бухгалтерском учете из рассылки a16z Fintech от фонда AnderssenHorowitz. Вообще, Andreessen Horowitz (чаще известный как a16z) - это ведущая венчурная компания из Кремниевой долины, основанная в 2009 году Марком Андриссеном и Беном Хоровицем. С объемом капитала в $45 миллиардов (по состоянию на начало 2025 года), фирма инвестирует на разных этапах и в различных отраслях, включая технологии, ИИ, здравоохранение, криптовалюты и финтех, делая ставку на смелых предпринимателей и прорывные инновации. Известная своей активной поддержкой портфельных компаний, a16z инвестировала в такие трансформационные проекты, как Airbnb, Lyft и Slack, а также стала пионером в таких новых секторах, как Web3 и искусственный интеллект. Кстати, у ребят есть интересная подборка больших идей на 2025 год, которую интересно почитать для расширения сознания. Если же возвращаться к самой статье, то она посвящена растущей роли вертикального AI в бухгалтерском учете, особенно в решении задач, связанных с услугами клиентского консалтинга (Client Advisory Services, CAS). Суть вертикальности в том, что бухгалтерский учет отличается по областям (авторы приводят в пример строительство и медицину), а это приводит к тому, что универсальный подход (горизонтальный) может проигрывать вертикальному, когда есть фокус на конкретный домен. Вообще, на западе услуги клиентского консалтинга (CAS) являются драйвером роста для компаний благодаря следующим стратегическим преимуществам: - CAS формируют устойчивые отношения с клиентами, открывая возможности для перекрестных продаж. - Доходы CAS растут на 30% ежегодно по сравнению с 9% в среднем по отрасли. - CAS обеспечивает предсказуемый и менее сезонный поток доходов по сравнению с традиционными налоговыми и аудиторскими услугами. Но масштабирование CAS требует значительных трудозатрат на повторяющиеся задачи, такие как закрытие месяца, сверка транзакций и управление расходами. Эти задачи часто выполняются вручную младшими бухгалтерами или офшорными сотрудниками, но сейчас у многих есть желание автоматизировать это при помощи AI - ИИ может значительно сократить время на выполнение рутинных задач с часов до минут за счет автоматизации сбора данных, их обработки и сверки. - Однако для этого требуются высокоточные модели ИИ, способные работать с разнообразными источниками данных и учитывать особенности рабочих процессов в различных отраслях. Дальше авторы сравнивают вертикальный и горизонтальный подход, одновременно нативно встраивая рекламу Adaptive, компанию из их портфеля, что вертикально AI-фицирует бухгалтерию для строительных фирм. Забавно, что в компаниях с собственными ресурсами для внедрения AI получается комбинация в виде вертикальной проработки конкретных доменов, а также создание AI-платформы для подготовки и сервинга ассистентов. Примерно так существует вселенная ассистентов в Т-Банке. #AI #ML #Software #VC

[3/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering) Продолжая рассказ про эту крутую книгу, поднятый в постах 1 и 2, здесь я расскажу про третью часть книги под названием "Процессы". III. Processes (Процессы) 8. Style guides and rules (руководства по стилю и правила) Здесь авторы объясняют необходимость стандартизированных стилей кодирования и правил. Консистентность во всех кодовых базах снижает трение (friction), облегчает поддержку и позволяет автоматизированным инструментам помогать обеспечивать соблюдение этих стандартов. Забавно, что в части языках эти правила зафиксированы на уровне языка, например, в Go 9. Code review (обзор кода) Здесь авторы излагают подход Google к code review как ключевому процессу для поддержания качества. Они описывают лучшие практики, преимущества (такие как обмен знаниями и раннее обнаружение ошибок) и то, как систематические обзоры поддерживают масштабируемую разработку. 10. Documentation (документация) Эта глава сосредоточена на создании ясной, поддерживаемой и доступной документации. Авторы подчеркивают, как правильная документация помогает обеспечить долгосрочную жизнеспособность кода и облегчает процесс онбординга и сотрудничества. 11. Testing overview (обзор тестирования) Авторы представляют общую философию тестирования в Google. Эта глава объясняет, как тесты являются важными для обнаружения проблем на ранней стадии, обеспечения надежности кода и возможности быстрых циклов разработки. 12. Unit testing (юнит-тестирование) Авторы рассказывают про детали тестирования отдельных компонентов. Они подчеркивают важность хорошо написанных, быстрых юнит-тестов для проверки того, что небольшие части кода работают правильно. Забавно, что в некоторых компаниях инженеры не видят смысла в юнит тестах, так как они находят не все ошибки. Но unit tests - это не просто про поиск багов, это про написание кода, который является тестируемым. И уже эта цель приводит нас к хорошей декомпозиции кода на части, а также использованию композиционных подходов, которые позволяют заменить реализацию большинства компонентов во время тестирования. 13. Test doubles (тестовые дубликаты) В этой главе обсуждаются стратегии применения дублей, таких как моки, стабы и фейки, которые используются для имитации частей системы в изоляции. Это гарантирует, что юнит-тесты остаются локальными и могут запускаться без зависимости от внешних компонентов. 14. Larger testing (более крупное тестирование) В этой главе авторы выходят за пределы юнит тестов и рассказывают про интеграционные, системные и end2end тесты. Они объясняют, как эти более широкие тесты проверяют, что несколько компонентов работают правильно вместе. 15. Deprecation (устаревание) Авторы предлагают рекомендации по выводу из эксплуатации старого или устаревшего кода. Они подчеркивают управление жизненным циклом функций и кодовых путей для поддержания стабильности, позволяя при этом эволюционировать и совершенствоваться. Окончание будет в последнем посте из этой серии. #Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps

Research on Enterprise Business Architecture Design Method Based on Domain-Driven Design (Рубрика #Architecture) Я продолжаю читать и делиться рассказами о whitepapers на тему архитектуры и сегодня речь про статью от ученых Huiwen Deng и Yan Zhao из China Aerospace Academy of Systems Science and Engineering, что в Пекине. В этой статье ребята решили объединить подходы из enterprise architecture с практиками DDD (Domain Driven Design) в попытке сблизить корпоративную архитектуру с IT архитектурой, чтобы это ни означало. Ну и все конечно во благо цифровой трансформации:) Для определения бизнес архитектуры авторы вспоминают определение OMG (Object Management Group) из TOGAF (The Open Group Architecture Framework)

The formal blueprint outlining the enterprise’s governance structure, business capabilities, value streams; it clearly defines the enterprise’s governance structure along with its business capabilities, processes, and data

Дальше авторы говорят, что именно она является основой цифровой трансформации и связывает стратегию корпорации с процессами и IT-системами. По факту, она служит неким "каркасом" для построения цифровых предприятий. Дальше авторы рассказывают базу про DDD, а точнее, что - DDD помогает моделировать сложные бизнес-процессы через глубокое понимание домена. - Для этого используются стратегические подходы: subdomains, bounded contexts По мнению авторов DDD дополняет традиционные методы бизнес-архитектуры более детализированным подходом к сложным процессам. Авторы предлагают использовать метамодель, объединяющую стратегии, домены, данные и IT-сервисы. Авторы упоминают 7 моделей в своем подходе: strategy model, organization model, process model, domain model, capability model, data model, IT service model. Первые три модели из этого списка авторы пробегают галопом по Европам, а вот последние четыре разбирают подробнее 1) Domain model: модель состоит из стратегии домена, где определяются сабдомены, доменные объекты и доменные события. Про это подробнее рекомендую почитать книгу Влада Хононова "Learning DDD", про которую я уже рассказывал. 2) Capability model: здесь авторы говорят про базовые возможности и точки расширения, дизайн capability components, а также про solution design. Условно, надо определиться с базовыми компонентами и способами их расширения, а дальше из этих базовых компонентов собирать те решения, которые требуются бизнесу 3) Data model: здесь авторы говорят про модель данных и делают отсылки к классическим подходам ETL/ELT и DWH с data lake. Интересно, что авторы похоже не слышали пока про федерализацию данных и data mesh. 4) IT service model: здесь авторы говорят про state, structure и port. Условно у нас есть изменяемое состояние, сервисы и их взаимосвязи, а также входные и выходные точки. Основной подхода авторов должны являться доменные объекты, что связывают бизнес и IT. Для определения логических границ IT-систем авторы предлагают использовать DDD и определять bounded context, используя single responsibility principle. А с точки зрения бизнес архитектуры выделение общих возможностей помогает бороться с дублями и избыточностью систем. В общем и целом, мне этот whitepaper дался не легко - я легко читал части про DDD, а вот части про enterprise architecture рассыпались на части - у меня было ощущение, что все слова по отдельности я понимаю, но вот смысла в них общего не слишком много, примерно как в старом видео про "Фирму, которая занимается ничем". Возможно, это просто мое предвзятое отношение к бюрократическим и бумажным процессам, что любят ребята из The Open Group, что и придумали TOGAF, который как мне кажется не подходит технологическим компаниям:) #Architecture #Software #DDD #SystemDesign #Whitepaper #Engineering