Публичные выступления на конференциях (Рубрика #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

Изучение 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

Code of Leadership #20 - Interview with Alexey Grishin about Software Architecture (Рубрика #Architecture)

В двадцатом выпуске подкаста "Code of Leadership" я общаюсь с Алексеем Гришиным, архитектором расчетных продуктов T-Bussines в Т-Банке. Алексей проектирует системы, налаживает архитектурные процессы, менторит коллег по архитектуре. На позиции архитектора работает уже около 10 лет, постепенно увеличивая масштаб и зону ответственности. Алексей - один из первых , кто затащил и поддерживает практику Event Storming в Т-Банке.

За час мы обсудили следующие темы
- Как Алексей пришел в компанию
- Как Алексей перешел к роли архитектора
- Переход Алексея в Т-Бизнес
- Выстраивание процесса управления архитектурой
- Согласование изменений
- Принятие решений
- Подходы с RFC и ADR
- Масштабирование архитектурного процесса
- Discovery и event storming
- Различия в восприятии контекста
- Сложности в применении event storming
- Продуктовый подход к developer experience
- Продажа изменений менеджменту
- Документирование решений
- Стоит ли расти в архитектора
- Практический подход к обучению
- Рефлексия и изучения опыта других компаний

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

How Amazon and Google view CI/CD in an entirely different way (Рубрика #Architecture)

Очень интересная статья про разные подходы двух крупных компаний к построению своих процессов CI/CD. Автор проработал суммарно 15 лет в инженерных командах, что занимались CI/CD инфраструктурой: сначала 11 лет в Amazon, потом 4 года в Google, а потом вернулся обратно в Amazon. И в этой статье он рассказывает, как отличчается школа мысли этих двух компаний к построению своих процессов CI/CD, фокусируясь на следующем трио
- Pre-submit - эта фаза относится к developer experience до сабмита кода. Собственно, автор разбирает то, какие проверки можно вкрутить на этом этапе в своем рабочем пространстве или как часть процесса code review
- Post-submit - это фаза относится к developer experience после сабмита кода. Как происходит merge изменений, как код развертывается в prod-like тестовых средах и прогоняются проверки там, и как код дальше выкатывается на прод
- Testing - автор в статье говорит про интеграционное и сквозное тестирования, а не модульное. Модульное тестирование тривиально для запуска в любом месте, но интеграционное тестирование требует, чтобы код-кандидат был развернут в тестируемой системе и связан с зависимостями, что добавляет экспоненциальный уровень сложности к инфраструктуре.

Дальше он говорит, что Google и Amazon по разному хостят свой код
- Google использует monorepo и весь код хранится в одном месте
- Amazon использует концепцию microrepos, где код отдельных сервисов хранится в отдельных репозиториях

И это отличие обуславливает разный подход к инструментам и фокусировке на разных этапах developer experience.

Если кратко, то Google крут в pre-submit проверках, так как сотни тысяч инженеров живут в общем репозитории, где нет отдельных бранчей. Blast radius при сабмите проблемного кода очень велик, поэтому они очень много инвестируют в разные крутые штуки на pre-submit (вот другая статья автора, где он рассказывает про это run end-to-end integration tests from a local dev environment, or a code review, against ephemeral, hermetic test environments). Но вот post-submit опыт совсем другой - код катится на прод совсем не часто. Суть здесь в том, что изменения разных инженеров накапливаются в батчи, по которым прогоняется большее количество тестов. Это сделано потому, что одна строчка кода может повлиять на большое количество deployments, поэтому запускать все проверки на каждый коммит точно не получится. Но расплата за это - долгое ожидание доставки кода на продакшен.

В Amazon код живет микрорепах, где blast-radius изменений ограничен твоим репо (по крайней мере, на pre-submit части). То есть, закоммитив что-то странное, ты легко навредишь только своим коллегам по 2-pizza-team. А дальше включаться post-submit проверки, которые не позволят раскатиться этому изменению. Поэтому в Amazon слабая автоматизация pre-submit части, но вот post-submit сделан сильно лучше, чем в Google. Отличие в том, что изменения в коде оказываются на проде в течение часов, а не суток.

Финализируя, автор говорит, что Google и Amazon выбрали разные подходы для борьбы со сложностью
- Monorepo ребят из Google работает за счет большой команды, что автоматизирует pre-submit и делает умную селективность тестов, позволяет им запускаться герметично и так далее, но код доставляется на прод долго. Но если требуются крупные изменения по кодовой базе, то их легче сделать в одной монорепе
- Microrepos ребят из Amazon проще менять и выкатывать новый фичевый код на прод, не опасаясь больших проблем. Но вот проблемы с обновлением зависимостей в разных репозиториях - это боль. В итоге, автор статьи отмечает, что поддерживать подход Amazon можно гораздо меньшей командой
И тот и другой подход имеет право на жизнь и фактически задает некоторую школу мысли для своих адептов:) Автору больше нравится подход Amazon

Ну и на самом деле круто скомбинировать крутой опыт на pre-submit и на post-submit, но часто это слишком дорого, поэтому имея ограниченные ресурсы инфра команды фокусируются на самом важном в их условиях.

#CI #SRE #Architecture #Software #Infra #QA