Продолжение Woke, Inc. или подробнее про DOGE (Department of Government Efficiency) (Рубрика #Management)

В предыдущем посте я рассказывал про книгу Вивека Рамасвами "Woke, Inc.". А в этом посте хотел чуть подробнее поговорить про DOGE, консультативной комиссии, цель которой в сокращении бюрократии, снижении неэффективных расходов и упрощении работы федерального правительства. Руководить этой комиссией будут 2 человека
- Илон Маск - генеральный директор Tesla и SpaceX, известный своей поддержкой дерегуляции.
- Вивек Рамасвами - предприниматель и бывший кандидат в президенты, сторонник политики минимального вмешательства государства.

Основные цели комиссии следующие
- Сокращение федеральных расходов за счёт устранения дублирующих регуляций и агентств.
- Уменьшение численности федерального персонала, с предложением сократить его на 75%.
- Консолидацию федеральных агентств с более чем 400 до менее чем 100.
- Консультирование по вопросам дерегуляции для повышения эффективности и снижения затрат. Руководители комиссии говорят оценивают эффект в 2$ трлн долларов из федрезерва США.
- Реформа Diversity, Equity, and Inclusion (DEI): одной из ключевых целей является полное устранение расходов на инициативы в области разнообразия, равенства и инклюзии (DEI). Это включает ликвидацию соответствующих подразделений в таких ведомствах, как Министерство здравоохранения и Министерство обороны.
- Прозрачность работы DOGE: Все действия министерства будут освещаться онлайн для обеспечения максимальной прозрачности. Это позволит гражданам следить за ходом реформ в режиме реального времени.

DOGE будет работать до 4 июля 2026 года, что совпадает с 250-летием Соединённых Штатов. Трамп описал эту дату завершения как символическую для миссии быстрого достижения эффективности. Не так уж долго придется подождать, чтобы оценить насколько удастся задуманное этими джентельменами:)

Правда, есть ряд проблемок на пути к реализации задуманного
- DOGE не обладает прямыми регуляторными или исполнительными полномочиями, поэтому его роль ограничивается предоставлением рекомендаций.
- Предложения по сокращению программ социального обеспечения или дискреционных расходов могут столкнуться с серьёзным политическим сопротивлением.
- Юридические вызовы могут возникнуть при попытках обойти одобрение Конгресса для реализации некоторых мер дерегуляции.

Рамасвами сравнивает масштабность этих реформ с Манхэттенским проектом времен Второй мировой войны, подчеркивая их потенциальное влияние на всю страну. Он считает, что главной проблемой США является раздутая бюрократия, которая мешает эффективному управлению государством. Таким образом, DOGE под руководством Рамасвами и Маска нацелен на радикальное преобразование структуры управления США с упором на сокращение расходов, упрощение процессов и повышение прозрачности работы правительства.

#Management #Leadership #Thinking

Woke, Inc. За фасадом корпоративной риторики о социальной справедливости (Woke, Inc.: Inside Corporate America's Social Justice Scam) (Рубрика #Mananagement)
Недавно я наткнулся на книги издательства Fortis Press, основанного в Ереване в 2023 году. Оно публикует переводы книг, посвящённых современным глобальным проблемам. Я купил несколько их книг и первой прочил интересную книгу Вивека Рамасвами, который был кандидатом в президенты США, а сейчас вместе с Илоном Маском, возглавляет новое Министерство эффективности правительства США (DOGE), созданное по инициативе Дональда Трампа. Основная цель этого ведомства — проведение масштабных реформ для сокращения бюрократии, оптимизации государственных расходов и реструктуризации федеральных агентств. Но за несколько лет до этого Вивек написал свою программную книгу с критикой современного подхода к капитализму, который он назвал stakeholder capitalism и противопоставил его shareholder capitalism, который был раньше. Суть в том, что сейчас капитализм пытается делать вид, что учитывает интересы всех стейкхолдеров, а на деле компании используют социальную справедливость и этические ценности для продвижения своих интересов, часто прикрывая этим сомнительные деловые практики.

Если говорить про книгу, то ее название отсылает к движению Woke — "проснувшийся", которое подразумевает нетерпимость к дискриминации и социальному неравенству. А если говорить про основные идеи книги, то они следующие
1) Критика woke-капитализма
Рамасвами утверждает, что корпорации используют «woke»-идеологию как инструмент маркетинга и защиты от критики. По его мнению, это позволяет им избегать ответственности за реальные проблемы, такие как эксплуатация труда или экологический ущерб. Например, он приводит случаи, когда компании вроде Unilever и Nike заявляют о своей социальной ответственности, но при этом игнорируют серьезные нарушения прав работников или продолжают эксплуатировать уязвимые группы населения.
2) Манипуляция потребителями
Рамасвами описывает феномен «woke-индустриального комплекса», где мораль смешивается с потреблением. Компании продают потребителям иллюзию участия в социальных изменениях через покупку их продуктов, что в итоге становится поверхностным решением глубоких проблем. Условно, купи наш гамбургер и он поможет в движении BLM или выпей наш лимонад и это поможет феминисткам
3) Критика ESG-повестки
Рамасвами ставит под сомнение эффективность ESG-инициатив, утверждая, что они часто являются формой «гринвошинга» (создания ложного впечатления экологической ответственности) и не решают фундаментальных проблем устойчивого развития.
4) Идеология woke как средство разделения общества
По мнению автора, woke-культура способствует поляризации общества, разделяя людей на демографические группы и усиливая чувство вины за привилегии у одних и обиды у других. 5) Отказ от смешивания бизнеса и политики
Рамасвами выступает за то, чтобы компании сосредоточились на своей основной задаче - максимизации прибыли - вместо того чтобы вовлекаться в политические и социальные вопросы. По-факту, он предлагает вернуться к старому доброму shareholder capitalism, где основная задача - это максимизация эффекта для акционеров, а учеты интереса стейкхолдеров оставить на правительство, НКО и так далее.

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

#Management #Leadership #Thinking

AI in software engineering at Google: Progress and the path ahead - Part II (Рубрика #AI)

Заканчивая рассказ про использование ИИ в разработке, хочется рассказать о том, чего они добились и какие следующие шаги они видят

6) В итоге, ребята в Google научились следующему
- Они достигли наибольшего эффекта с UX, который естественным образом вписывается в рабочие процессы пользователей . Во всех приведенных выше примерах пользователю предлагается предложение, которое переводит его на следующий шаг в рабочем процессе с помощью одной вкладки или щелчка. Эксперименты, требующие от пользователя помнить о необходимости активировать функцию, не масштабировались.
- Они наблюдают, что с предложениями на основе ИИ автор кода все больше становится рецензентом , и важно найти баланс между стоимостью ревью и добавленной ценностью этого предложения. Обычно это вопрос компромисса с помощью целевых acceptance rates.
- Быстрые итерации с онлайн a/b экспериментами являются ключевыми, поскольку офлайн-метрики часто являются лишь грубыми показателями ценности для пользователя. За счет вывода AI-инструментов во внутренний тулинг авторы получают огромную выгоду от возможности легко запускать и итерировать, измерять данные об использовании и напрямую спрашивать пользователей об их опыте с помощью UX-исследований.
- Полученные высококачественные данные имеют решающее значение для повышения качества моделей.
7) Воронка взаимодействия выглядит примерно так
- Event of SWE acting in tooling
- Trigger for ML prediction
- Confident ML Prediction
- Generated ML Prediction
- Discovery of ML Suggestion
- Applied (это целевой действие)
8 ) Авторы отмечают, что автодополнение кода на основе ML дало мощный буст в разработке софта. Конечно эти модели можно улучшать и дальше, но авторы видят перспективы в расширении помощи на тестирование, понимание и поддержку кода, а также они видят два тренда
- Взаимодействие человека и компьютера перешло на естественный язык как на общепринятую модальность, то есть происходит переход к использованию языка в качестве интерфейса для задач разработки программного обеспечения, а также шлюза для удовлетворения информационных потребностей разработчиков программного обеспечения, и все это интегрировано в IDE.
- Автоматизация более масштабных задач на основе ML (от диагностики проблемы до ее исправления) начала показывать первые признаки осуществимости. Эти возможности обусловлены инновациями в использовании агентов и инструментов , которые позволяют создавать системы, использующие один или несколько LLM в качестве компонента для выполнения более крупной задачи.
Авторы предлагают объединиться для создания бенчмарков для оценки этих возможностей следующего поколения. Они упоминают как примеры
- SWEBench - решение issues на Github
- Бенчи из Cognition AI - а Cognition AI запустили Devin (end-to-end software agent), который пытается решать e2e задачки

#Software #AI #ML #Engineering #Processes #DevEx

Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up (Рубрика #Management)

Это очередной обзор статьи из серии человеческого подхода к продуктивности разработчиков. Это статья фокусируется на критических аспектах онбординга и наращивания скорости работы инженеров.

Основные моменты этой статьи следующие

1. Вопрос онбординга очень важен - это процесс перехода нового инженера от новичка до продуктивного члена команды. Он важен как для индивидуального успеха, так и общекомандной производительности. Эффективный онбординг может сократить время "разгона" и улучшить долговременную продуктивность
2. Но адаптации инженеров часто мешают стандартные проблемы: недостаточная документация, отсутствие наставничества, неясные ожидания от инженера, а также сложные исходный код проектов. Эти факторы могут задерживать способность разработчика эффективно вносить вклад в работу команды
3. Для оценки качества онбординга надо уметь его измерять. По-факту, это измерение относиться к измерению продуктивности инженеров, но так как нас интересуют только результаты изменений в подходах к онбордингу, то авторы решили мерить не саму продуктивность, а изменения в ней.
4. Предыдущие подходы к ramp-up-time metrics включали сравнение параметров новчиков с опытными инженерами, но авторы этого исследования пошли своим путем, в котором им нужно было избежать сравнения между самими инженерами-новичками (иначе у них появилась бы мотивации геймить метрики и показывать как они здорово онбордятся). В итоге, они решили валидировать метрики-кандидаты относительно восприятия самих инженеров относительно того, насколько они заоонбордились в стандартные инженерные задачи.
5. Авторы исследовали 9 метрик-кандидатов и выбрали для дальнейшего анализа 3, в которых есть прогресс со временем работы и выход на некоторый стабильный уровень. Это метрики
   - Active coding time per line of code (LOC)
   - Reviewed LOC
   - Submitted LOC
   Дальше авторы аггрегировали новых инженеров по недельным когортам, а потом начали отслеживать сколько недель потребуется этим метрикам, чтобы выйти на стабильный уровень и оставаться там по-крайней мере 4 недели.
6. Потом авторы запустили опросы для инженеров (что работали меньше 40 недель). Этот опрос прошло порядка 3к инженеров. Вопросы были вокруг 17 стандартных задач, навроде, writing code, reviewing other people's code, running build and tests, finding examples of API use by others at Googe и так далее. Вопросы были про опыт вокруг этих задач в последнюю неделю и было 5 вариантов ответов от "Я не выполнял таких задач", до "Я уже выполняю такие задачи на максимально эффективном уровне по моим ожиданиям".
7. Авторы нашли стат значимую негативню корреляцию между "Active coding time per LOC" и самооценкой эффективности выполнения 15 из 17 задач. А 6 из 17 задач стат значимо были связаны с submitted LOC. Авторы взяли и эту метрику в качестве ramp-ut-time.
8. Авторы рассказали про результаты COVID-19 для ramp-up-time, так как у них данные начали собираться еще до всей петрушки.
   - Для инженеров до COVID-19 средняя круизная скорость была в 2.5 раза выше, чем начальная. А для выходящих в COVID она стала всего 1.5x
   - До COVID 19 инженеры выходили на стабильный submitted LOC за 12 недель, а после - за 18 недель
9. Авторы думают, что смогут использовать результаты исследования для помощи коллегам, которые запускают образовательные инициативы и треннинги для инженеров внутри компании

Авторы предлагают следующие рекомендации для улучшения онбординга
- Предоставляйте исчерпывающую документацию и четкие guidelines.
- Назначайте наставников или «buddies» для помощи новым разработчикам.
- Реализуйте структурированные программы адаптации с определенными этапами.
- Поощряйте обратную связь от новых сотрудников для совершенствования процессов адаптации.
- Инвестируйте в инструменты и системы, которые упрощают навигацию по исходникам и рабочим процессам.

P.S.
Разводящий пост с обзорами всех статей из серии доступен здесь.

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

Архитектурная ката от клуба { между скобок } (Рубрика #Architecture)

Несколько недель назад Гриша Скобелев, основавтель клуба { между скобок } (@backend_megdu_skobkah) собрал людей для участия в архитектурной кате. А в группу экспертов он позвал несколько человек, включая меня. Задача была в проектировании масштабируемой и отказоустойчивой системы поддержки клиентов, работающей через чат. Фокус был в том, чтобы разобраться а как обеспечить связь клиента и оператора поддержки в режиме реального времени с минимальными задержками. Сейчас стала доступна запись этой каты

Полезные ссылки:
- ArchDays - конференция по архитектуре, где я в программном комитете
- Объединение ИТ-Архитекторов
- Канал Игоря Антонова про разработку
- Хорошее видео про event storming
- Про микросервисы от Сергея Баранова

#Architecture #DistributedSystems #SystemDesign #Engineering #Software

Откуда я беру интересные whitepapers (Рубрика #RnD)

Я люблю изучать научные статьи и уделяю этому много времени. Меня часто спрашивают где я их нахожу и я постоянно отвечают, что самые интересные статьи есть на сайтах bigtech компаний
1) Google Research. Основные области исследований Google включают машинное обучение, алгоритмы, квантовые вычисления, вычислительные системы, а также исследования в области науки, общества и ответственных технологий.
2) Amazon Science. В Amazon фокусируются на машинном обучении, компьютерном зрении, обработке естественного языка, квантовых вычислениях, автоматизации логистики и устойчивом развитии.
3) Meta Research*. Исследования охватывают искусственный интеллект, дополненную и виртуальную реальность, обработку естественного языка и социальные взаимодействия.
4) Mircosoft Research. Microsoft фокусируется на следующих областях: искусственный интеллект, машинное обучение, квантовые вычисления, компьютерное зрение, безопасность, взаимодействие человека и компьютера и технологии для социальных благ.
5) Netflix Research. Основные направления у Netflix сфокусированы на нужных для них темах: персонализация контента, оптимизация потоковой передачи, анализ данных и улучшение качества контента с использованием NLP и компьютерного зрения

Также есть общие библиотеки крупных ассоциаций
1) ACM Digital Library (ACM - Association for Computing Machinery)
2) IEEE Publications (IEEE - Institute of Electrical and Electronics Engineers)

P.S.
Я уже как-то рассказывал про свое увлечение whitepapers
1) Мое выступление на Techlead Conf "Как RnD появляется в крупных IТ-компаниях"
2) Новогодный выпуск "Code of Architecture" по white paper «Google's Hybrid Approach to Research»
3) Перечень изученных и разобранных за 1+ год whitepapers
4) Мой подкаст "Research Insights Made Simple" с разбором whitepapers (пока 5 эпизодов, что доступны на Youtube, Yandex Music)
P.P.S.
Meta - это запрещенная в России организация.

#Whitepaper #Architecture #Management #Science

System Design for Interviews and Beyond - Курс на Leetcode - Part II (Рубрика #Architecture)

Я продолжаю рассказ про крутой курс с Leetcode, в котором доступно и понятно рассказывали о том, что такое system design interview и что он призван проверять у кандидатов. В предыдущем посте мы обсудили работу с требованиями, важные архитектурные характеристики, инфраструктуру, кеширование и очереди. В этой части мы продолжим говорить про хранение данных,  взаимодействие компонентов системы 6. Data store internals.
Здесь автор кратко рассматривает тему хранения данных:
- Log - самый простой способ сохранения данных, но вот читать их сложно в таком виде (full scan на любой запрос)
- Index - индексы в качестве способа подготовки данных для эффективных запросов на чтения
- Time series data - отдельный тип данных, которые полезны, например, при мониторинге
- Simple key/value database - автор объясняет как будет работать база с простейшей моделью данных
- B-Tree index - автор рассказывает про вездесущие b-tree индексы, как они устроены и для каких сценариев подходят оптимально
- Embedded databases - иногда удобно встроить базу прямо в процесс приложения, например, так могут LevelDB, RocksDB, DuckDB
- RocksDB - автор рассказывает как устроена эта база и тут речь про memtable, write-ahead log и SSTables
- Сравнение LSM-tree и B-Tree - автор показывает компромиссы каждого из подходов и сравнивает их границы применимости
- Page cache - заканчивает автор рассказом о том, как все это приземлить на файловую систему внутри OS. Без этих знаний многое из описанного выше не будет хорошо работать

7. How to build efficient communication in distributed systems.
В этой части автор говорит про классику коммуникаций
- Push vs pull модели взаимодействия
- Как выглядит host и service discovery (тут появляется DNS), а также peer discovery
- Как выбирать сетевой протокол под задачу (UDP, TCP, HTTP) и как они ведут себя на практике
- Как обычно передается видео-поток и что такое CDN (content delivery network)
- Что такое short pooling, long pooling, web-socket, server-sent events, зачем они нужны и как они ведут себя на практике
- В конце раздела автор показывает как могут работать пуши на клиентов на большом масштабе (аля Netflix)

8. How to delivery data reliably.
Этот раздел начинается с известного списка fallacies of distributed systems, а дальше автор переходит к практическим средствам обеспечения надежности
- Таймауты и стратегии действий с неуспешными запросами: cancel, retry, failover, fallback
- На конкретных примерах автор разбирает когда и как делать retries
- Дальше наступает время обсудить гарантии доставки сообщений: at most once, at least once, exactly once
- Дальше автор рассматривает как работают log-based message queues (аля Kafka) и что такое consumer offset

9. How to deliver data quickly
Здесь автор рассказывает про подходы к батчингу и компрессии данных, что обеспечивает лучшую пропускную способность.

10. How to deliver data at large scale
В этой части наступает время обсудить вопросы масштабирования обработки данных. Автор рассказывает про
- Партиционирование (шардирование) и рассматривает стратегии: lookup strategy, range strategy, hash strategy
- Как партиционирование работает в реальном мире и какие плюсы/минусы имеет
- Как выглядит роутинг запросов
- Что делать с ребалансировкой шардов
- Что такое consistent hashing

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

#Software #Architecture #DistributedSystems #SystemDesign #Engineering