API Design Patterns (Паттерны проектирования API) (Рубрика #Architecture)

В последнее время я много изучаю материалов на тему governance. Туда входит architecture governance, API governance и другие подходы для того, чтобы двигаться в сторону engineering excellence. И так получилось, что я в выходные снял с полки эту книгу "API Design Patterns" из последней закупки на распродаже в издательстве "Питер". Книгу написал Джей Джей Гивакс, соавтор статьи "API Governance at Scale" про подходы в Google. Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta - это видно по заглавной страничке с авторами whitepaper:)

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

P.S.
Я разбирал статью "API Governance at Scale" в первом выпуске нового подкаста "Research Insights Made Simpe" (видео в Youtube, подкаст в Ya Music). Отдельно разбор есть в моем блоге в виде статьи.

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

Почему DevEx важен при разработке IDP и как его померить - Владимир Калугин (Рубрика #Management)

Это интересное выступление моего коллеги Владимира Калугина про developer experience и почему он важен при создании внутренних платформ разработки. Это выступление было в рамках нашей конференции Platform Engineering Night, про которую я рассказывал раньше. Владимир в Т-Банке выступает в роли technical product manager и развивает все, что вокруг кода, сборок и артефактов - то есть, Вова улучшает developer experience всех наших инженеров. Собственно, в докладе Вова рассказывает про модель DevEx, куда входит когнитивная нагрузка на инженеров, циклы обратной связи и состояние потока. Вот как это описывают сами авторы модели

1) Feedback loops
Software organizations commonly look for ways to optimize their value stream by reducing or eliminating delays in software delivery. Shortening feedback loops—the speed and quality of responses to actions performed—is equally important to improving DevEx.
2) Cognitive load
Software development is inherently complex, and the ever-growing number of tools and technologies is further adding to the cognitive load faced by developers. Cognitive load encompasses the amount of mental processing required for a developer to perform a task.
3) Flow state
Developers often speak of "getting into the flow" or "being in the zone." Such statements colloquially describe the concept of flow state, a mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment.

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

Напоследок, приводится список материалов для изучения, среди которых
1) Whitepaper "DevEx: What Actually Drives Productivity" - я его уже разбирал в блоге
2) Whitepaper "DevEx in Action" - я его уже разбирал в блоге
3) Whitepaper "DevOps metrics" - я его пока не читал
4) Сайт про внутренние платформы разработки - Internal Developer Platform
5) Статья "The top 10 fallacies in platform engineering"

Кроме этого я рекомендую почитать на эту тему колонку исследователей из Google, где они разбирают human centric подход к инженернной продуктивности. В ней пока 8 статей и 4 из них я уже разобрал в деталях.

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

System Design Interview - Highload++ 2024 (Рубрика #Architecture)

В этом году я зайду в декабре на Highload++, чтобы подискутировать на тему system design interview. Этот формат собеседования стал достаточно популярным в крупных компаниях6 а кто-то его вкручивает в свой процесс собеседований как карго-культ. В этои дискуссии мы обсудим
- Что это за тип интервью
- Зачем он нужен компаниям и можно ли обойтись без него
- Какие у него есть плюсы и минусы

Надеюсь, что дискуссия будет интересной и понравится всем зрителям:)

P.S.
До этого я уже рассказывал про процессы найма в большие компании и типы интервью на примере Т-Банка. Про System Design у меня тоже было много материалов. Например можно посмотреть в общем про system design в Tinkoff, больше про то, как мы оцениваем прохождение собеседования и как подготовиться к собеседованию или публичные интервью на ArchDays

#Career #HR #Management #Architecture #Software #Leadership #Processes

The Engineering Executive's Primer - Part 0 (Рубрика #Management)

Я уже давно прочел новую книгу Will Larson для IT топ-менеджеров, про которую я писал раньше. Прочел и прочел, но все как-то не доходили руки написать про нее, но сейчас я в очередной раз сижу в аэропорту и жду самолета, поэтому время есть:) Сразу скажу, что книга мне понравилась - у Вилла как обычно отлично со структурой книги, а отдельные главы достаточно емкие и наводят на размышление (интересно, что они обычно появляются как статьи в блоге lethain.com, один из немногих блогов, что я читаю)

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

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

The Engineering Executive's Primer - Part I (Рубрика #Management)

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

0) Preface
Во введении автор рассказывает про то, как он пришел к идее этой книги после предыдущих книг "Staff Engineer" и "An Elegant Puzzle. Systems of Engineering Management". Первая является классным источником информации по карьерному пути для инженеров, которые переросли уровень senior и отправились покорять новые моря. Я про нее уже рассказывал: 1 и 2. Вторая книга хороша для engineering managers, про которую я рассказывал раньше, а потом было две серии подкаста "Code of Leadership" с разбором этой книги вместе с Eugene Sergueev, senior engineering manager из Flo health: 1 и 2
1) Getting the Job
Начинает книгу автор с того, чтобы рассказать про то, а как же можно получить работу в качестве engineering executive. Для начала стоит ответить себе на вопрос, а точно стоит в это вписываться? Дальше возникают вопросы, а где это делать: внутри текущей компании или во внешней. Дальше автор обсуждает хаотичный процесс найма топов, который отличается от компании к компании, а дальше еще идет и обсуждение условий. Ну и заканчивается все тем, а как размышлять относительного того, а принимать офер или нет. В общем и целом, глава действительно неплохо описывает этот непростой процесс и дает структуру и подход для взвешенного принятия решений.
2) Your First 90 Days
Здесь автор говорит о том, что в первые 90 дней придется серьезно попотеть и начать с того, чтобы разобраться с тем как работает бизнес и откуда приходят деньги, что определяет культуру компании, как установить здоровые взаимоотношения со стейкхолдерами и своими peers, насколько хорошо функционирует инженерная команда с точки зрения delivery, насколько высоко техническое качество софта и инструментов для поддержки процессов разработки, что с моралью инженерной команды и насколько сама команда устойчива для выбранного темпа развития команды. Дальше важно ограничить количство ранних изменений, что вы делаете в первые 90 дней. Кроме этого важно выстроить доверие с коллегами и позаботиться о поддержке с их стороны. Вообще, классно разобраться как в компании осуществляется работа и как выглядят технологии (включая код и деплой, дежурства, работа с инцидентами, ...)
3) Writing Your Engineering Strategy
Эту главу я разбирал еще тогда, когда она была просто статье в блоге автора. Статья была отличной и она не стала хуже после превращения в книжную главу:)
4) How to Plan
Автор рассказывает про стандартный подход к планированию в компаниях:
- Ежегодное финансовое планирование (включая план по headcount)
- Полугодовые или квартальные планы, например в виде OKRs для команд. Эти планы таргетируют бизнес результаты или список проектов, что надо сделать
- Внутрикомандные процессы управления работой (Kanban, Scrum, etc), которые направлены на то, чтобы уложиться в квартальные/полугодовые планы
- Отдельно автор говорит о том, что могут быть еще и периодические ревью, например, каждый месяц. Эти ревью направлены на отслеживание прогресса по выполнению целей компании

Продолжение в следующих постах: 2

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

The Engineering Executive's Primer - Part II (Рубрика #Management)

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

5. Creating Useful Organizational Values
В этой главе автор говорит про организационные ценности и как они влияют на работу компании. Он вспоминает свою работу в Uber и конкретно культурный принцип "Let builders build (People must be empowered to build things)", который повышал diversity технологического ландшафта. Каждый из инженеров считал, что этот принцип про то, что они могут делать то, что хотят:) Подробнее про Uber в книге "Super Pumped", про которую я уже рассказывал.
Дальше автор рассказывает о том какие проблемы решают организационные ценности, должны ли они быть общими для всей организаций или у инженерной части должны быть какие-то свои ценности. Мне нравятся критерии Вилла относительно того, а как проверить насколько ценность сформулирована так, чтобы приносит пользу:

- Reversible: It can be rewritten to have a different or opposite perspective without being nonsensical.
- Applicable: It can be used to navigate complex, real scenarios, particularly when making trade-offs.
- Honest: It accurately describes real behavior.

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

Дальше Вилл рассказывает как раскатывать обновления культутрных ценностей через стандартный процесс раскатки изменений: "identify the opportunity, document potential options, involve stakeholders early to build buy-in, test before finalizing to avoid folks feeling trapped, and iterate until it’s useful". А потом отдельно надо встроить изменения в найм, онбординг, лестницу грейдов. Ну и дальше подсвечивать соответствие новым ценностям во время работы.
Напоследок автор приводит тот список ценностей, что кажется ему полезным

- Create capacity (rather than capture it).
- Default to vendors unless it’s our core competency.
- Follow existing patterns unless there’s a need for order-of-magnitude improvement.
- Optimize for the [whole, business unit, team].
- Approach conflict with curiosity.

6. Measuring Engineering Organizations
Эту главу автор начинает с перечисления подходов к измерениям в инженерных организациях, а дальше он рассказывает про свой подход к измеренями, про паттерны и антипаттерны. И для начала надо отметить, что он делит подходы на измерения для себя и измерения для стейкхолеров. В части "measuring for yourself" он говорит про измерения для планирования, выполнения, оптимизации, а также для вдохновения. В части измерений для стейкхолдеров автор говорит про измерения для CEO и совета директоров, для финансового департамента, для стртегически peers (продукт, дизайн, продажи), для тактических peers.
Дальше автор предлагает алгоритм для измерений
1) Некоторые вещи сложно измерить, поэтому пробуйте это измерить только если вы действительно планируете учитывать это при принятии решения. Если же это нет так, то просто померьте что-то попроще, навроде, прокси-метрики
2) Часть измерений очень проста, поэтому появляется желание сделать эти измерения для построения доверия со стейкхолдерами:) И тут часто желание измерений и усилия, приложенные для их получения, важнее чем реальный результат:)
3) Если возможно, добавляйте по одному измерению за раз, так как если пытаться внедрить слишком много изменений в измерения, то можно облажаться.
Дальше автор приводит список антипаттернов для измерений

- Focusing on measurement when the bigger issue is a lack of trust.
- Letting perfect be the enemy of good.
- Using optimization metrics to judge performance.
- Measuring individuals rather than teams.
- Worrying too much about measurements being misused.
- Deciding alone rather than in community

Интересно, что этот список хорошо пересекается с антипаттернами из книги "Тирания показателей" ("The Tyrany of Metrics"), про которые я рассказывал раньше

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

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

Карта гипотез (Рубрика #Manangement)

Наконец-то дошли руки прочитать книгу Александра Бындю про стратегическое планирование. Вообще, это уже вторая книга Александра, предыдущая называлась "Антихрупкость в IT" и я раньше про нее уже рассказывал, а потом мы с Александром записали серию подкаста "Code of Leadership", где разобрали эту книгу. В новой книге Александр рассказывает фокусно про свой метод карты гипотез, который развивает идеи метода impact mapping от Гойко Аджича. Кстати, у Гойко есть книга "Impact mapping", про которую я рассказывал раньше. Собственно, Александ творчески расширяет этот подход и предлагает следующую структуру метода, которую он раскрывает в первой части книги "Структура карты гипотез"
1) Цель - по каким критериям в конце работы мы поймем, что достигли успеха
2) Субъект - тот, чью жизнь мы хотим поменять с помощбю гипотезы, чтобы изменение привело нас к цели
3) Гипотеза - формализованная идея, с помощью которой мы собираемся изменить поведение субъекта
4) Задача - список активностй, с помощью реализации которых мы будем проверять, насколько верны наши гипотезы
Основная суть изменений между impact mapping и картой гипотез в том, что в карте основной фокус на том, чтобы через гипотезы зафиксировать ответ на вопрос а почему мы думаем, что определенные задачи приведут нас к цели. Гипотеза формулируется в виде

Если <действие1> и <действие2> ..., то <следствие>, потому что <идея>

Во второй части "Тонкости составления карты гипотез" автор подробнее рассказывает о том, что цели надо ставить по SMART, субъектов надо описывать четко, а не аморфно "все потребители", гипотезы должны быть правильные по форме, в них должен быть смысл, задачи не должны висеть в воздухе и зачастую они объединяются в цепочки для выполненияя.
В третьй части "Этапы работ с картой гипотз" автор рассказывает как ее создавать и когда стоит прекратить, а потом делится подходом к валидации карты, который позволяет понять, а не фигню ли мы сделали.
В четвертой части автор рассказывает про преимущества подхода, которые включают в себя
1) Осмысленный подход к решению
2) Стратегию в виде схем как доступный способ ее коммуникации
3) Возможность варьировать реализацию
4) Конкурентное преимущество из-за четкой и гибкой стратегии
5) Фильтр для проектов без идеи (которые любят вкидывать сверху)
6) Передачу знаний внутри компании
7) Переключения майндсета с "затрат на проекты" на "инвестиции в реализацию стратегии"

В общем, вторая книга Саши Бындю мне понравилась больше. Видно, что он он пишет сфокусированно о том инструменте, который он использовал очень часто для работы со стратегией. И этот инструмент по моим ощущениям может быть достаточно эффективным. Подробнее про карту гипотез можно прочитать на сайте картагипотез.рф

#Software #SoftwareDevelopment #Management #Processes #Strategy #Leadership #ProductManagement

Research Insights Made Simple #2 - Обсуждение paper "Defining, measuring and managing technical debt" (Рубрика #Management)

Это второй выпуск подкаста с разбором научных статей, которые посвящены разным темам computer science и engineering management. В этом выпуске мне помогает мой коллега, Дмитрий Гаевский, Technical CPO (Chief Product Owner) нашей внутренней платформы разработки Spirit. Для второго выпуска мы взяли научную статью про технический долг и то, как он влияет на продуктивность инженеров. Эта статья от ребят из Google вышла в 2023 году.

Основные материалы
- Whitepaper доступен здесь
- Мой разбор whitepaper есть в блоге

В этом выпуске мы успели обсудить темы
- Исторический контекст и метафора технического долга
- Долг или инвестиции в качество кода
- Исследование технического долга в Google
- Категории технического долга в общем
- Категории, выбранные для исследования
- Измерение технического долга
- Проблемы с метриками и целевыми состояниями
- Концепция opportunity cost
- Проблемы с термином "технический долг"
- Управление техническим долгом
- Альтернативы термину "технический долг"
- Результаты работы с техническим долгом в Google
- Объединение объективных и субъективных данных
- Проблемы разделения технической и продуктовой работы
- Альтернативные подходы к техническому долгу

#Architecture #Software #Management #Leadership #Engineering #Podcast

What Is Your Definition of Software Architecture (Рубрика #Architecture)

Пока готовился к своему выступлению на ArchDays в пятницу, наткнулся на paper почти 15-летней давности от Software Engineering Institute с названием "What Is Your Definition of Software Architecture". В нем авторы сделали подборку определений архитектуры программного обеспечения с начала времен по 2010 год. Среди определений встречаются примечательные

1) Из книги "Documenting Software Architectures: Views and Beyond (2nd Edition)", Clements et al, AddisonWesley, 2010:
The set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both.
2) Из книги " Software Architecture in Practice (2nd edition)", Bass, Clements, Kazman; AddisonWesley 2003, которую я перечитывал пару раз
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
3) Из стандарта ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software Intensive Systems
Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
4) Из RUP (Rational Unified Process)
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition

В итоге, можно выделить следующие взгляды на программную архитектуру
- Высокоуровневая структура - организация системы, структурных элементов и их интерфейсов. Фокус на взаимодействии элементов
- Абстракция и композиция - архитектура представляет собой абстракцию, что скрывает реализацию. Такие абстракции позволяют проще думать о взаимодействиях компонентов. Эта тема была отлично раскрыта John Osterhout в книге "A Philosophy of Software Design", что я рассматривалась в 21 выпуске подкаста "Code of Leadership"
- Набор структур - этот набор позволяют комплексно размышлять о программной системе, в этот набор обычно включают элементы, их взаимосвязи и свойства
- Руководящие принципы - это история про governance:) Суть в том, что архитектура - это про принципы, политики, модели, стандарты. В общем, тут фокус на стратегическом роли архитектуры. Недавно я вспоминал книгу про "Continuous API Management", где тема governance была отлично раскрыта
- Компромиссы и принятие решений - это история про принятие фундаментальных структурных решений, что стоят дорого для будущего. Фокус на поиске компромиссов между функциональными и нефункциональными требованиями
- Архитектурные стили и паттерны - это практический подход, который фокусируется на выделении повторно используемых подходов к построению архитектуры. Недавно вспоминал про книгу "API Design Patterns"
- Коммуникация со заинтересованными сторонами - здесь фокус на том, что нам надо обсуждать и согласовывать архитектурные решения со стейкхолдерами для принятия дорогих решений.

В итоге, определений много и перефразируя Джорджа Бокса, все они неправильные, но некоторые полезны:)
Главное понимать их границы применимости и использовать по назначению. У меня вроде картинка за 20 лет работы в IT сложилась:)

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance #ArchBook

CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async (Рубрика #ComputerScience)

Я часто рассказываю про то, что надо знать базу для того, чтобы развиваться в software engineering. Но обычно сложно описать, а что же входит в это определение "база" и является джентельменским набором хорошего инженера. Но тут мой коллега, Женя Козлов, крутой инженер, написал серию статей про процессоры, модели памяти, многозадачность и конкурентность. В этой серии разбираются моменты, которые полезны инженерам, что делают высоконагруженные системы, которые плотно работают с данными. Собственно, сам Женя у нас лидит команду, что занимается Statist - это наша система продуктовой аналитики, которая давно заменила нам Amplitude и по всем характеристикам тянет на data intensive application. В общем, я очень рекомендую вам эту серию статей от Жени, если вам интересно понять как компьютер обрабатывает под капотом те программы, что вы пишите на своем любимом языке программирования.

1) Начальный пост про многозадачность в OS
2) Про развитие процессоров и взаимодействие OS с ними
3) Про Hyper Threading
4) Процессы. Начало
5) Процессы в Linux
6) Потоки. Начало
7) Потоки в Linux
😍 Модели ввода-вывода. Универсальная(блокирующая) модель ввода-вывода
9) Multiplexed IO
10) Asynchronous IO

#Software #ComputerScience #Engineering #SRE #Architecture

Code of Leadership (Рубрика #Management)

Примерно год назад я стартанул подкаст про engineering management с названием Code of Leadership. За это время получилось выпустить 21 эпизод, но я не планирую на этом останавливаться:) Подкаст доступен в Youtube и Ya Music.
Вот ссылки на материалы по каждому эпизоду:

1) Team topologies со Станиславом Халупом
2) "Antifragility in IT" с Александром Бындю
3) "Herding Cats" с Женей Кузовлевым
4) "Turn the ship around" с Екатериной Шестимеровой
5) "Project Phoenix" с Иваном Михеевым
6) Интервью про Staff+ инженеры, архитектура и SDLC с Алексеем Тарасовым
7) "Your brain at Work" с Эрнесто Инаркиевым
8) Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)
9) "An Elegant Puzzle - System of Engineering Management (часть 1)" с Eugene Sergueev
10) "An Elegant Puzzle - System of Engineering Management (часть 2)" с Eugene Sergueev
11) Интервью с Кириллом Крайневым про системных аналитиков в Тинькофф
12) Интервью с Димой Гаевским про платформу Spirit (Internal developer platform) в Тинькофф
13) "Accelerate" с Игорем Курочкиным
14) Interview with Artem Ivanov about Risk Tech
15) Interview with Roman Lebed about Information security
16) "The Five Dysfunctions of a Team" с Андреем Соколовым
17) Interview with Anton Kosterin about Architecture Governance
18) Interview with Pavel Akhmetchanov about Processes and Tools
19) Interview with Evgeny Sokolov about Modern Education
20) Interview with Alexey Grishin about Software Architecture
21) "A Philosophy of Software Design" с Гришей Скобелевым

#Architecture #Processes #Management #Leadership #Software #Statistics #Project #Productivity #ProductManagement

"Архитектура в Т-Банке: вчера, сегодня, завтра" на конференции ArchDays 2024 (Рубрика #Architecture)

Сегодня в 15.40 я выступаю на конференции ArchDays с докладом "Архитектура в Т-Банке: вчера, сегодня, завтра", в котором я расскажу про развитие подходов к проектированию и архитектуре в Т-Банке с начала времен и до текущего момента. Я постараюсь объяснить какие причины побуждали нас меняться и как мы осуществляли сами изменения. Я расскажу про процессы и людей, которые занимаются у нас проектированием и почему архитектор - это не должность, а роль. А закончу тем, что расскажу куда мы движемся дальше.

Вот дополнительные материалы для изучения, которые я рекомендую к своему выступлению
1) "Эволюция web’а tinkoff.ru за последние 3 года" (youtube) - мое выступление на ArchDays 2019, в котором я рассказываю как мы переходили от коробочного решения к собственной разработке в одном из доменов
2) "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения" (youtube, статья с расшифровкой) - мое выступление на ArchDays 2020, в котором я рассказываю про архитектурные подходы, к которым мы пришли по итогам масштабной собственной разработки и какую мы ставку делали на платформизацию
3) "DevOps-эры в Тинькофф: культура, люди, инструменты" - выступление моего бывшего коллеги Станислава Халупа на Kuber Conf 2021 года, где он рассказывал про platform engineering и почему это направления стало важным для нас (мое саммари по выступлению, само выступление на youtube)
4) "Technical Governance для IDP на 7000 разработчиков" - статья Дмитрия Гаевского про governance для нашей внутренней платформы разработки Spirit (это расшифровка его выступления на Highload++ 2021)
5) Раздел про технологии на нашем сайте - здесь можно почитать про наши платформенные решения
6) "Code of leadership #17 - Interview with Anton Kosterin about Architecture" (youtube, ya music, пост) - серия подкаста с Антоном Костериным, моим замом, который помогает мне строить architecture governance
7) "Research Insights Made Simple #1 - API Governance at Scale" (youtube, ya music, пост) - первая серия подкаста с разбором научных статей, где я с моим коллегой разбирал подход к API Governance в Google, а также мы активно проводили параллели с architecture governance в нашей компании
8) "Measuring Developer Goals" - мой обзор статьи от Google на тему того, куда стоит двигаться платформе разработки, чтобы оптимально поддерживать цели инженеров при разработке софта

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #SystemDesignInterview #DistributedSystems

Открытая менторинг сессия со мной на SouthHub (Рубрика #Management)

12 ноября в 19:00 я проведу открытую сессию менторинга на канале SouthHub. Менти выберут организаторы канала SouthHub, а подать заявку на участие может любой желающий. Запрос по менторингу может быть на одну из следующих тем
- Как выбрать орг. дизайн команд под задачи бизнеса: как понять, что требуется, как организовать команды.
- Как выстроить процессы в командах — discovery & delivery, архитектурные процессы и процессы обеспечения надежности.
- Как измерять эффективность процессов — какие метрики бывают и насколько им можно верить.
- Как осуществлять крупные изменения в больших компаниях.
- Как работать над техническим брендом параллельно с основной работой.

Сама сессия будет доступна в виде видео на канале SouthHub.

#Management #Leadership #Processes #Engineering #Software

Как стать продуктивнее в IT, если вы уже прокачали свои харды (Рубрика #Management)

Через 3 недели я выступлю на конференции soft weekend, первой софтовой офлайн-конференция в России (что бы это ни значило). Я не могу сказать, что люблю рассказывать чисто про софты, но эту конференцию организует мой знакомый, Андрей Смирнов, автор подкаста "Frontend Weekend", куда я ходил в гости в прошлом году. В итоге, я решил рассказать что-то из серии набора качеств и навыков, что важны для всех: и для крутых инженеров и для начинающих маркетологов. В этот список вошли
- Умение планировать свое время (а дальше если повезет и своей команды)
- Умение и желание брать на себя ответственность (и главное доводить сложные дела до конца)
- Навыки общения с коллегами и договороспособность (эта часть часто западает)
- Навыки самомотивации и мотивации окружающих (правда, если разбираться в вопросе, то внешняя мотивация - это скорее стимуляция)

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

Конференция пройдет очно 23 ноября в Пространстве Весна, Спартаковский п., 2с1. Купить билет можно здесь

#Leadership #Processes #Management

Ухожу в Stand Up! (Mastering Stand-Up) (Рубрика #Humor)

Это не утверждение, а название очередной книги, которую я дочитал буквально этой ночью. Книга попала ко мне интересным образом - пару месяцев назад меня позвали выступить на внутреннее мероприятие на всю компанию в формате стендапа. Я немного подумал над темами и выбрал одну из двух, про которые я обычно рассказываю - это была тема "Архитектуры", потому что про менеджмент шутили два других спикера. Как обычно, когда я сталкиваюсь с новой темой, то покупаю книги по ней - кажется, что еще с детства у меня пошла история о том, что получение книги == получению знаний из книги. В итоге, выступление на стендап я подготовил, но книгу прочитать не успел. Хорошо, что я заявился с этой же темой "Архитектура в Т-Банке: вчера, сегодня, завтра" на ArchDays и взял книгу в проработку. На прошлой неделе я рассказал этот доклад, а ночью дочитал последние страницы книги. Конечно, конференция по архитектуре - это не стендап-шоу, поэтому пришлось разбавлять шутки занудной теорией до гомеопатического состояния, но часть пользователей в отзывах к докладу отметила чувство юмора (ладно, это заметил один человек).

Если говорить о самой книге, то ее написал Стивен Розенфилд, основатель Американской школы комедии, который поставил обучение комиков на поток и в этой трехсотстраничной книге поделился своими рецептами становления хорошим стендапером. В книге 5 частей
1) Начинаем сотрудничать - в этой части автор подбадривает читателя и рассказывает о пути, который ему предстоит пройти, чтобы стать успешным: выясни в чем, твоя оригинальность, научись писать тексты для стендапа, отточи мастерство выступлений, придумай сценического персонажа, постоянно выступай и так далее
2) Виды стендап-комедии - здесь автор перечисляет виды, показывает примеры и объясняет разницу между ними. Например, он говорит о комедии наблюдений, сторителлинге, стендап-скетчах, акт-аутах, унижениях знаменитостей или людей из своего окружения, самоиронию, юмор на грани фола и так далее
3) Руководство по созданию материала для стендап-комедии - здесь автор рассказывает что делать до того как сесть за черновик, дальше как работать с черновиком, как обкатывать материал из него, как дорабатывать шутки формата сетап - панчлайн через фидбек аудитории на выступлениях (тут используется принцип working backwards для шлифовки и усиления шуток)
4) Руководство по выступлению со стендап-комедией - автор описывает что делать с волнением перед выступлением, как вести себя на сцене, как уложиться в регламент и что делать если шутка не зашла:)
5) Как добиваться непревзойденного мастерства - здесь автор рассказывает про классификацию шуток "A", "B", "C" и описывает как составить сет из шуток класса "А". Как создать удачный сценический образ, который должен быть оригинальным, правдоподобным, ярким, вызывать симпатию, иметь сценическое обаяние и смешную суть. Прикольно, что автор дает список причин почему шутка, которая раньше разрывала зал, стала уходить в тишину - а дальше он дает рекомендации как это можно исправить. Финалит последнюю часть автор рассказом про то, как быть ведущим и как победить свой внутренний голос, который мешает достигать своих целей (в данном случае быть смешным).

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

#Humor #PublicSpeaking #Leadership #SelfDevelopment

Обзор paper "Build Latency, Predictability, and Developer Productivity" (Рубрика #Management)

Я продолжаю читать и писать о статьях из серии developer productivity от исследователей из Google. В четвертом whitepaper с заголовком "Build Latency, Predictability, and Developer Productivity" речь идет про скорость сборок и как она влияет на продуктивность разработчиков (вот мой обзор). Эта связь кажется довольно очевидной, но авторы находят очень элегантный способ для измерений. Вообще, авторы в своей статье дают ответ на следующие вопрос

- How fast do builds need to be for developers to stay productive?
- Are there changes we can make to build systems besides just “make builds faster” to improve productivity?
- And how much of a productivity improvement can we reasonably expect by improving build latency, anyway?

P.S.
Вот список статей из этой колонки "Developer Productivity for Humans", большую половину из которых я уже разобрал раньше
1) A Human-Centered Approach to Developer Productivity - разбор у меня в блоге
2) Hybrid Productivity - разбор у меня я в блоге
3) Defining, Measuring, and Managing Technical Debt - разбор у меня в блоге
4) Build Latency, Predictability, and Developer Productivity - это сегоднящняя статья
5) Onboarding and Ramp-Up
6) Measuring Flow, Focus, and Friction for Developers
7) Software Quality - разбор у меня в блоге
😍 Creativity in Software Engineering

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