HighLoad++ 2023

Завтра буду на конференции Highload++ и зайду на наш стенд на пару часиков, там меня можно будет поймать и пообщаться. Там же все время будут мои коллеги, с которыми можно поговорить про наши внутренние технологические продукты, которые мы используем внутри и продаем наружу
- TiMe - современный корпоративный мессенджер, который мы используем внутри вместо slack
- Sage - full-stack observability платформа, которую мы используем для централизованного сбора и анализа телеметрии всех сервисов компании
- Thara - сервис для оживления 3D-аватаров и синтеза мимики, который преобразует аудио или текст в видеоконтент с визуальным аватаром для коммуникации в режиме реального времени
- Etna - платформа прогнозирования и предиктивной аналитики
- и другие

А вечером в 19.00 можно будет посмотреть вручение премии Highload++, куда я номинирован, но думаю, что лауреатом станет кто-то из других участников: Яндекс-Практикум, Лекторий Академии Яндекса, Getmentor.dev, Linkmeup, Школа 21, Skillbox. Кстати, трансляция из главного зала открыта для всех, надо только зарегестрироваться для получения к ней на сайте конфы.

#Conference #SoftwareDevelopment #Software #Engineering #Architecture

The Agile Paradoxon

Крутое видео с историей развития Agile подходов к разработке софта, которые пришли на смену более тяжеловесным подходам и принесли легкость, простоту и гибкость. Agile практики больше 20 лет назад смогли договориться об общем манифесте, суть которого была изложена в строках
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Что привело к появлению более коротких итераций разработки, скрам церемоний, идей о командах, что самоорганизуются.
Все это стартовало как революция ... но стало религией ... со своими догмами, проповедниками и прихожанами.

#Management #Leadership #Processes #SelfDevelopment

Code of Architecture - Continuous Architecture in Practice - III

Сегодня в 18:00 по Москве мы обсудим пятую и шестую главу книги Continuous Architecture in Practice. Эти главы посвящены вопросам scalability и performance.
- в части про scalability мы погорим про архитектурные подходы к масштабированию stateless и stateful нагрузок
- в части про performance мы обсудим почему производительность важна, как ее мониторить и что делать для повышения производительности вашего решения

У нас будет два гостя:
- Алексей Тарасов, который развивает архитектуру Тинькофф Инвестиций
- Даниил Кулешов, архитектор новой системы авторизации для клиентов

#Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management

Есть контакт! Общайся продуктивно, без стресса, в любой ситуации

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

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

2. Те, кто всегда рядом
Здесь читатель знакомится со своим ближайшим кругом общения, учится находить взаимопонимание, исследовать окружение и вести оччень трудные разговоры. Здесь авторы вспоминаают про пирамиду потребностей (пирамиду Маслоу), говорят про конфликты как зоны роста, круги близости, помогают определить с кем из ближайшего круга можно поговорить и о чем. В части про взаимоотношение много говориться о том, что надо избегать оценочных суждений и заменять их описаниями того, почему у нас сформировалась такая оценка. Дальше авторы возвращаются к вопросу чувств и рассказывают про "ты-высказывания" и "я-высказывания", что помогает уйти от обвинительных высказываний в нейтральные. Много времени уделяется обсуждению границ и почему они нужны для комфортного общения. Дальше предлагается подумать про свои границы, а также про соблюдение чужих границ. В части исследования окружения предлагается сформулировать цедли и ожидания от общения с другими людьми (в книге предлагается подумать насчет отношений с родителями). Дальше идет переход к тому, а как обсуждать сложные вопросы и решать неразрешенные конфликты. Как сформулировать свои права и обязанности, а также общаться с друзьями. Что делать с манипуляциями, как их распознать и как ответить на попытки манипуляции. Как поддерживать собеседника при помощи активного слушания и как распознать токсичного человека, что такое буллинг и как дать отпор.

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

4. У всех на глазах
Здесь авторы на пальцах объясняют правила публичных выступлений, куда входят части
- цель и идея выступления, которые зависят от аудитории на которую мы планируем рассказывать
- структура выступления
- как подготовиться к самому выстулпению
- как работать с вопросами аудитории
В общем, это краткая но полезная глава про публичные выступления.

#ForKids #ForParents #SelfDevelopment

Code of Leadership

С нового года я планирую запустить видеоподкаст с обсуждением engineering management и technical leadership. Формат будет таков
- один выпуск - одна книга
- один выпуск - один гость с большим опытом разработки
- книги для разбора пока следующие: "The Art of Leadership", "The Manager's Path", "The Staff Engineer's Path", "Team Topologies"
Чуть позже закину список гостей на первые четыре серии.
Если есть желание послушать про другие книги на эти темы, то закидывайте предложения в комментариях.

#Management #Leadership #Software #Engineering #SelfDevelopment #Podcast

TeamLead Conf++ 2023

Завтра в 11.20 ++ я выступлю на Teamlead Conf в главном зале с темой "Как RnD появляется в крупных IТ-компаниях". Круто, что именно в главном зале, так как он будет доступен в виде публичной трансляции, но на которую надо будет зарегистрироваться. Так что если вам интересна эта тема, то приходите послушать и позадвать вопросы как online, так и offline.

#Management #RnD #Leadership #Processes #Architecture #PlatformEngineering

Материалы к докладу "Как RnD появляется в крупных IТ-компаниях"

Сегодня я выступаю на Teamlead Conf с этим докладом и тут по традиции привожу список рекомендованных материалов.
- Статья с расшифровкой - текстовая версия выступления, но без части про Yandex (ее я добавлял именно к Teamlead Conf)
- White paper "Google's Hybrid Approach to Research" - хорошая научная статья 2012 года про гибридный подход Google к RnD
- Ключевые публикации с Google Research - подборка от меня ключевых whitepaper по техническим продуктам Google
- Invent and Wander. Избранные статьи создателя Amazon Джеффа Безоса - книга с историей Amazon через публичные письма Джеффа акционерам + другие ключевые выступления
- Письмо Джеффа Безоса акционерам 2010 года - интересно написано про важность общих подходов и инструментов для компании
- Статья от Yandex "Почему инфраструктура big tech обычно состоит из самописных решений" - крутая статья, в которой на пальцах объясняются причины и приводится примеры ввнутреннего облака и монорепозитория
- Yandex Platform Engineering - крутой ресурс с описанием технологий и команд отдела Yandex Platform Engineering, который делает инфраструктуру для разработки и эксплуатации продуктов Яндекса
- Whitepaper "Investigation of The Relationship Between Brand Value And R&D Activities: Fortune 500 Companies Analysis" - исследование про связь стоимости бренда и затрат на RnD

#Management #Engineering #Software #Architecture #SoftwareDevelopment #RnD

В этот понедельник мы провели третий стрим клуба Code of Architecture по книге "Continuous Architecture in Practice". Он был посвящен scalability и performance.
- в части про scalability мы погорили про архитектурные подходы к масштабированию stateless и stateful нагрузок
- в части про performance мы обсудили почему производительность важна, как ее мониторить и что делать для повышения производительности вашего решения
У нас в гостях были два гостя:
- Алексей Тарасов, который развивает архитектуру Тинькофф Инвестиций
- Даниил Кулешов, архитектор новой системы авторизации для клиентов

В рамках обсуждения мы упоминали дополнительные материалы
- Requirements Engineering for Software and Systems — книга про работу с требованиями, которую рекомендовал Даниил;
- Статья от Ozon про кеширование и мой обзор этой статьи
- Книга Architecting for Scale и обзор интервью с автором от меня
- Концепция AWS Well-Architected от Amazon, в которой хорошо рассказывается про то, как собирать из кубиков AWS надежные и масштабируемые системы
- Мое выступление про надежные системы, которые в основе используют решения, что хорошо масштабируются
- "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - интересный white paper от ребят из Google, где показано как редизайнится система для повышения ее надежности и масштабируемости, причем сам редизайн выполняется достаточно формально, чтобы по модели оценить позитивное влияние на нужные архитектурные характеристики

#Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management

One Rule to Rule Them All • Pragmatic Dave Thomas • GOTO 2023

Интересное выступление от Dave Thomas, который участвовал в принятии "Manifesto for Agile Software Development" много лет назад. В этом выступлении Дейв использует много цитат Йоги Берра, который славился своими «йогизмами» - остротами, который часто имеют форму очевидной тавтологии или парадоксального противоречия вида "We're lost, but we're making good time". Кстати, эта фраза про наши процессы разработки:) Дальше автор идет по шагам
- И рассказывает про классический waterfall и почему его все перевирают, когда показывают картинку без обратных связей
- Вспоминает про type systems и theorem proving как подход к улучшению качества кода
- Высказывает неканоническое мнение про test coverage (правда, автор доводит все до абсурда с 100% coverage)
- Вспоминает научные истории для того, чтобы обсудить корректность кода и начинает с отсылки к Лапласу, который был приверженцем абсолютного детерминизмаи утверждал, что

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

Дальше Дейв вспоминает про квантовую физику с принципом неопределённости Гейзенбе‌рга, который в простом варианте можно описать так

Невозможно одновременно с точностью определить координаты и скорость квантовой частицы

А потом переходит к теореме о неполноте Геделя, которая в обобщенном виде может звучать так

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

Отсюда Дейв выводит свой первый постулат

Thomas's Postulate #1 - There is no such thing as correct code

И после этого Дейв предлагает стремиться не к корректному коду, а к коду, который готов к изменениям. А изменения бывают по куче причин.
Дальше Дейв вспоминает про старые времена, когда множество уважаемых людей съехалось на горнолыжный курорт и написали свой манифест, который Дейв назвает не Agile Manifesto, а именно "Manifesto for Agile Software Development".
Дальше Дейв вспоминает свое популярное выступление "Agile is Dead • Pragmatic Dave Thomas • GOTO 2015", где для того, чтобы быть agile предлагают не проходить кучу тренингов или приглашать коучей, а просто понимать ценности и применять их

Understand the Agile values and then apply them

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

Thomas's Postulate #2 - Make it easier to change

Дальше автор разбирается с вопросом, а как научиться предсказывать будущее для того, чтобы быть готовым к изменениям. По-факту, он предлагает прокачивать нашу интуицию и много размышляет про сознательное и бессознательное, про выработку правильных паттернов и реакций. Дальше он рекомендует книгу Даниэля Канемана "Thinking fast and slow". Потом он рассказывает про то, как работает опыт и вспоминает про книгу "The inner game of tennis", про которую я тоже слышал лет 10 назад.
Ну и напоследок автор говорит про то, как вести дневник и записывать, когда вы сталкиваетесь с изменениями
- What is the change?
- Likely effort
- Actual effort
- Observations
причем Дейв настаивает на том, чтобы писать это рукой, а не печатать, чтобы использовать мультимодальность нашего мозга:)
В итоге, это упражнение поможет прокачать вам свою интуицию, с помощью которой вы сможете принимать решения лучше.

Ну и напоследок Дейв опять вспоминает про заглавие доклада "One Rule to Rule Them All" и говорит, что это не совсем правило, но оно в том, чтобы

Makе it easier to change

#Management #SelfDevelopment #Processes #Leadership #Learning #Agile #Philosophy #Brain

Задачки про программированию от Тинькофф на Highload++

В начале этой недели был Highload++, на котором у Тинькофф был стенд с Digital Interview. Там были забавные задачи по программированию, а код можно было писать на одном из языков: C++, C#, Go, Java, JavaScript, Kotlin, Python, Swift. Цель была в том, чтобы написать код, который проходит автотесты, которых всего пять на каждую задачу. Сами задачи немного нестандартные, а каждый новый тест открывает новое условие. А иногда условие задачи вообще не известно.

Вы можете порешать эти задачи тут. Задача выбирается случайным образом при нажатии кнопки «Поехали!».

#Conference #Software #SoftwareDevelopment #SelfDevelopment

Как формировать структуру команд под запросы бизнеса - часть 2

Продолжу пост про структуру команд, в котором поговорю про проектный менеджмент. Мне кажется, что каждый менеджер должен уметь работать в рамках проекта, который PMI (Project Management Institute) определяет как

Project is a temporary endeavor undertaken to create a unique product, service or result

Из этого определения сразу видны ключевые характеристики проекта, а именно:
- Уникальность продукта или сервиса (функциональность)
- Ограничение по времени (сроки)
- Ограничение по ресурсам, которые так или иначе конвертируются в деньги (стоимость)
Эти ключевые характеристики можно изобразить графически в виде треугольника ограничений: функциональность - сроки - стоимость. И обычно можно выбрать и уложиться в любые два ограничения из трех:)

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

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

1) Проект переезда web привлечения на новую версию Tinkoff.ru (примерно 7 лет назад)
С этого проекта началась моя карьера в Тинькофф
- Проект переезда на новое решение к моему приходу длился уже больше года
- Над ним работало 50+ человек
- Моя зона ответственности была только в страницах привлечения и формах привлечения, над которыми работало 3 человека
- До переезда оставалось 3 месяца, а на новом решении не работали ключевые вещи: не работал SSR (кто-то ошибся с расчетом нагрузки), не работала аналитика (SPA приложения требовали переделать трекинг), не работали многие механики на формах, а также релизы занимали недели из-за ручного регресса.

Мы сделали этот проект в авральном режиме, успешно переехали и дальше начали развивать приложение как продукт. За три года наши страницы привлечения выросли до всей публичной части Tinkoff.ru, включая все продукты, а команда до 50 человек в 7+ командах. Многие ребята, с которыми мы затянули этот проект и развивали продукт до сих пор со мной. Подробнее про этот проект, переросший в продукт, можно посмотреть в моем выступлении на ArchDays 2019

2) Проект запуска отдельных продуктовых команд и процессов в мобильном банке Тинькофф (примерно 4 года назад)
Этот проект стал вызовом для меня - именно с ним я вышел за границы привлечения.
- Проект перехода на продуктовую структуру команд от одной команды в 50 человек длился уже полгода, но шел с пробуксовкой
- Запрос был в том, чтобы повторить для мобильного банка путь по разъезду на отдельные продуктовые команды, который я проходил в web.
- Здесь вызовом было то, что команда была сложившаяся и требовалось гораздо лучше уметь в change management.

Проект изменений мы запустили за три месяца, но я в это время проводил в среднем по 3 интервью в день, не считая разнообразные синки. Так как эти первые три месяца я работал в режиме привлеченного руководителя, то я почувствовал как сложно идут изменения, когда ты работаешь из позиции консультанта, пускай и внутреннего. Этот проект тоже перерос в большую продуктовую историю, про которую я рассказывал в нескольких частях
- В апреле 2021 года "Как мы меняли разработку лучшего* мобильного банка под требования бизнеса"
- В сентябре 2022 года "Канал. Продукт. Платформа” или эволюция подходов к развитию мобильного банка Тинькофф"

Подводя итоги, я думаю, что проектный менеджмент - это удобный инструмент, у которого есть своя область применимости, где он достаточно эффективен. А в следующем посте поговорим про продуктовую разработку:)

#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software

YaTalks 2023

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

Update
Проверил форму регистрации и узнал, что регистрация на оффлайн уже закончена. Так что остается только вариант с онлайном.

#Conference #Management #Leadership #Processes

eBPF Documentary: eBPF’s Creation Story – Unlocking The Kernel

Крутое документальное видео на полчаса про технологию eBPF, которая используется для безопасного и эффективного расширения возможностей операционной системы в runtime (изначально это была только Linux). Суть в том, что для такого расширения не требовались изменения в исходном коде ядра, а также не требовалось подгружать отдельные его модули. Безопасность достигалась за счет того верификатора внутри ядра, который проводил статический анализ кода. Загруженные программы, прошедшие проверку, либо интерпретируются, либо JIT-компилируются в ядре для обеспечения собственной производительности выполнения. Модель выполнения управляется событиями и, за некоторыми исключениями, выполняется до завершения. Это означает, что программы могут быть прикреплены к различным точкам перехвата в ядре операционной системы и запускаться при возникновении события.

В фильме круто рассказывается как все началось с того, что Alexei Starovoitov, работая в стартапе PLUMgrid над SDN (software defined network), придумал встроить виртуальную машину в ядро Linux

Alexei decided to invent a new instruction set based on x86 assembly and get the kernel to verify the instruction set for safety.

Но эта идея была слишком революционной и поэтому Chris Wright из RedHat (сейчас CTO RedHat) предложил ему пойти эволюционно и начать с того, чтобы

look into an existing kernel subsystem called BPF and integrate it into existing BPF to make it easier to understand and accept for the community.

Собственно отсюда появилось название "extended Berkeley Packet Filter" и дело пошло
- сначала был план сфокусироваться на сети, но как оказалось для горящей проблемы уже было решение
- дальше фокус сместился на трейсинг и к делу подключился Brendan Gregg, который сделал с использованием eBPF инструменты, что потом превратились в bcc и bpftrace
- дальше eBPF показал свою эффективность в hyperscalers (Meta, Google, Netflix, ...), собственно Alexei Starovoitov ушел в 2015 году в Fb и там показал выдающиеся результаты
- потом появилась идея компании Isovalent, которая создала Cilium, который принес возможности eBPF конечным пользователям
- дальше eBPF нашел применение в security
- а потом eBPF повторили и для других операционных систем

В итоге, изначальная задумку удалось внедрить и поменять положение дел в индустрии, когда написание кода для исполнения кода внутри ядра (а не в userspace) было крайне сложным, долгим и дорогим. Теперь это можно сделать легко и быстро, используя eBPF.

P.S.
Я про eBPF услышал только в 2019 на Kubecon в Барсе и сразу не распознал всю прелесть технологии. Возможно, дело в том, что я никогда не был системным программистом, да и сети знаю так себе:)

#Linux #Kubernetes #Networking #DistributedSystems #SystemDesign #Software #Engineering

Code of Architecture - Continuous Architecture in Practice - IV

Завтра в 18:00 мы закончим разобр книги "Continuous Architecture in Practice" и поговорим про три главы
- Resilience as architectural concerns - я достаточно подробно уже разбирал эту главу в своем посте пару месяцев назад
- Software architecture and emerging technologies - тут авторы говорят про AI и blockchain и их влияние на архитектуру софта
- Conclusion - здесь авторы подводят итоги книги, что сделаем и мы на своем стриме

Гостями выпуска станут два эксперта
- Евгений Пешков, техлид, независимый эксперт и консультант, увлеченный созданием продуктов, построением эффективных команд и внедрение практик технического совершенства в мире разработки и архитектуры ПО, основатель сообщества DDDevotion.
- Сергей Баранов, архитектор, основатель конференции ArchDays. Сергей ведет каналы по распределенным системам и Event Storming, пишет статьи в блоге agilemindset.ru.

#CoA #Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management