Code of Leadership #19 - Interview with Evgeny Sokolov about Modern Education

Интервью с Евгением Соколовым, доцентом факультета компьютерных наук НИУ ВШЭ, про то, как выглядит современное образование для software development engineers (Youtube, Yandex Music). Евгений руководит бакалаврской программой «Прикладная математика и информатика», преподаёт машинное обучение. В 2014-2019 годах работал в Яндексе, где успел позаниматься внутренними инструментами для ML, проектами по DS для внешних заказчиков, рекомендательными системами в Дзене.

В этом выпуске мы обсуждаем темы
- Как Евгений пришел в образование из индустрии
- Как ВШЭ выстраивает свое партнерство с компаниями на рыке
- Философия образования
- Архетипы студентов на факультета компьютерных наук (ФКН) ВШЭ
- Продуктовый подход
- Важность фундаментальных знаний 
- Важность понимания дизайна
- Практическое применение знаний
- Взаимодействие с новыми сотрудниками
- Обсуждение дизайна и преподавания
- Типы преподавателей и их привлечение
- Преподаватели из индустрии
- Советы для преподавателей

#Architecture #Software #Management #Leadership #Processes #Education

Обзор whitepaper "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency" (Рубрика #Architecture)

Недавно я прочитал очень интересное исследование на тему API Governance от академических исследователей и специалистов из Google. Целью исследования было понимание влияния подходов к управлению API (application programming interface) на продуктивность и usability. По итогам этого research исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API. Мне это исследование показалось интересным для написания обзора, так как последние годы я имею отношение на работе к темам
- Architecture governance
- Development productivity
- API management
А этот whitepaper имеет отношение к каждой из этих тем:)

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

В итоге, авторы написали план по углублению и расширению исследований, который поможет точнее оценить эти эффекты, а может быть и лучше натренировать API Architect (файнтюненную LLM), которая помогает с написанием API спек.

Подробнее про этот whitepaper можно почитать в моей статье

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

Sber Enterprise Architect Framework (SEAF) (Рубрика #Architecture)

Интересное выступление про корпоративный архитектурный фреймворк от Сбера, которая позволяет посмотреть на один их подходов к документированию архитектуры.

Основные тезисы, что я почерпнул для себя
- Этот фреймворк делала несколько лет команда экспертов для для решения проблем управления архитектурой и обеспечения его интеграции в производственный процесс
- Философское наполнение этого фреймворка описано в статье "Архитектор 2.0" на Хабре
- Фреймворк не противопоставляет себя другим фреймворкам, а скорее дополняет их, накапливая и оцифровывая практики - в иллюстрациях приведены DDD, TOGAF, C4 Model, ...
- Фреймворк содержит внутри себя инструменты, пркатики, методологию и артефакты (хорошо, что онтологий нет)
- Целью фреймворка создать цифровую модель предприятия, которая будет иметь неоспоримые характеристики и позволит производить производные.
- Инструментом для автоматизации является DocHub, который я отношу к категории инструментов architecture documentation as a code
- Инструмент позволяет создать рабочее место для архитекторов разных мастей, которые теперь будут рисовать на квадратики и стрелочки для визуализации - теперь они смогут писать это в yaml файлах. Все также как и раньше будет дуализм: 1) то, что происходит в коде и на инфраструктуре и 2) то, что нарисовал архитектор в своих yaml. Зато теперь это можно называть as a Code
- Фреймворк подходит для федеративного управления архитектурой, которая может быть расширяема и адаптирована под нужды каждого домена
- В списке инструментов есть пакетный менеджер, который позволяет скачивать и управлять пакетами с метаданными.
- SEAF стимулирует сообщество к адаптации фреймворка под свои нужды и использовании успешных методологий
- Автор агитирует к переходу от архитектора 1.0 к архитектору 2.0. Архитектор 1.0 - это человек, который визуализирует визуальную схему и модель, в то время как архитектор 2.0 - это человек, который создает архитектуру и постоянно работает над улучшением и заимствованием практик.
- В докладе автор рассказывает про метамодель, которая описана еще и на Github

- Для структурирования метамодели выбран подход разделения ее на слои и вертикали.
- Слои выделяют функциональные области, в то время как вертикали пронизывают их и связывают.
Выделяются слои:
- Бизнес-архитектура;
- Прикладная архитектура;
- Техническая архитектура.

Вертикали:
- Информационная архитектура;
- Управление требованиями.
- Важным принципом метамодели является - адаптивность. Она должна легко подстраиваться под нужды использования. Предусматривать частичное применение, возможность расширения и модификации.
Таким образом, решение о фактическом объеме использования метамодели предоставляется пользователю.

В общем, это хорошая попытка создания фреймворка для реализации подхода architecture documentation as a code.

P.S.
На тему управления архитектурой уже было недавно несколько постов, которые тоже интересно почитать
- Архитектура как код - Роман Пионтик - ArchDays 2022
- Архитектурный репозиторий на базе GitLab и C4 Model для большой компании - Кирилл Ветчинкин - ArchDays 2022
- Материалы к моему докладу "Architecture at T-Bank: how we design our solutions"
- Раз архитектура — «as Code», почему бы её не покрыть тестами?!
- Проводим архитектурное ревью продуктовой фичи
- Опыт использования подхода «Архитектура как код» в ГК Самолет - Роман Пионтик, Валентин Козлов - ArchDays 2023
- Генерация архитектурных схем и метаданных - Кирилл Ветчинкин - E-community 2023

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

"Founder Mode" и "Notes on Founder Mode" (Рубрика #Management)

Недавно я рассказывал про интересное интервью Брайана Чески, CEO и co-founder Airbnb (1 и 2). В этом интервью Брайан говорил о том, как он поменял схему управления компанией от сильно распределенной обратно в режим основателя компании (founder mode). Брайан подробно объяснял что его побудило сделать такие изменения, а также то, чего они добились со времени изменения.

Недавно, а точнее в сентябре, вышла статья за авторством Paul Graham, сооснователя Y Combinator. В этой статье Пол рассматривал "founder mode" и "manager mode" и отмечал, что до этого момента масштабирование стартапа в Кремниевой Долине неявно предполагало переход от режима основателя к режиму менеджера. Но пример Брайана показывает, что это не обязательно идет компании на пользу. Пол даже вспоминает Стива Джобса и его выезды с ключевыми сотрудниками, которые не относились к самым высоким чинам в корпоративной иерархии. А это нарушает этот иерархичный организационный подход из manager mode

Whatever founder mode consists of, it's pretty clear that it's going to break the principle that the CEO should engage with the company only via his or her direct reports. "Skip-level" meetings will become the norm instead of a practice so unusual that there's a name for it. And once you abandon that constraint there are a huge number of permutations to choose from. For example, Steve Jobs used to run an annual retreat for what he considered the 100 most important people at Apple, and these were not the 100 people highest on the org chart.

Дальше вышла понравившаяся мне статья Anu Atluru, в которой разбирались тезисы Пола Грехема. Вот основные тезисы из нее:
1) Most founders are in “founder mode” and most of them fail anyway
- Most early-stage startup founders are in founder mode by default
- Many founders are first-time founders with zero management experience.
- Founder mode has a dark side risk that can hurt the company and employees
2) Companies don’t fail because founders switch leadership modes. They fail because the mode switch is set up to fail, ill-timed, and rigid
Сценарии, когда classical management приводит к проблемам
- There’s no clear vision and strategy for the company
- The people being managed aren’t the right fit for the job.
- The context is evolving while the “leadership mode” stays rigid.
3) The best CEOs (founder or not) know how to switch between founder mode and management mode — and when they need either one
- Founder mode is akin to the wartime CEO mode. Management mode is more akin to peacetime CEO.
- “Founder mode” and “management mode” can’t be seen as static opposites.
4) A founder’s unique leadership style will put them in their zone of genius and make them happy (mostly)
- Founders need to find their own ideal leadership mode
- The tricky part? It takes practice to figure out.

В итоге, мне кажется, что это очень важные вопросы для крупных компаний, которым важно не застыть во времени и пространстве, а оставаться гибкими и способными реагировать на рыночные изменения и появление конкурентов. Актуально в этом плане посмотреть на Intel и как они из лидера рынка превратились в аутсайдера, которого Qualcomm планирует выкупить и распродать дальше по частям:)

#Management #Leadership #Processes #Engineering #Project #Software #Design #ProductManagement #BusinessStory

When to write strategy, and how much? (Рубрика #Management)

Интересная статья про создание стратегии от Will Larson (Lethain) в его крутом блоге. Кстати, Вилл написал уже три книги, каждую из которых я прочитал и каждая по своему мне понравилась:)
Собственно, эта статья представляет главу из еще не написанной книги на тему стратегии. Здесь Вилл размышляет о том, когда пора писать стратегию и насколько она должна быть обширной.
Вот основные мысли, что я извлек для себя
1) Когда писать стратегию?
Организация может быть в трех стратегических состояниях: глобально консистентном (все понимают что и зачем делают), консистентным внутри отдельных команд, совсем разобранном, когда у инженеров мало согласия относительно того, как решать задачи. Собственно, смысл в формализации стратегии есть, если есть неконсистентность. С другой стороны многое зависит от того, куда направлен тренд изменений - если все идет не туда, то есть смысл делать стратегические изменения:) Но даже если все идет не туда, то надо сначала оценить насколько вы понимаете происходящее в организации для написания полезной стратегии. Эффект от стратегии может сведен на нет, если организация слишком часто меняет направление.
2) Насколько много должно быть стратегий?
Это важный вопрос, так как стратегий относительно разных активностей может быть много, но если не ограничивать WIP (work in progress), то по каждой из них результаты будут мизерными. В итоге, тут важна приоритизация и выделение самого важного. Заодно можно часть вещей делать не фундаментально на все времена, а начинать по шагам, которые не пугают участников своим объемом, но приближают вас к цели
3) Масштаб и высота стратегии
Здесь Вилл предлагает поделить стратегии на разрешительные и запретительные. Первые предлагают вариант решения аля (golden path), но не запрещают остальные варианты. В итоге, движение по такому пути выглядит менее напряжным для участников и растягивается во времени. По-факту, тут работа идет через доработку golden paths и adoption инструментов. В запретительных стратегиях есть разрешенный вариант, а все остальное запрещено. Возможны эскалации, но они должны быть единичны. Это более жесткий и быстрый путь. В итоге, разрешительных стратегий может быть запущено одновременно больше, чем если мы будем делать те же самые изменения через запретительные стратегии. Суть в том, что они требуют меньше усилий.
4) Не слишком ли много стратегий вы имплементируете?
Вилл парадоксально отмечает, что хоть и многие инженеры в компаниях считают, что у их компании нет четкой инженерной стратегии, но гораздо больше руководителей терпят неудачу, пытаясь много работать над стратегией, а не мало:) Определить это можно, оценив насколько прошлые стратегические инициативы, повлияли на последующие решения.

P.S.
Книги Вилла в порядке их выхода
- "An Elegant Puzzle" - мой рассказ о книге
- "Staff Engineer" - мой рассказ о книге
- "The Engineering Executive's Primer" - мой рассказ о книге

The Rise of the CAIO (Рубрика #Management)

Недавно мне на глаза попаслась забавная статья про найм CAIO - Chief AI Officers. Я ничего не имею против разнообразных CxO, но по этим новым неймингам можно отслеживать тренды хайпа. Я попробовал вспомнить что из интересного появлялось или набирало популярности за последние 20 лет
- CTO - Chief Technology Officer - когда технологии стали модными
- CKO - Chief knowledge officer - когда стала популярна идея про обучающиеся организации Питера Синге
- CGO - Chief Growth Officer - последние 15 лет, когда все гнались за бешенным ростом (пример с контентными платфомами и соцсетями)
- CDTO - Chief Digital Transformation Officer - когда все внезапно загорелись цифровой трансформацией (даже изначально не digital бизнес)
- CDO - Chief Data Officer - когда данные стали называть новой нефтью
- CAIO - Chief Artificial Intelligent Officer - когда все побежали заниматься искусственным интеллектом
B общем, интересно какой тип C...O нас ждет дальше:)

P.S.
Отдельно отмечу, что часто после появления термина начинается его инфляция - я видел примеры, когда помимо главного CTO и остальных технических руководителей начинали называть CTO примерно так
- CTO больших продуктов (~500 инженеров)
- Дальше CTO отделов (~70 инженеров)
- Дальше CTO команд (~ 10 инженеров)
Финальной точкой может быть сам себе режиссер CTO:)

#AI #Management #Humor #Future

Публичные выступления на конференциях (Рубрика #PublicSpeaking)

Я начал выступать на конференциях около шести лет назад на Teamlead Conf, где я рассказывал про тимлидов во фронтовых командах нашего публичного веба тогда еще Тинькофф. Для меня это был во многом пугающий опыт, так как до этого на конференциях я не выступал. Но, оглядываясь назад, я могу сказать, что тот опыт мне сильно помог вырасти с какой стороны не посмотри и я смог
- Стрктурировать свои знания по управлению разработкой, образованию команд и прокачке своих инженеров, многие из которых стали тимлидами. Подготовка к докладу очень хорошо помогает проверить насколько ты действительно разобрался в теме и закрыть определенные пробелы
- Познакомиться с крутыми ребятами, которые решали похожие проблемы и почерпнуть их опыт
- Вырасти как лидер - мне стало гораздо проще доносить свои мысли просто и понятно и вести ребят за собой
- Начать нарабатывать авторитет как эксперт в управлении разработкой, а потом и в проектировании софта
Это все дальше мне помогло и в карьере - этот опыт и навыки сработали в плюс, когда я решал свои рабочие вопросы в Т-Банке, где я уже работаю почти 8 лет.

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

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

P.S.
Кстати, я уже достаточно часто рассказывал про публичные выступления раньше
- Talk Like TED (Презентации в стиле TED)
- The Hero with a Thousand Faces (Тысячеликий герой)
- К выступлению готов. Презентационный конструктор
- Memo
- Убеждай и побеждай
- Пиши, сокращай
- Вредные советы для спикеров
- Риторика. Поэтика
- Драматика или поэтика рациональности
- Магия общения
- Откровения оратора (Confessions of a Public Speaker)
- Выступление в стиле TED. Говорю. Слушаю. Слышу (How to be heard. Secrets for powerful speaking and listening)
- Как сторителлинг сделал нас людьми (The Storytelling Animal: How Stories Make Us Human)
- Черная риторика. Власть и магия слова (Schwarze Rhetorik - Macht und Magie der Sprache)
- В голос! Нескучное руководство по созданию подкаста
- Randy Pausch Last Lecture: Achieving Your Childhood Dreams
- Успешная короткая презентация
- Искусство словесной атаки. Практическое руководство (SchlagFertigkeit. Das Arbeitsbuch)
- Корпоративная презентация. Как продать идею за 10 слайдов
- Курс подготовки спикера от Кирилла Анастасина
- 100 главных принципов презентаций (100 Things Every Presenter Needs to Know About People)
- Говори на языке диаграмм (Say it with Charts)
- Сделано, чтобы прилипать. Почему одни идеи выживают, а другие умирают (Made to Stick. Why Some Ideas Survive and Others Die)
- Последняя лекция. Мудрая книга о силе мечты (The Last Lecture)

#PublicSpeaking #SelfDevelopment

Обзор whitepaper "Secure by Design at Google" (Рубрика #Architecture)

Недавно я прочитал интересный whitepaper от Chirstoph Kern на тему security с человеческим лицом от Google, где рассказывалось о том, как создавать безопасный софт на большом масштабе. Начинается статья с того, что для security экспертов самоочевидно, что вопросы безопасности должны рассматриваться как интегральная часть дизайна софтовых продуктов и добавление безопасности уже после создания продукта обычно заканчиваются неудачей. А что с этим можно сделать автор рассказывает уже дальше. И если немного спойлерить, то автор отмечает, что security posture софтверных продуктов и сервисов является эмерджентным свойством developer ecosystem, в рамках которой проектируются, имплементируются и деплоятся приложения. А значит эта экосистема должна быть создана определенным образом так, чтобы позволять на этапе проектирования и написания кода сделать его безопасным by design. В самом whitepaper приводится достаточно много примеров о том, как это сделано в Google.

Подробнее с обзором можно ознакомиться в моем блоге.

P.S.
Я уже участвовал в паре подкастов про безопасность, где мы обсуждали shift left security и secure by design
- [SafeCode Live] Secure by design
- Code of leadership #15 - Interview with Roman Lebed about Information security

и упоминал про пару книг
- Building secure and reliable systems - я про нее уже как-то рассказывал
- Agile Application Security

#Software #Security #Infosec #SystemDesign

The way we play. Theory of game design (Гейм-дизайн. Как создаются игры) - Part II (Рубрика #Design)

Продолжая рассказ про книгу о геймдизайне Майкла Киллика (Michael Killick), начатый ранее, я хотел рассказать кратко об оставшихся главах

3. С бумаги на экран - как строить сюжетную линию, какие типы персонажей бывают (смешной, героический, ...). Как выстроить геймплей, передвигаться по миру, залезать на возвышенности, прыгать, плавать. Какие варианты взгляда на мир есть: 2D, 2.5D (изометрический), 3D, от первого лица, от третьего лица
4. Контроллер персонажа от первого лица на Unity - практический пример как при помощи Unity сделать демку с видом от первого лица и очень простым миром. Тут автор объясняет как пользоваться Unity и приводит куски кода для базовой настройки демки
5. Управление миром - дизайн уровней - как строить карты, как управлять персонажем, как выстраивать обучение для новых игроков
6. Друг или враг? Дизайн противников - как сделать противников интересными и разнообразными. О том, что у них могут быть разный размер, поведение, скорость, подход к перемещению, атаки, здоровье и так далее. Отдельно автор отмечает важность создания боссов:)
7. Механика, система боев и мультиплеер - здесь автор рассказывает про важное трио, где нужно проработать механики игры, а также боевую систему. После этого уже можно думать про многопользовательскую игру
8. Руководство по созданию 2D-платформеров - еще один пример с Unity, но теперь про создание простенького платформера
9. HUD и UI. Что это такое? - как правильно задизайнить экран (heads-up display), который видит игрок. И тут речь не про основное зрелище, а про вспомогательные элементы: индикатор здоровья, боеприпасов, выносливсти, мини-карта и так далее. Отдельно автор отмечает, что можно делать статический HUD или динамический, который появляется только в некоторых случаях
10. Совет напоследок - автор говорит о важности создания реалистичных целей при создании игры, создании game design документа и следования ему, а также работе в команде, что часто позволяет довести до ума даже сложный проект.
11. Совет или начало - здесь автор подбивает саммари по книге и завершает мотивирующим

Но прежде чем начать делать первые шаги - в дизайне, поиске работы или в освоении нового навыка, - важно запомнить главное: какой бы крупной или амбициозной ни была ваша идея, сохраняете упорство и продолжайте ей следовать! Осознание того, что вы преодолели серьезные препятствия и достигли поставленной цели, - прекрасное чувство. Всегда сосредотачивайтесь на конкретной задачи и никогда не бойтесь быть креативным и показывать свои способности. Все великое начинается с малого!

P.S.
Я стал больше интересоваться гейм-дизайном после того, как мой сын поступил в этом году в бакалавриат по этому направлению.
Но и до этого я много писал на тему игр и геймдизайна
- The Making of Prince of Persia
- Геймдзайн (Designing games. A guide to engineering experiences)
- Minecraft: Мобиология (Minecraft: Mobestiary)
- Кровь, пот и пиксели (Blood, sweat and pixels)
- Настольная игра "Нефариус"
- Настольная игра "Корпорация Гоблинов" (Goblins Inc)
- Прогейминг, Overwatch, киберспорт (Young guns: obsession, owerwatch, and the future of gaming)
- Мастера Геймдизайна (Game Designer Confessions: Insights from Finland's Top Game Designers)
- Мальчик, сделанный из кубиков (A Boy Made of Blocks)
- Настольня игра "Бумунту"
- Документальный фильм про AlphaGo
- Настольная игра "Ужасы Аркхэма"

#Games

Изучение whitepapers (Рубрика #Architecure)

В последнее время я изучаю много whitepapers для того, чтобы ответить для себя на экзистенциальные вопросы относительно того, как правильно выстраивать процессы разработки софта. Меня интересуют темы developer productivity, system design, software architecture и так далее. Причем большая часть прочитанных whitepapers напрямую относится к моей работе в Т-Банке. И я решил стартануть отдельный подкаст с обсуждением разобранных whitepapers, куда я тоже буду звать гостей, с которыми мы будем обсуждать эти крутые статьи. Пока я не придумал название для подкаста, так что в комментах можете накидывать предложения. На фото изучение очередного whitepaper на этот раз про "API Governance at Scale" by Google

P.S.
Вот примерный список обзоров whitepapers, что я уже разбирал и хотел бы обсудить с гостями
- Обзор whitepaper "Secure by Design at Google"
- Обзор whitepaper "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency"
- Обзор whitepaper "CNCF Platforms White Paper"
- Обзор whitepaper "Deployment Archetypes for Cloud Applications"
- Обзор whitepaper "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google"
- Обзор whitepaper "AWS Fault Isolation Boundaries"
- Обзор whitepaper "Architecture Anti-patterns: Automatically Detectable Violations of Design Principles"
- Обзор whitepaper "Lifting the veil on Meta's microservice architecture: Analyses of topology and request workflows"

- Обзор whitepaper "A Human-Centered Approach to Developer Productivity"
- Обзор whitepaper "Measuring Developer Goals"
- Обзор whitepaper "Developer productivity for Humans, Part 7: Software Quality"
- Обзор whitepaper "Improving Design Reviews at Google"
- Обзор whitepaper "The SPACE of Developer Productivity"
- Обзор whitepaper "DevEx in Action"
- Обзор whitepaper "DevEx: What Actually Drives Productivity"

Если у вас есть опыт в одной из тем и желание обсудить ее со мной на подкасте, то пишите в личку

#Whitepaper #Architecture #Management #Science