What Do Developers Want From AI? (Рубрика #DevEx)

Летом 2024 года вышла интересная статья про то, что эволюция AI - это поворотный момент, но с технологическими революциями, что меняют формат работы людей, человечество сталкивается не в первый раз. Поэтому авторы статьи решают провести параллели с развитием автомобильной промышленности и сфокусироваться на потребностях и целях наших разработчиков. Это статья из серии "Hunam centric approach to developer productivity" от ребят из Google, про которую я рассказывал раньше. А теперь основные моменты статьи

1) Последние достижения в AI привели к появлению большого количества инструментов разработки для поддержки искусственного интелекта (например, DuetAI, CoPilot и ChatGPT для задач программирования). После этого было проведено много исследований влияния этих инструментов на продуктивность разработчиков, где задавались вопросы навроде
- Повышают ли улучшения ИИ скорость написания кода?
- Улучшают ли они качество написанного кода?
- Помогают ли они разработчикам находить более креативные решения?
2) Но вот обсуждений того, а как разработчики хотят взаимодействовать с AI в своих инструментах, было гораздо меньше. Авторы исследования со своим фокусом на человекоориентированный подход к пониманию продуктивности разработчиков решили это испраивать и провести исследование для ответа на вопрос, а где разработчики хотят видеть ИИ в своих рабочих процессах, и какими, по их мнению, будут его эффекты?
3) Здесь авторы начинают проводить параллели с автомобилями для понимания потребностей. Они говорят, что понимание того, что люди хотят и в чем нуждаются от технологий, является основой исследований пользовательского опыта. Однако этот подход иногда подвергается сомнению, особенно когда речь идет о крупных технических инновациях - в этих случаях вспоминают знаменитую фразу, приписываемуюГенри Форду: "Если бы я спросил людей, чего они хотят, они бы сказали 'более быстрых лошадей'".
4) Для исследования предпочтений разработчиков авторы провели многочисленные интервью и пользовательские сследования с разработчиками, имеющими различный опыт работы с инструментами разработки с поддержкой ИИ. Разработчики выражали свое желание, чтобы такие инструменты экономили их время и энергию, помогая им более эффективно выполнять свою работу, то есть они хотят, чтобы ИИ поддерживал более простые задачи и уменьшал рутину, позволяя им сосредоточиться на решении сложных проблем и творческих аспектах их работы.
5) Для того, чтобы понять какие области мешают разработчикам быть продуктивными в Google исследователи проводят опросы и анализируют логи. Это позволяет сфокусировать усилия на самых важных факторах, тройка которых в Google сейчас такая
- Технический долг
- Плохая или отсутствующая документация
- Сложности в изучении новых платформ и технологий
6) Авторы классифицировали эволюцию улучшений AI по трем типам (проведя параллели с автомобильной промышленностью)
- Улучшение существующих человеческих возможностей. Для машин это усилитель руля, антиблокировочная система для тормозов. Для AI в разработке это code completion.
- Расширение человеческих возможностей (добавление новых). Для машин это камера заднего вида, контроль слепых зон. Для AI в разработке это code review suggestions, chatbots
- Делегирование человеческих возможностей (фичи, что убирают human in the loop). Для машин это удержание полосы движения, автоматическое торможение, улучшенный круиз-контроль. Для AI в разработке это автоматический откат проблемных релизов, автоматическое удаление dead code, генерация тестов
7) Для успешного внедрения изменений с AI необходимо
- Понимание сопротивления и скептицизма разработчиков
- Создание правильной инфраструктуры для внедрения
- Обеспечение безопасного и справедливого доступа во всех отраслях
- Сохранение фокуса на целях разработчиков, а не только на технологических возможностях

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

Новогодний отпуск

Мой отпуск уже заканчивается, завтра на  работу, а сегодня еще 9 часов лета. Если подводить итоги, то отпуск в новогодние каникулы обычно бывает хорош и позволяет успеть многое:
- Можно хорошо провести время с семьей и отдохнуть
- Посмотреть красивые места - в этот раз это была Шри Ланка
- Порефлексировать о  прошедшем годе и его итогах
- Подумать о будущем - раньше я бы сказал о планировании, но сейчас предпочитаю не строить планы, а думать о приоритетах
- Почитать интересные книги - я прочел тройку книг и несколько whitepapers

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

P.S.
И раз отпуск заканчивается, то дальше я смогу постить еще больше интересного в канале:)

Grokking Continuous Delivery (Грокаем continuous delivery) (Рубрика #DevEx)

Одной из книг, что я прочел на новогодних каникулах стала книга Кристи Уилсон из Google про современные подходы к continuous delivery. Я достаточно осторожно отношусь к книгам из серии Grokking, но тут меня подкупило, что вступительное слово написало целых два крутых инженера, что точно умеют в инженерию
- Джез Хамбл, что был соавтором книг "Continuous Delivery", "DevOps Handbook", "Accelerate" (я уже рассказывал про первую и третью книги из этого списка)
- Эрик Брюэр, что сформулировал CAP теорему (я уже рассказывал об этом), а потом участвовал в разработке Google Spanner, а сейчас VP Infrastructure & Google Fellow
Оба этих уважаемых джентельмена очень хорошо отзывались о книге во вступительном слове, поэтому я был в предвкушении интересного чтения ... и так и получилось. Но интересность была обусловлена не rocket science подходами, а скорее тем, как Кристи буквально с основ объяснила как выглядит разработка софта и зачем нужен continuous integrating, continuous delivery и чем он отличается от continuous deployment.

По-факту, в книге 4 части, 13 глав и 2 приложения, которые чем-то напоминают мне комиксы - во многих главах разбираются почти реальные проблемы выдуманных компаний навроде "Cat Picture", "Super Game Console", "Ice Cream for All", "CoinExCompare" и так далее. Это позволяет автору продемонстировать эволюционное развитие подходов к инженерным процессам, а не сразу показывать идеальную картинку. Кстати, по оглавлению уже можно понять как выстроена логика повествования

Part 1: Introducing continuous delivery
Chapter 1: Welcome to Grokking Continuous Delivery
Chapter 2: A basic pipeline
Part 2: Keeping software in a deliverable state
Chapter 3: Version control is the only way to roll
Chapter 4: Use linting effectively
Chapter 5: Dealing with noisy tests
Chapter 6: Speeding up slow test suites
Chapter 7: Give the right signals at the right times
Part 3: Making delivery easy
Chapter 8: Easy delivery starts with version control
Chapter 9: Building securely and reliably
Chapter 10: Deploying confidently
Part 4: CD design
Chapter 11: Starter packs: From zero to CD
Chapter 12: Scripts are code, too
Chapter 13: Pipeline design

Из важного стоит отметить, что Кристи
1) Старается не привязываться к инструментам для CI/CD (для этого есть первое приложение, где рассматриваются их возможности)
2) Дает инструкции по настройке пайплайнов как для green-field, так и для brown-field проектов
3) Акцентирует внимание на лучших практиках: VCS как источник истины, безопасное развертывание с использованием автоматизации, использование шагов пайплайна для получения правильных сигналов о готовности софта для развертывания, отслеживание качества процесса поставки при помощи DORA метрик (подробнее про них в книге Accelerate, о которой я рассказывал в трех частях 1, 2 и 3)

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

P.S.
Книга на русском вышла в издательстве "Питер" и как по мне она переведена достаточно неплохо:)

#Devops #Management #Leadership #Processes #SRE #Software #Devops #Architecture #SoftwareDevelopment

Measuring Developer Experience With a Longitudinal Survey - Part 2 (Рубрика #DevEx)

Продолжая первый пост, расскажу про основные моменты в том, как устроены опросы про developer productivity в Google.

4) Основными фичами программы опросов в Google являются следующие моменты
- Каждый квартал за программу опросов отвечает новая пара: исследователь и инженер. Исследователь отвечает за развитие и эволюцию программы исследований и коммуникации, инженер отвечает за автоматизацию инфраструктуры обработки и анализа данных. Сменяемость этой пары позволяет лучше задокументировать процесс и сделать его безпристрастным и повторяемы
- Процесс проведения опросов четко описан и выстроен в формате пайплайна: определение изменений в опросах, имплементация изменений, верификация, запуск, анализ, подготовка и рассылка отчетов.
- Процесс хорошо автоматизирован и большая часть его проходит без участия человека
5) Такой процесс помог иссследователям получать крутые инсайты, например
- Какое было влияние пандемии COVID-19 на разработчиков в Google. Подробнее про это в моем разборе "Hybrid Productivity"
- Как валидировать другие метрики, например, так ребята изучали поток, фокус и friction при разработке - подробнее про это в моем разборе "Measuring Flow, Focus, and Friction for Developers"
- Как можно драматически улушить метрику, например, техдолг. Подробнее про это в моем разборе "Defining, measuring and managing technical debt" и в выпуске Research Insights Made Simple #2 с обсуждением этого whitepaper
6) Надо заниматься эволюцией опросов во времени, так как они имеют свойство удлиняться и может уменьшаться response rate. Авторы борятся с этим через 2 вещи
- Sampling. Авторы бьют всех инженеров на три когорты, а каждая когорт проходит опросы раз в 3 квартала (условно каждый квартал только треть инженеров отвечает на вопросы). Важно, что группы именно 3, так как это позволяет отвечать им на вопросы в разное время года
- Reporting. Авторы анонимизируют результаты и делают их доступными всем, а также показывают какие решения принимаются на их основе и к каким результатам они приводят. Это мотивирует инженеров их заполнять.
7) Последнее изменение опросов привело к тому, что авторы выкинули сильно специфические вопросы и сконцентрировались на тех, по которым можно принимать решения и отслеживать эффект

To better serve decisions at the company level, we opted for more generalizable questions focused on five outcome measures and four additional theme areas that are drivers of our outcomes

Основными outcomes являются: satisfaction, productivity, speed, ease, quality. А темы можно посмотреть в приложенном изображении
8.) Напоследок авторы дают алгоритм с рекомендациями для создания своей программы longitudinal survey

- Establish a clear and unique goal for your survey (ensure that there are no other survey programs or data sources that you can already use).
- Collaborate with domain experts and researchers to develop an effective instrument.
- Gather stakeholder buy-in (for example, communicate the value of survey data and partner with teams that can act on your results).
- If you are planning to run a longitudinal survey, invest time in the beginning in setting up the right infrastructure, process, templates, and documentation.
- Maintain the health of your survey program (control survey length and sample strategically).
- Be transparent and accountable. The quality of your insights depends on the feedback provided by your developers, so make it clear why they should spend their time on it.

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

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

Третий раз в стационаре (Рубрика #LifeStory)

В последнее время я начал получать фидбек, что больше историй из моей жизни разбавляют сухой контент канала с книгами, whitepapers и моими мыслями о работе. Я внял этой обратной связи и решил, что буду теперь периодически писать что-то из своей жизни и сегодня у меня есть о чем рассказать. Вчера я оказался в третий раз в своей жизни в стационаре, но первые два раза я был там сам, а вчера попал с сыном. Вообще, это длинная история:
- В ноябре у него был отит, что мы вроде бы вылечили
- В начале декабря мы сходили к лору из-за соплей и стало ясно, что у нас бинго: отит + воспаленные аденоиды
- Мы решили, что надо оперировать, так как не хотелось уходить больными в Новый год
- После операции, что должна была включать удаление аденоидов и операцию на ухе, ему нельзя бы было летать месяц
- В итоге, у нас чуть не сорвался отпуск, но при операции выяснилось, что ухо прокалывать не пришлось - вода ушла сама
- Удаление аденоидов приводило к запрету на полет в 2 недели, что позволило нам слетать в Шри Ланку, но средний и старший сын уже переиграли свои планы
- Когда мы были в Шри Ланке у старшего сына (18 лет) были проблемы со здоровьем - оказалось, что он за неделю без лечения довел себя до пневмонии
- В понедельник вечером мы прилетели в Москву, во вторник я сходил на работу, а вечером вторника жену и самого маленького сына накрыло болезнью
- В среду я решил остаться поработать из дома, но приехавшие на дом врачи диагностировали отит у малыша, а также грипп у жены - эффекты были такие, что температура была у обоих в 38.5 градусов
- Жене приехали ставить капельницу на дом, так как температура нурафеном не сбивалась, а я с малышом ближе к вечеру уехал в стационар, так как тоже температура была слишком высокой
- В стационаре малышу и мне сделали тест на ковид - оказалось, что не он. Потом померили у врача температуру и сказали "сорок два", оказалось, что это было 40.2.
- Получилось, что младший сын собрал страйк: отит с жидкостью, воспаленные мендалины и грипп, но зато теперь понятно как и чем лечить - капельницы проставили и температура пошла вниз

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

Update
У малыша оказался страйк: отит, грипп, пневмония. Классно, что мы его вовремя отвезли в стационар - сейчас температура сбита, идет планомерное лечение

#LifeStory #Storytelling

Глава "API Governance" из книги API Management - Part I (Рубрика #Management)

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

In fact, we’ll go as far as saying that it’s impossible to manage your APIs without governing them.

Поэтому тот или иной подход к governance существует и авторы предлагают модель для осмысленного выбора подхода
2. Этими элементами системы governance являются: decisions, management, complexity
3. Инженерная работа предполагает большое количество решений, причем часть решений влияют на то, как себя будет чувствовать в дальнейшем бизнес
4. В большой компании может требоваться принимать много решений и в ограниченный промежуток времени, а governance должен помогать в организации процесса принятия этих решений так, чтобы они были качественными.
5. Процессы governance - это дорогое удовольствие, но хорошая новость в том, что не требуется контролировать все принимаемые решения в организации, а плохая в том, что надо определиться с тем, а что нужно контролировать для получения хороших результатов
6. Здесь вступает в дело complexity, а точнее то, что мы работаем с complex adaptive system, у которых следующие интересные свойства
- В них много взаимозависимых частей (люди, технологии, процессы, культура, ...)
- Эти части меняют свое поведение динамически и адаптируются к изменениям (например, изменения в технологиях инфры приводить к изменению практик развертывания)
7. Люди хорошо адаптируются к изменениям в отличие от нашего существующего софта и они умеют принимать локально оптимальные решения, из которых вырастает со временем большая система
8. Если мы хотим влиять на поведение людей и принятие ими решений в нужную нам сторону, то мы не можем рубить с плеча и вот, что авторы книги рекомендуют делать

A big, up-front plan and execution approach to API governance is unlikely to work. Instead, you’ll need to “nudge” the system by making smaller changes and assessing their impact. It requires an approach of continuous adjustment and improvement, in the same way you might tend to a garden, pruning branches, planting seeds, and watering while continuously observing and adjusting your approach.

9. Для эффективного управления принятием решений стоит ответить на три вопроса
- Какие решения надо менеджерить?
- Кто и где должен принимать эти решения?
- Как эта стратегия принятия решений повлияет на CAS (complex adaptive systems)
10. Вообще есть 2 концептуальных способа принятия решений: централизованный и децентрализованный. Их проще всего рассматривать через призму трех факторов
- Доступность и точность информации для принятия решений
- Талант к принятию решений
- Стоимость координации
11. Другие важные аспекты для рассмотрения - это scope и scale
- Scope of optimization - условно при децентрализованном принятии решений могут приниматься локально оптимальные решения и все будет выглядеть модно и инновационно. Но если учитывать только local scope, то на всю систему решения могут влиять негативно - дружить эти отдельные решения на уровне всей компании будет ой как тяжело
- Scale of operations - это про количество решений, которые требуется принять. Условно, если требуется принимать сложные решения, то сложно обеспечить все децентрализованные команды профессионалами, что смогут их принять. А централизация принятия решений приведет центральную группу в бутылочное горлышко.

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

#Architecture #Software #Governance #Management #Leadership #Processes #Leadership

Глава "API Governance" из книги API Management - Part II (Рубрика #Management)

Продолжая рассказ из прошлого поста, обсудим как можно воспользоваться подходом разделяй и властвуй и организовать governance процесс через микс централизованного и децентрализованного подхода. Для этого стоит разделить процесс принятия решений на отдельные этапы, которые похожи на пайплан разработки:) И эти этапы следующие
1. Inception (начало). Каждое решение принимается, потому что кто-то считает, что это решение необходимо принять. Это означает, что кто-то определил, что проблема или возможность существуют с более чем одним возможным решением.
2. Choice generation (генерация опций). Если вы принимаете решение в области, в которой у вас большой опыт, генерирование вариантов может быть довольно простым. Но если есть много неизвестных, вам нужно будет потратить больше времени на определение возможностей.
3. Selection (выбор). Это сердце принятия решения, на котором большинство людей фокусируется, но важность элемента выбора во многом зависит от объема доступных вариантов.
4. Authorization (авторизация принятого решения). Тот факт, что выбор был сделан, не означает, что решение принято. Выбор должен быть авторизован, прежде чем он может быть реализован. Авторизация — это работа по принятию решения о действительности выбранного выбора. Был ли сделан правильный выбор? Осуществим ли он? Безопасен ли он? Имеет ли он смысл в контексте других принятых решений?
5. Implementation (реализация). Процесс принятия решения не заканчивается, когда выбор авторизован. Реализация является важной частью работы по управлению API. Если реализация решений происходит слишком медленно или некачественно, то все ваши решения напрасны.
6. Challenge (оспаривание). Решения не являются неизменными, и каждое решение, которое вы принимаете для вашей системы управления API, должно быть открыто для оспаривания. Часто мы не думаем о том, что принимаемые нами решения могут потребовать пересмотра, изменения или даже отмены в будущем. Определение элемента вызова позволяет нам планировать непрерывные изменения на уровне принятия решений.

И вся прелесть в том, что можно централизовать или децентролизовать каждый из шагов этого подхода к принятию решений. Наприме, при выборе языка для разработки: Inception - centralized, choice generation - centralized, остальное decentralized. Тут суть в том, что централизованно определяются доступные языки, а команды децентрализованно сами решают на каком из них писать.

Авторы отмечаютют, что хорошие governance системы должны включать следующие фичи
- Распределение решений на основе impact, scope, and scale (про это было в первом посте)
- Enforcement системных органичений и валидация имплементации (для централизованных решений)
- Incentivization для формаирования принятия решений (для децентрализованных решений)
- Адаптивность измерения импакта и постоянных улучшений

Продолжение в последнем посте из этой серии, где мы поговорим про паттерны организации governance процессов.

#Architecture #Software #Governance #Management #Leadership #Processes #Leadership