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
2) Developer experience (опыт разработчиков)
Основное внимание уделяется созданию поддерживающей и комфортной среды для разработчиков. Вместо того чтобы просто измерять результаты, акцент делается на предоставлении разработчикам необходимых инструментов, процессов и культуры для их успеха, что в итоге повышает продуктивность и качество работы.
3) Using benchmarks (использование бенчмарков)
Аби Нода предлагает использовать отраслевые или внутренние бенчмарки как ориентир для понимания того, где находится команда относительно лучших практик. Однако подчеркивается, что бенчмарки следует адаптировать к уникальному контексту команды, так как различия в типе проектов, составе команды и рабочей культуре требуют гибкого подхода. Это очень важные ремарки относительно бенчмаркинга - если сравнивать теплое с мягким, то получить осмысленные результаты не получиться
4) Implementing metrics (реализация метрик)
При проектировании и внедрении метрик продуктивности акцент делается на сбалансированном подходе, который избегает узкой фокусировки только на количественных результатах. Лучшие практики включают определение метрик, которые эмпирически обоснованы, и использование их как ориентиров для постоянного улучшения, а не как самоцели. Общая рекомендация — применять рефлексивный и итеративный процесс разработки метрик с учетом обратной связи от разработчиков и руководства.
В общем, получилось как по мне, отличное интервью, где Кент и Аби прошлись по ключевым болевым точкам измерения продуктивности и остались при своих, сойдясь на том, что Аби со своей платформой делает нормальные вещи, а также со скепсисом Кента относительно неправильного использования метрик большинством на рынке разработки софта.
P.S.
Я подписан на рассылку от платформы Аби Нода GetDX, где попадаются хорошие материалы на тему продуктивности инженеров. Рекомендую.
#Productivity #Engineering #Metrics #DevOps #DevEx #Software
Интересная интервью на тему 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
Getdx
Measuring developer productivity: A clear-eyed view
Kent Beck grilled me on Goodhart’s law, benchmarks, and the purpose of measurement.
👍6❤4🔥1
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
Интересный 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
YouTube
The Engineering Unlocks Behind DeepSeek | YC Decoded
Chinese AI company DeepSeek recently made waves when it announced R1, an open-source reasoning model that it claimed achieved comparable performance to OpenAI’s o1, at a fraction of the cost. But for those following AI developments closely, DeepSeek and R1…
👍12❤6🔥2
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. Если артефактов нет для оценки какого-то из атрибутов качества, то надо запустить процесс его создания (звучит бюрократически)
Вот такие бенефиты авторы выделяют в своем подходе
В конце статьи авторы приводят натужный пример со сквозным оцениванием атрибутов качества в домене безопасности, но он выглядит игрушечным.
#Whitepaper #Architecture #EA #Software #Engineering #SystemDesign #Engineering
Продолжая изучать статьи по архитектуре, я наткнулся на статью про подходы к оценке целевого состояние корпоративной архитектуры. Статья уже довольно старенькая, но ключевые слова, что интересовали меня в ней оказались. Если обобщать эту статью, то авторы фокусируются на процессе оценки, но описывают и процессы 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
ACM Other conferences
Cross-layer Enterprise Architecture Evaluation | Proceedings of the International Conference on Omni-Layer Intelligent Systems
👍4❤3🔥1
Иллюстрации из статьи "Cross-layer Enterprise Architecture Evaluation"
❤6👍2🔥2
Драйв (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
Недавно я прочитал эту классическую книгу Даниэля Пинка (обложки в отдельном посте), которая была написана в конце 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
Telegram
Книжный куб
Обложки книг "Drive: The Surprising Truth About What Motivates Us" и "Драйв"
👍9❤5🔥1
Обложки книг "Drive: The Surprising Truth About What Motivates Us" и "Драйв"
🔥6👍2❤1
[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
Продолжая рассказ про эту крутую книгу, поднятый в постах 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
Telegram
Книжный куб
[1/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering)
Я читаю и перечитываю эту крутую книгу уже примерно пару лет, как раз с того момента, как она мне доехала с Amazon в 2022 году. Я никогда…
Я читаю и перечитываю эту крутую книгу уже примерно пару лет, как раз с того момента, как она мне доехала с Amazon в 2022 году. Я никогда…
❤4👍4🔥1
[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
Буквально на днях наткнулся на древний инструмент опросов от 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❤🔥3🔥3❤1🥰1
[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
Продолжая сравнение разных подходов к оценке эффективности команд, расскажу про оставшиеся параметры по которым их можно сравнивать.
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
Telegram
Книжный куб
[1/2] Squad Health Check и сравнение его с DORA Metrics, SPACE, DevEx (Рубрика #Management)
Буквально на днях наткнулся на древний инструмент опросов от Spotify. Этот концепт был опубликован в далеком 2014 году, через пару лет после публикации знаменитой…
Буквально на днях наткнулся на древний инструмент опросов от Spotify. Этот концепт был опубликован в далеком 2014 году, через пару лет после публикации знаменитой…
👍3❤2🔥2
Я люблю читать канал "Малоизвестное интересное", так как там периодически, бывают очень интересные мысли. Они позволяют мне самому чуть шире взглянуть на происходящее на переднем краю технологических возможностей, а иногда этот взгляд не шире, но как будто под другим углом:) Конкретно в этом посте мне понравилась интересная визуализация и вообще график качество/стоимость для LLMs, а также фронтир возможностей OpenAI, DeepSeek и Gemini моделей.
👍3🔥2💯1
Forwarded from Малоизвестное интересное
Кто получит «Мандат Неба»?
Динамика «гонки вооружений» LLM одним слайдом.
«Гонка вооружений» на рынке больших языковых моделей (LLM) определяется просто: все стараются получить максимально высокую точность при минимальной цене. А а «фронтир» отражает лучшие на данный момент варианты по сочетанию этих двух параметров.
Диаграмма показывает [1], как разные версии языковых моделей (от OpenAI, Deepseek, Google «Gemini», Anthropic и др.) соотносятся по:
• стоимости (ось X): цена за миллион токенов - чем правее точка, тем дешевле использование модели (ниже стоимость за миллион токенов).
• качеству (ось Y): рейтинг LMSys Elo - чем выше точка, тем сильнее модель (лучшее качество ответов/результатов).
Ключевые выводы (по состоянию на февраль 2025)
• Чемпион в соотношении цена-производительность - Gemini 2.0 Flash Thinking (лучше, чем DeepSeek r1 (по ELO) и дешевле
• Стоимость возможностей GPT-4 упала в 1000 раз за 18 месяцев
• Скорость роста возможностей моделей просто немыслимая – так не бывает, … но так есть!
PS Спецы из Google DeepMind полагают, что они близки к получению «Мандата Неба» ("Mandate of Heaven" (天命, Тяньмин)) [2]. Когда говорят, что компания имеет "Mandate of Heaven" в сфере ИИ, это означает, что она занимает лидирующую позицию не просто благодаря рыночной доле, но и благодаря признанию её технологического превосходства и инновационного лидерства.
Но вряд ли конкуренты согласятся 😊
#ИИгонка
Динамика «гонки вооружений» 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" в сфере ИИ, это означает, что она занимает лидирующую позицию не просто благодаря рыночной доле, но и благодаря признанию её технологического превосходства и инновационного лидерства.
Но вряд ли конкуренты согласятся 😊
#ИИгонка
👍8❤3🔥2
[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
Интересное обсуждение поведенческих интервью в бигтех компаниях. Оно само выполнено в виде интервью, которое берет 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
YouTube
Behavioral Interview Discussion with Ex-Meta Hiring Committee Member
In this conversation, Stefan Mai interviews Austen McDonald, a former senior engineering manager and hiring committee member at Meta, about the how behavioral interviews are assessed, what you should do to prepare, and common red flags.
Check out Austen's…
Check out Austen's…
👍12❤4🔥3
[2/2] Behavioral Interview Discussion with Ex-Meta Hiring Committee Member (Рубрика #Management)
Продолжу рассказ про поведенческие интервью в зарубежных бигтехах, который я начал в первом посте.
9) Кандидатам важно уметь правильно презентовать свой опыт, а для этого важно понимать свои достижения и проекты, а также соотнести свои проекты с ценностями компании
10) Важно правильно выбирать проекты для рассказа. Например, автор рекомендует делить проекты по личному участию, влиянию на бизнес и масштабу. Важно, чтобы о выбранных проектах можно было интересно рассказать (рассказ об унылом проекте вгоняет интервьюера в депрессию )
11) На интервью часто задают вопросы об совершенных ошибках. Не стоит отвечать, что их не было - все люди ошибаются, но хорошие кандидаты признают ошибки и учаться на них (а лучшие учатся еще и на чужих ошибка )
12) Помимо ошибок интервьюер может спросить про слабости кандидата. Не стоит отвечать на них, что их нет или "Я - трудоголик", важно признавать свои слабости, а если еще рассказать про извлеченные из них уроки, то будет еще лучше. Но для интервьера важна честность и искренность, наигранные рассказы не принесут вистов
13) При подготовке к интервью важно подумать о том, а как показать, что вы подходите команде и решаете похожие задачи и сможете принести пользу новой компании. Лучше всего показать это через то, чтобы показать как вы добились реальных результатов на прошлом месте и принесли пользу бизнесу
14) При подготовке к интервью будьте готовы рассказать о себе, любимом проекте, а также конфликтной ситуации. В принципе, можно подготовить еще набор историй, привязанных к ценностям компании, а также отсортированных по масштабу, личному участию и импакту. Это поможет вам на интервью проще подбирать примеры из своего опыта под вопросы интервьюера
15) В конце интервью часто есть время на то, чтобы задать вопросы интервьюеру - это важный момент для того, чтобы продемонстировать интересе к компании и команде (если вас смотрят в конкретную команду), например можно задать вопросы про
- О развитии отдела и технологий
- О стиле управления нанимающего менеджера и динамике команды
В принципе, все советы достаточно логичные и помогут не просто подготовиться к интервью, а запустить процесс рефлексии о своем рабочем опыте и своих ожиданиях от дальнейшего места. Поэтому рекомендую поразмышлять о них, даже если вы не ищите работу:)
P.S.
Я как-то рассказывл про то, как мы нанимаем
- Технических руководителей
- Staff+ инженеров
В принципе, многие советы Остина полезны и для подготовки к нашим интервью.
#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career
Продолжу рассказ про поведенческие интервью в зарубежных бигтехах, который я начал в первом посте.
9) Кандидатам важно уметь правильно презентовать свой опыт, а для этого важно понимать свои достижения и проекты, а также соотнести свои проекты с ценностями компании
10) Важно правильно выбирать проекты для рассказа. Например, автор рекомендует делить проекты по личному участию, влиянию на бизнес и масштабу. Важно, чтобы о выбранных проектах можно было интересно рассказать (
11) На интервью часто задают вопросы об совершенных ошибках. Не стоит отвечать, что их не было - все люди ошибаются, но хорошие кандидаты признают ошибки и учаться на них (
12) Помимо ошибок интервьюер может спросить про слабости кандидата. Не стоит отвечать на них, что их нет или "Я - трудоголик", важно признавать свои слабости, а если еще рассказать про извлеченные из них уроки, то будет еще лучше. Но для интервьера важна честность и искренность, наигранные рассказы не принесут вистов
13) При подготовке к интервью важно подумать о том, а как показать, что вы подходите команде и решаете похожие задачи и сможете принести пользу новой компании. Лучше всего показать это через то, чтобы показать как вы добились реальных результатов на прошлом месте и принесли пользу бизнесу
14) При подготовке к интервью будьте готовы рассказать о себе, любимом проекте, а также конфликтной ситуации. В принципе, можно подготовить еще набор историй, привязанных к ценностям компании, а также отсортированных по масштабу, личному участию и импакту. Это поможет вам на интервью проще подбирать примеры из своего опыта под вопросы интервьюера
15) В конце интервью часто есть время на то, чтобы задать вопросы интервьюеру - это важный момент для того, чтобы продемонстировать интересе к компании и команде (если вас смотрят в конкретную команду), например можно задать вопросы про
- О развитии отдела и технологий
- О стиле управления нанимающего менеджера и динамике команды
В принципе, все советы достаточно логичные и помогут не просто подготовиться к интервью, а запустить процесс рефлексии о своем рабочем опыте и своих ожиданиях от дальнейшего места. Поэтому рекомендую поразмышлять о них, даже если вы не ищите работу:)
P.S.
Я как-то рассказывл про то, как мы нанимаем
- Технических руководителей
- Staff+ инженеров
В принципе, многие советы Остина полезны и для подготовки к нашим интервью.
#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career
👍5❤2🔥2🗿2
Digital Nudge (Рубрика #Management)
Полгода назад мне подарили эту книгу, но прочитал я ее на днях. В ней Fabio Pereira рассказывает про базовые принципы поведенческой экономики, которые могут быть применены в цифровом миру для тонкого влияния на решения и поведение пользователей. Автор вводит концепцию digital nudging или цифрового подталкивания, которая представляет собой использование тонких элементов дизайна, информации и взаимодействия в цифровой среде для управления поведением пользователей без ограничения их свободы выбора. По-факту, это адаптация nudge theory Ричарда Талера и Касса Састейна из книги "Nudge". Правда, digital nudge адаптирован к цифровому контексту, например, веб-сайтам, приложениям или онлайн-платформам, и используют элементы интерфейса, такие как настройки по умолчанию, визуальные подсказки, персонализированные рекомендации и своевременные уведомления для влияния на принятие решений.
Оснонвые идеи книги
1) Choice architecture (архитектура выбора): То, как представлены варианты выбора в цифровой среде, может существенно влиять на поведение пользователей. Например, настройки по умолчанию (например, автоматическое продление подписок) часто направляют пользователей к определенным действиям.
2) Behavioral triggers (психологические триггеры): Цифровые "подталкивания" опираются на психологические принципы, такие как социальное доказательство (например, отзывы пользователей), дефицит (например, "Осталось всего 3 товара") и избегание потерь для стимулирования желаемого поведения.
3) Personalization (персонализация): "Подталкивания" могут быть адаптированы на основе данных о пользователях, таких как предпочтения или действия в реальном времени, для повышения их эффективности.
4) Low-cost interventions (дешевые интервенции): Цифровые "подталкивания" недороги и минимально навязчивы, что делает их масштабируемым решением для влияния на поведение в разных областях
Автор приводит большой список примеров использования digital nudges
- Электронная коммерция: Выделение ограниченных по времени предложений или персонализированных рекомендаций для увеличения продаж.
- Здоровье и фитнес: Стимулирование более здорового образа жизни или регулярных тренировок через напоминания и элементы геймификации.
- Продуктивность на работе: Подталкивание сотрудников к выполнению задач или освоению новых инструментов с помощью целевых уведомлений.
- Образование: Повышение вовлеченности студентов с помощью интерактивных учебных материалов и функций отслеживания прогресса.
Эта книга связана с другими
- "Nudge: Improving Decisions About Health, Wealth, and Happiness" Ричарда Талера и Касса Санстейна — основополагающая работа о теории "подталкивания".
- "Hooked: How to Build Habit-Forming Products" ("На крючке") - эта книга Нира Эяля о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. Я про нее уже рассказывал
- "Thinking, Fast and Slow" ("Думай медленно... решай быстро") Даниэля Канемана — исследует психологические системы принятия решений. Я про нее уже рассказывал
- "Predictably Irrational" ("Предсказуемая иррациональность") Дэна Ариели — объясняет, почему люди принимают иррациональные решения и как на них можно влиять.Я про нее уже рассказывал
- "Inside the Nudge Unit" Дэвида Хэлперна — о практическом применении теории "подталкивания" в государственной политике.
- "Misbehaving: The Making of Behavioral Economics" Ричарда Талера — рассказывает о развитии поведенческой экономики как научной дисциплины.
Эти книги предоставляют более глубокое понимание поведенческой экономики и науки о принятии решений, дополняя темы из Digital Nudge.
А вообще, сама книга "Digital nudge" очень простая и легкая, а поэтому хорошо подходит для того, чтобы познакомиться с этой темой.
P.S.
Я уже рассказывал про пару выступлений Фабио конференциях, из которых можно сложить отличное представление о самой концепции digital nudge
- The Psychology of UX
- Infobesity - How to Cope with the Overload of Information
#Thinking #PopularScience #SelfDevelopment #Brain #Economics #Psychology
Полгода назад мне подарили эту книгу, но прочитал я ее на днях. В ней Fabio Pereira рассказывает про базовые принципы поведенческой экономики, которые могут быть применены в цифровом миру для тонкого влияния на решения и поведение пользователей. Автор вводит концепцию digital nudging или цифрового подталкивания, которая представляет собой использование тонких элементов дизайна, информации и взаимодействия в цифровой среде для управления поведением пользователей без ограничения их свободы выбора. По-факту, это адаптация nudge theory Ричарда Талера и Касса Састейна из книги "Nudge". Правда, digital nudge адаптирован к цифровому контексту, например, веб-сайтам, приложениям или онлайн-платформам, и используют элементы интерфейса, такие как настройки по умолчанию, визуальные подсказки, персонализированные рекомендации и своевременные уведомления для влияния на принятие решений.
Оснонвые идеи книги
1) Choice architecture (архитектура выбора): То, как представлены варианты выбора в цифровой среде, может существенно влиять на поведение пользователей. Например, настройки по умолчанию (например, автоматическое продление подписок) часто направляют пользователей к определенным действиям.
2) Behavioral triggers (психологические триггеры): Цифровые "подталкивания" опираются на психологические принципы, такие как социальное доказательство (например, отзывы пользователей), дефицит (например, "Осталось всего 3 товара") и избегание потерь для стимулирования желаемого поведения.
3) Personalization (персонализация): "Подталкивания" могут быть адаптированы на основе данных о пользователях, таких как предпочтения или действия в реальном времени, для повышения их эффективности.
4) Low-cost interventions (дешевые интервенции): Цифровые "подталкивания" недороги и минимально навязчивы, что делает их масштабируемым решением для влияния на поведение в разных областях
Автор приводит большой список примеров использования digital nudges
- Электронная коммерция: Выделение ограниченных по времени предложений или персонализированных рекомендаций для увеличения продаж.
- Здоровье и фитнес: Стимулирование более здорового образа жизни или регулярных тренировок через напоминания и элементы геймификации.
- Продуктивность на работе: Подталкивание сотрудников к выполнению задач или освоению новых инструментов с помощью целевых уведомлений.
- Образование: Повышение вовлеченности студентов с помощью интерактивных учебных материалов и функций отслеживания прогресса.
Эта книга связана с другими
- "Nudge: Improving Decisions About Health, Wealth, and Happiness" Ричарда Талера и Касса Санстейна — основополагающая работа о теории "подталкивания".
- "Hooked: How to Build Habit-Forming Products" ("На крючке") - эта книга Нира Эяля о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. Я про нее уже рассказывал
- "Thinking, Fast and Slow" ("Думай медленно... решай быстро") Даниэля Канемана — исследует психологические системы принятия решений. Я про нее уже рассказывал
- "Predictably Irrational" ("Предсказуемая иррациональность") Дэна Ариели — объясняет, почему люди принимают иррациональные решения и как на них можно влиять.Я про нее уже рассказывал
- "Inside the Nudge Unit" Дэвида Хэлперна — о практическом применении теории "подталкивания" в государственной политике.
- "Misbehaving: The Making of Behavioral Economics" Ричарда Талера — рассказывает о развитии поведенческой экономики как научной дисциплины.
Эти книги предоставляют более глубокое понимание поведенческой экономики и науки о принятии решений, дополняя темы из Digital Nudge.
А вообще, сама книга "Digital nudge" очень простая и легкая, а поэтому хорошо подходит для того, чтобы познакомиться с этой темой.
P.S.
Я уже рассказывал про пару выступлений Фабио конференциях, из которых можно сложить отличное представление о самой концепции digital nudge
- The Psychology of UX
- Infobesity - How to Cope with the Overload of Information
#Thinking #PopularScience #SelfDevelopment #Brain #Economics #Psychology
👍9❤5🔥3