Let's talk about DX, Baby! - Jo Franchetti - NDC London 2024

Этот доклад Джо Франкетти на конференции NDC {London} 2024 посвящен теме developer experience (DX, DevEx), по которой относительно недавно вышло несколько whitepapers. Эта тема мне импонирует, поэтому я расскажу кратко о чем была речь в этом докладе:
- Автор рассказывает про важность DX, рассказывая историю о разработчике, который столкнулся с трудностями при интеграции нового инструмента.
- Из этого выводятся три составляющие подхода DX: cognitive load, flow state и feedback loops
-- Когнитивная нагрузка - это объем информации, который разработчик должен обработать для выполнения задачи.
-- Состояние потока - это состояние ума, когда человек полностью погружен в свою деятельность и чувствует себя мотивированным и эффективным.
-- Циклы обратной связи - это скорость и качество ответной реакции на произведенные действия
- Дальше звучит тезис о том, что если работать над улучшением опыта разработчика, то это может снизить когнитивную нагрузку и повысить продуктивность.
- Для попадания в состояние потока нам нужна среда, где есть баланс между уровнем мастерства и задачами, которые ставятся перед разработчиками. Это позволяет разработчикам чувствовать, что они контролируют процесс и могут использовать инструменты.
- Циклы обратной связи позволяют разработчикам получать информацию о том, правильно ли они выполняют задачи и где они испытывают трудности (условно запуски CI/CD с прогоном тестов дают полезную обратную связь, но если мы ее ждем часами, то мы теряем в эффективности)

- Для измерения и оценки изменений можно использовать опросы (NPS, CSAT), оценку качества кода (code complexity, code coverage, number of bugs, number of issues), developer productivity (тут мерить можно по разном), development lifecycle
- Дальше автор предлагает разделять Internal DX и External DX
-- Internal DX - тут фокус на улучшении продуктивности, выравнивании с бизнес-целями
-- External DX - тут фокус на adoption rates, вовлечении коммьюнити и промотировании продукта более широкой аудитории
- А дальше автор показывает гигиенические факторы при создании репозиториев с кодом:
-- Соблюдение стандартов кодирования
-- Использование dev контейнеров и codespaces
-- Избегание глобальных настроек
-- Создание всеобъемлющего readme, включающего введение, цели, задачи, ключевые особенности, использование, настройку, ограничения, рекомендации по внесению изменений, контактные данные, кодекс поведения, лицензию.Грамотное написание технических текстов, понимание аудитории, создание образа читателя.
-- Создание понятного кода - функций без побочных эффектов, функций с меньшим количество аргументов, promises over callbacks, ранний возврат из функций, etc. Важно отслеживать читаемость кода, так как большую часть времени мы поддерживаем уже созданный код, а не создаем новый. Сложный код увеличивает когнитивную нагрузку и ухудшает developer experience

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

P.S.
Я уже писал на тему developer productivity и developer experience несколько статей
- В общем про подход к теме developer productivity
- Обзор whitepapers
- Обзор доступных коммерческих платформ

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

Вакансия Staff Engineer в a/b платформу @ Tinkoff

Я ищу крутого инженера в команду, которая разрабатывает систему для проведения экспериментов. Эта система позволяет автоматизировать все этапы проведения экспериментов от планирования до подведения итогов и, существенно снизить расходы на проведение экспериментов. Интересно, что за эту систему отвечает мой коллега, Андрей Цыбин, с которым мы уже записывали серию подкаста "Code of Leadership" про систему продуктовой аналитики Statist. В итоге, сейчас у Андрея есть позиция крутого инженера, что выступит забойщиком при создании системы подведения итогов по экспериментам, которая позволяет оценить результаты проведения тестов по набору метрик и статистических критериев к ним, и на основе этих данных принять решение по эксперименту. План таков, что вокруг этого инженера соберется команда, что сможет сделать Тинькофф еще более data driven.

Кстати, я уже рассказывал про книги на тему статистики, которые были бы полезны такому инженеру
- Как лгать при помощи статистики (How to Lie with Statistics) - на пальцах объясняется как врут с помощью статистики, а отсюда становится ясна мотивация создания системы подведения итогов экспериментов
- Understanding Statistics and Experimental Design. How to Not Lie With Statistics (Статистика и планирование эксперимента для непосвященных) - в этой книге рассказывается про дизайн экспериментов и математику, что стоит за ними
- Доверительное a/b тестирование (Trustworthy Online Controlled Experiments) - а эта книга позволяет еще и понять как сделать платформу для проведения экспериментов на уровне всей компании

Ну а теперь немного про наши ожидания от идеального кандидата (tl;dr - надо быть крутым инженером)
- Опыт разработки на любом из уважаемых языков программирования (C++, Python, Java, Kotlin, Scala, Golang, C#)
- Опыт проектирования масштабируемой инфраструктуры для распределенной обработки данных, включая ее мониторинг. Будет плюсом опыт работы с инструментами обработки данных, таких как: Apache Spark, Apache Airflow и т.п.
- Опыт проектирования моделей данных, выбор подходящего способа хранения и работы с такими хранилищами как: S3, HDFS, Clickhouse, Greenplum
- Будет плюсом знание математической статистики и понимание методологий проведения А/Б экспериментов (можно поботать книги, что я указывал выше, чтобы понять насколько это интересно)

Ну а теперь что придется делать кандидату (tl;dr - надо делать то, что делают крутые инженеры)
- Планировать техническое развитие продукта (тех долг, улучшения)
- Участвовать в разработке архитектуры и спецификации задач
- Участвовать в процессе разработки новых фич от проектирования до ввода в эксплуатацию (да, у нас разработчики релизят код на прод)
- Улучшать кодовую базу как основных сервисов, так и вспомогательных библиотек
- Вести внешную коммуникацию с другими командами, стекхолдерами и руководителями
- Отвечать на своевременную доставку фич

Если вам понравилась позиция, то пишите в личку @apolomodov и @tcandrei

P.S.
А в общем про staff инженеров мы говорили с моим коллегой, Лешей Тарасовым, в другом выпуске Code of Leadership.

#Vacancy #Statistics #Data #Staff #Leadership #Architecture #SoftwareArchitecture

Code of leadership #15 - Interview with Roman Lebed about Information security

В пятнадцатом выпуске подкаста "Code of Leadership" я пообщался с Романом Лебедем, архитектором из департамента информационной безопасности Тинькофф. До Тинькофф Роман руководил командой Red Team и занимался прикладными исследованиями в области безопасности приложений и операционных систем. В этом интервью мы обсуждаем подходы к безопасности в современных технологических компаниях. За 50 минут мы успели рассмотреть следующие моменты

- Как выглядит работа security архитектора в Тинькофф
- Требования к экспертам безопасности
- Как выстроено взаимодействие с командами разработки
- Какие подходы к безопасности существуют в Тинкофф
- Роль архитектора в команде
- Метрики безопасности
- Об "информационной безопасности" как профессии
- Обучение и развитие SDE (software development engineers) и shift left подходы
- Рекомендации для начинающих специалистов

P.S.
У Романа есть свой канал, посвященный безопасности @offensive_thread, на который можно подписаться, а также можно почитать книги, которые он рекомендовал
- Building secure and reliable systems - я про нее уже как-то рассказывал
- How to Linux works
- Android Internals::A Confectioner's Cookbook
- MacOS and iOS Internals (3 тома)
- Компьютерные сети (Таненбаум и ко)

Также у Ромы есть ряд интересных вакансий в его команды
- Архитектор ИБ/ Security Engineer & Architect (SEAR) в команду защиты Core Services
- AppSec TechLead в команду защиты периметра
- DevSecOps инженер в команду защиты периметра
- Разработчики Golang в команду VMP (Vulnerability Management Platform)

Если одна из вакансий вам интересна, то пишите Роме (@Ziv00s3)

#Infosec #Leadership #Architecture #Software #Processes #ProductManagement #Management #Security

Ты уволен. С уважением, ChatGPT (Выпуск подкаста "Карты, деньги и продукт")

Интересный выпуск подкаста "Карты, деньги и продукт", в котором мои коллеги обсуждают влияние искусственного интеллекта на различные профессии, но преимущественно в продактов. Очень интересно слушать гостя, Витю Тарнавского, директора AI Центра Tinkoff, который рассказывает о текущих возможностях AI, а также про его перспективы. Если сократить, то ребята затронули вопросы
- Как AI повлияет на разные профессии - тут больше всего эффекта на digital профессии, так как они уже оцифрованы. А вот профессии из реального сектора сложнее автоматизировать. Для того, чтобы не оказаться на профессиональной обочине надо прямо сейчас пробовать и применять AI инструменты для помощи в своей работе, например, copilot для написания кода, тестов, ...
- Не во всех областях LLMs можно использовать эффективно - у сетей есть галлюцинации и иногда это не ок (но для условной болталки это не проблема)
- В Тинькофф мы активно внедряем технологии искусственного интеллекта для автоматизации работы продуктов и сервисов. Из свеженького можно почитать нашу новость про вселенную ассистентов от 25 апреля 2024 года
- Можно пробовать использовать AI для помощи в принятии решений - например, подбор рецептов по продуктам из холодильника или прогнозированию расходов на фастфуд
- Другая крутая тема - это использование AI для помощи в корпоративном управлении. Условно в большой корпорации всегда есть проблемы с управляемостью (централизацией/децентрализацией) и стоимостью аппарата управления. Примерно про это я писал в посте про developer productivity, называя это подходом сверху-вниз
- Все бегут в сторону AI, потому что есть ожидание, что он может приносить деньги, автоматизируя процессы и создавая новые прогрессивные продукты. Витя упоминает конкретные примеры
- Ну и в финале этой серии гость и ведущие выражают надежду на наступление "пелевинских времен", когда технологии будут помогать в жизни и трансгуманизм станет реальностью.

#AI #ML #Leadership #ProductManagement #Productivity #Management

YAC 2023 - Нейросерия (1 сезон, 1 эпизод)

Интересный формат Yet another conference, которую лет 10 назад я посещал лично. А теперь это сделано в виде сериала, первая серия, которого посвящена трансформационным изменениям от LLMs, причем показано как они влият на продукты самого Яндекса.
- Рассказывается про то, как новая Алиса стала умнее общаться с пользователями - сначала с помощью навыка "Давай придумай", а потом и в обычном режиме
- Про связь LLMs и поиска - мы все видели как ChatGPT встраивался в Bing и вот недавно Яндекс выкатил Нейро
- Про этические аспекты, включая галлюцинации и цензуру, например, на нецензурную лексику
- Про визуальные продукты и Шедеврум от Яндекса
- Про суммаризацию статей и видео в Yandex Browser (удобная штука, которая позволяет экономить время)
- Про то, как LLMs помогают преодолеть проблему чистого листа в контентных сервисах (написать болванку объявления, отзыва, ответа на обращение, письма, ...)
- Ну и про будущее AI, где будет распространено создание персональных ассистентов для разных сфер - аля экосистема персональных помощников, которую мы запустили в Тинькофф

#ML #AI #Software #DataScience

Чистый дизайн (Tidy First?) - Part II - Очистка (Tidyings)

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

В итоге автор предлагает следующие подходы
- Охранные выражения (guarding clauses) - вынос в начало функции начальных выражений, которые надо учитывать и ранний возврат при их наступлении из функции
- Мертвый код (dead code) - его просто надо удалить (если он понадобится, то его можно будет восстановить из системы контроля версий)
- Нормализация симметрий (normalize symmetries) - если кратко, то надо использовать консистентные подходы по всему коду, например, подход к определению и инициализации переменных. Тут могут помочь линтеры или подходы к readability, как в Google (про которые я писал раньше в посте про measuring engineering productivity)
- Новый интерфейс, старая реализация (new interface, old implementation) - при реализации изменений мы можем определить новый красивый интерфейс и всех перевести на него, а поначалу под капотом дергать вызов старой реализации. На самом деле это дефолтный подход при миграциях:)
- Порядок чтения кода (reading order) - файл с кодом должен быть устроен так, чтобы его было удобно изучать читателю (забавно, что это верно для всего: книг, презентаций, мануалов)
- Принцип связности (cohesion order) - суть в том, чтобы организовать код в файле так, чтобы при изменениях элементы, что меняются вместе, распологались рядом. Это же верно и для разных файлов, что сцеплены (coupling) - их можно перенести в общий каталог.
- Соединение объявления переменной и его инициализации (move declaration and initialization together) - опять же тут суть в том, чтобы свести связанные кусочки логики вместе
- Пояснительные переменные (explaining variables) - создание отдельных переменных для сложных выражений вместо вычисления их just in place, например при прокидывании выражения в параметры вызываемой функции
- Пояснительные константы (explaining constants) - создание констант вместо раскиданных по коду магических значений
- Явная передача параметров (explicit parameters) - вместо прокидывания hashmap с ненормированным количеством параметров лучше их явно прокинуть в параметры при вызове функции
- Визуальная группировка инструкций (chunk statements) - если при чтении кода вы понимаете, что одна часть делает вот это, а другая делает то, то просто добавьте дополнительную пустую линию между этими блоками кода, плюс этот блоки кода можно улучшать при помощи остальных советов из этой части
- Извлечение функций-хелперов (extract helper) - извлечение вспомогательных блоков кода в отдельные функции с именем
- Одна большая свалка (one pile) - во время очистки иногда требуется свести все части кода в одно место, а уже потом применять остальные подходы. Когда мы делаем так, то получаем одну большую свалку.
- Содержательные комментарии (explaining comments) - если при чтении куска кода у вас щелкает и возникает мысль "Ах, вот что это такое", то есть смысл записать это озарение в комментарий
- Удаление избыточных комментариев (delete redundant comments) - иногда при очистке кода часть комментариев становится очевидной, в этот момент такие комментарии стоит удалить.

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

Lessons from a Hyperscaler • Casey Rosenthal • GOTO 2024

Интересный доклад от Casey Rosenthal, автора книги "Chaos Engineering", в котором он рассказывает о тех уроках, что были получены от работы в компаниях-гиперскейлерах, где hyperscale это

Hyperscale is the ability of an architecture to scale appropriately as increased demand is added to the system.

Сам автор работал в компании Netflix и был изначально в traffic team, которая отвечала за то, чтобы Netflix работал для пользователей. А в комплексных системах возникает такой уровень сложности, который не помещается ни в одну голову. Для того, чтобы бороться с этой сложностью в Netflix придумали Chaos Monkey, который рандомно отключает машинки с частями системы. Это помогает инженерам искать системные недостатки и принимать решения для повышения надежности системы. Дальше автор приводит конкретный пример с двумя микросервисами, один из которых stateful и хранит данные в persistent DB, а также у него есть кеш в Redis. А дальше что-то идет не так со stateful сервисом и вся система деградирует:) Суть примера в том, что в комплексных системах возможны пробелмы, несмотря на то, что все компоненты соответствуют спецификациям.

Автор говорит про 4 модели, что помогают гиперскейлерам бороться со сложностью:
- Observability (not metrics) - обеспечение наблюдаемости системы, просто метрик для этого не достаточно
- DevUX (platfoorm engineering) - создание платформенных команд, что делают dev2dev продукты, что снижают когнитивную сложность (можно почитать мой разбор "State of Platform Engineering Report 2023 от Puppet")
- Experimentation over testing - экспериментирование, а не тестирование. Суть в том, что эксперименты помогают узнать что-то новое о системе, а тестирование - это проверка того, что система соответствует нашим ожиданиям
- Low bureaucracy - низкий уровень бюрократии, где у инженеров достаточно полномочий на то, чтобы делать свою работу без кучи согласований

Автор рассказывает про 4 экономических столпа комлексности
- States - ограничение количества состояний системы. Например, Ford Model T, где потребитель мог купить машину любого цвета, если этот цвет черный:) Но сейчас это ушло в прошлое и мы ценим вариативность и персонализацию продуктов под конкретного клиента
- Relationships - здесь у нас тоже все идет по нарастающей - добавляются новые связи, новые уровни абстракции, динамическое поведение систем становится все сложнее
- Environment - окружающая среда тоже не отличается предсказуемостью и мало кто из компаний может на нее как-то значимо повлиять в свою пользу (если вы не Amazon или Google)
- Reversability - а вот тут разработка софта сильно выделяется на общем фоне. Мы можем выбрать для себя фокус на этом и получить возможность откатывать изменения. Тут нам в помощь CI/CD, a/b тестирование гипотез, ... Но для того, чтобы это все работало нам требуется observability.

И автор рассказывает про подходы: observability 1.0 и observability 2.0, где observability 1.0 это
• Metrics (метрики)
• Unstructured logs (неструктурированные логи)
• Structure logs (структурированные логи)
Недостатком observability 1.0 является убывающая полезность и нарастающие затраты на создание и хранение логов и метрик. Суть в том, что по мере роста системы, добавления компонентов, инцидентов, логов будет становиться все больше и сложно будет искать в них нужную информацию, а также это все будет занимать все больше места.

В качестве ответа автор говорит про observability 2.0, который обладает следующими возможностями:
- Это подход с high cardinality / high dimenions и в одном месте, который является единым источником истины
- Из этого хранилища можно получать показатели, логи, структурированные и неструктурированные данные
- А кроме того, это не уменьшает эффективность разработчиков, а скорее увеличивает за счет использования одного решения

У нас в Tinkoff таким единым источником истины является Sage, наша obserbility платформа, которая является стандартом де-факто для всех в компании.

#Devops #PlatformEngineering #Management #SoftwareDevelopment #Software #SRE