Почему ваша амбициозность в Европе может обернуться одиночеством | Евгений Кот (Рубрика #Culture)

Интересное интервью, что дал Евгений Кот Кириллу Мокевнину в рамках подкаста Кирилла. Ребята говорили о культурном коде в мире IT. Евгений много выступал на конференциях до того, как уехал в Прагу в качестве директора по инжинирингу во Wrike. Сейчас Евгений является VP of Engineering в стартапе rarible.com про NFTs, а также о ведет подкаст "Доктор Кот". Темой выпуска стали культурные различия в IT-индустрии и их влияние на карьеру разработчика.

Вот основные 10 ключевых тем
1) Культурный код отличается в разных странах, поэтому важно адаптироваться к локальным культурным особенностям для успешного взаимодействия. Рекомендую почитать книгу "The Culture Map", про которую я рассказывал раньше
2) Языковой барьер и акцент — несовершенное владение языком влияет на профессиональное восприятие и нервную систему специалистов, а также способы адаптации к этой проблеме.
3) Важность софт-скиллов в разных странах — обсуждение важности "мягких навыков" в США, Европе и России, с акцентом на то, что дело не в "правильности", а в культурных особенностях.
4) Токсичность и культурные различия в IT — ребята обсудили сравнение проявлений токсичности в разных IT-культурах: в России — прямолинейность, на Западе — токсичность часто скрывается за формальностями.
5) Культурные подходы к увольнениям — В США увольнения часто происходят моментально, в то время как в Европе процесс более формализован и занимает больше времени.
6) Амбиции и работа в Европе — амбициозным специалистам бывает сложно реализоваться в Европе, где ценится стабильность и баланс работа-жизнь.
7) Принятие решений и эскалация конфликтов — ребята обсудили различные модели решения рабочих конфликтов: прямое обсуждение vs эскалация через менеджмент.
8 ) Дебаты и их важность для экспертов — тут пошла речь о культуре публичных выступлений и дебатов, которую в США развивают с детства, и как это влияет на профессиональный успех.
9) Воспитание и культурные установки — детство и воспитание в разных странах влияет на профессиональное поведение и способность к интеграции в международных командах.
10) Возрастные программисты и стигма — как отношения к возрастным разработчикам в разных странах и как с возрастом меняется отношение к программированию.

Если подводить итог, то это интервью стоит посмотреть, если хочется чуть шире взглянуть на мультикультурные вопросы, которые Кирилл и Евгений рассказывают не просто теоретически, а делятся своими историями и байками из опыта работы в IT в других странах.

#Culture #Management #Leadership #Engineering

Code of Leadership #38 - Interview with Dmitry Kotelnikov about origination platform and reliability (Рубрика #Management)

В очередном выпуске подкаста ко мне пришел интересный гость, Дмитрий Котельников, с которым мы обсудили origination процессы и вопросы обеспечения их надежности. Дима работает в Т-Банке уже 8 лет и все это время занимается онбордингом новых клиентов, а сейчас руководит платформой Origination, а также развивает RnD направление AI миграций и участвовал в запуске стрима Staff инженеров, о которых мы как-то говорили в выпуске с моим коллегой Лешей Тарасовым

За час мы успели обсудить следующие темы
- Знакомство с гостем
- Выбор университета и развитие навыков
- Начало карьеры и первые рабочие задачи
- Архитектурные изменения и рост компании
- Развитие инфраструктурных инструментов
- BPM и сложности бизнес-процессов
- Надежность, интеграции и инструменты мониторинга
- Структура платформы origination
- Технические аспекты и общие компоненты платформы
- Управление потребностями продуктов и вызовы платформы
- Переход от инженера к менеджеру и рекомендации для развития

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

[1/3] Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем? (Рубрика #Architecture)

Сегодня я выступаю на конференции Positive Hack Days в Лужниках с заявленной выше темой. А тут я напишу тезисы и дам отсылки к дополнительным источникам

1) Почему стоит обсуждать эти темы сейчас
- Средняя стоимость сбоев растет и сейчас стоит порядка $300k/hour - подробнее в отчете "Hourly Cost of Downtime - ITIC 2024" (вот мой рассказ)
- Средняя стоимость утечек данных растет и стоит примерно $5M/breach - подробнее в отчете "IBM Cost of a Data Breach Report 2024" (вот мой рассказ в 2 частях: 1 и 2)
- Средняя сложность систем растет (облака, микросервисы, быстрые изменения) - все это приводит к тому, что надежность и безопасность обеспечивать становится сложнее
2) Почему это надо обсуждать на уровне системы и процессов (эмерджентность)
- Про это очень хорошо написано в whitepaper “Developer productivity for Humans: Software Quality” от ребят из Google (я уже рассказывал о нем). Суть в том, что для получения качественного продукта надо правильно выстроить процесс (условно, хочешь хорошую колбасу на мясокомбинате, то будь добр выстроить процессы с учетом ISO 9000). Это верно и для разработки и тут мы гонимся за эмерджентными свойствами (хорошая архитектура, надежность, безопасность), то есть за теми свойствами системы в целом, которые не присутствуют ни в одном из ее отдельных компонентов, но возникают в результате взаимодействий и отношений между этими компонентами. Подробнее про эмерджентность рекомендую почитать в Wiki, а также в кинге физика Девида Дойча "The Fabric of Reality: The Science of Parallel Universes" ("Структура реальности"), о которой я писал раньше
3) Подходы к надежности и безопасности
- Надежность популяризировал Google через культуру SRE - есть три ключевые книги: "SRE Book", "SRE Workbook", "Building Secure & Reliable Systems", о которых я уже тоже рассказывал
- Безопасность двигалась в сторону DevSecOps и Security by Design, где первое хорошо раскрывалось в давней книге "Agile Application Security" (я уже рассказывал про нее), то второе хорошо раскрыто в whitepaper "Security by Design at Google", который я тоже разбирал. Суть всей истории, чтобы безопасность сдвигалась влево и была интегрирована в процессы разработки
4) Подходы к архитектуре и проектированию решений
- ATAM (architecture tradeoff analysis method) - хороший подход к проектированию решений от Software Engineering Institute (SEI), который в том или ином виде часто используется при проектировании для снижения рисков. В этом подходе у нас есть целевые функциональные сценарии, сопутствующие им архитектурные характеристики, которые часто влияют друг на друга и нам требуется принимать решения о компромиссах между ними. Вообще, про этот подход есть хороший рассказ в книге "Software Architecture for Busy Developers", про которую я рассказывал. Кроме того для учета рисков часто используют подход с построением матрицы рисков
- А для учета рисков безопасности в дизайне хорошо бы использвать threat modeling. В итоге, у нас из ATAM есть не только функциональные сценарии, что нам надо реализовать в системе, но еще есть из Threat modeling сценарии угроз, которые надо предотврать
5) Case studies от лидеров индустрии
- Google - про него я много рассказывал и в контексте SRE и Secure by Design, но тут разве что добавлю их motto: "Hope is not a strategy", а также вспомню, что для проверки того, что все учтено на этапе проектирования у них есть design review процесс, про который они рассказывали в whitepaper "Improving Design Reviews at Google" (вот мой обзор)
- Netflix сделал ставку на хаос (Chaos Monkey и далее), чтобы обеспечивать resilience своим системам. Подробнее можно почитать книгу "Chaos Engineering", про которую я писал
- Amazon выбрала себе слоган "At Amazon, security is job zero", вот, например, раздел про культуру безопасности на сайте AWS

Продолжение в следующем посте, так как в один все не влезло:)

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering

[2/3] Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем? (Рубрика #Architecture)

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

Ну и начнем мы с того, что у нас внутри компании есть developer ecosystem, которая представлена PaaS платформой Spirit, которая состоит из большого количества составляющих. Но начать надо с принципов, которым ребята следуют при создании платформы

— Повторяемость и прозрачность жизненного цикла кода в рамках процессов поставки. Код проходит одни и те же стадии: написание, сборка, разные формы тестирования, обновление документации, выкатка в среды, контроль качества после выкатки, поддержка и вывод из эксплуатации. Важно, чтобы любой разработчик мог понять, что происходит и какие стадии процесса ему нужно пройти.
— Управление кодовой базой и оценка ее качества на всех этапах. Качество кодовой базы — одна из главных характеристик технического продукта. Умение держать его на стабильно высоком уровне — показатель устойчивости и зрелости процессов разработки.
— Переход к Inner Source в компании. Переиспользование кода и наработок коллег — большой плюс для компании. Это помогает уменьшить стоимость разработки и увеличить скорость поставки бизнес-фич. Платформа должна помогать шерить код быстро и безболезненно.
— Ориентация на результат. Когда у разработчика есть все необходимые инструменты для управления жизненным циклом продукта, это экономит массу времени. Становится проще создавать новые фичи и чинить старые, запускать тесты и многое другое. Мы хотим, чтобы разработчики могли тратить на создание бизнес-фич 80% рабочего времени, не отвлекаясь на рутину и сложности инфраструктуры. В конечном итоге от этого выигрывают пользователи.

Составляющие платформы представлены на схеме, но если отмечать некоторые особо важные для надежности и безопасности, то это
- Sage - observability платформа, использующаяся для централизованного сбора и анализа телеметрии всех сервисов компании. Sage обеспечивает прозрачность бизнес-приложений и ИТ-инфраструктуры и помогает поддерживать бесперебойность работы сервисов.
- FineDog - платформа инцидент-менеджмента, которая помогает Т-Банку оперативно выявлять сбои в работе сервисов, сокращать время их устранения и предотвращать повторение одинаковых инцидентов.
- Nestor - copilot для code suggest и чата внутри IDE, а также других инструментов около кода и не только.
- Safeliner - это AI-ассистент по информационнои‌ безопасности для команд разработки, который может работать как внутри шагов CI/CD, так и быть интегрирован в IDE в качестве плагина.
Одновремено, надо отметить, что ребята из Spirit активно работают над темой developer experience и они про это рассказывали в докладе "Почему DevEx важен при разработке IDP и как его померить" (я про него рассказывал). Это позволяет им собирать метрики инженерного опыта и определять, а что внутри платформы требует улучшений.

Но это конечно здорово иметь уже зрелую платформу и выстроенные процессы вокруг надежности и безопасности, а что делать если такого в вашей компании нет?

Для изменений надо
- На уровне стратегии компании сделать эти вопросы приоритетными, определиться с понятными целями (и поставить их в OKR), согласовать выделение ресурсов
- На уровне культуры компании сделать так, чтобы security & reliability стали общей ответственностью команд
- На уровне архитектуры и проектирования учитывать эти архитектурные характеристики и использовать лучшие практики
- На уровне процессов они должны быть интегрированы в pipelines (devsecops и shift left)

Ну и все этим надо управлять как большим проектом изменений, используя change mgmt подходы

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering

Критическое мышление. Железная логика на все случаи жизни (Рубрика #Thinking)

Эта книга Никиты Непряхина и Тараса Пащенко, позиционируется как практическое руководство для подростков, стремящихся развить навыки мышления. Моя жена купила его для детишек, а я решил прочитать и оценить как детей учат анализировать информацию, отличать факты от мнений, противостоять манипуляциям и принимать обоснованные решения. Изложение очень доступное, используются примеры из повседневной жизни. В книге рассматриваются следующие темы
1. Распознавание стереотипов и когнитивных искажений. На примерах из школьной жизни объясняется, как социальные шаблоны влияют на восприятие реальности.
2. Механизмы формирования суеверий и мифов. Разбираются психологические причины веры в иррациональное, включая эффект подтверждения и склонность к упрощённым объяснениям.
3. Влияние общественного мнения на принятие решений. Анализируются случаи конформизма и группового мышления, актуальные для подростковой среды.
4. Разграничение фактов и оценочных суждений. Приводятся критерии верификации информации, такие как проверка источников и поиск доказательств.
5. Логические основы аргументации. Обсуждаются структура умозаключений, типы аргументов и распространённые логические ошибки.
6. Практика принятия решений. Предлагаются алгоритмы взвешенного выбора в условиях неопределённости, включая анализ рисков и последствий.

Все эти темы разбираются в рамках отдельных историй, которые основаны на реальных ситациях: конфликт с родителями, выбор подарка, выбор профессии, магическое мышление. Это позволяет не просто читать теорию, а попробовать применить ее на практике. Авторы так прорабатывают важные концепции
- Когнитивные искажения - например, эффект ореола, предвзятость подтверждения
- Структура аргументации - тезис, аргументы, контраргументы
- Критерии достоверности информации - проверяемость, источник, контекст.

Практическую направленность книги подтверждает то, что каждая глава содержит
- Кейсы для анализа. Читателям предлагается оценить ситуации, подобные тем, с которыми они сталкиваются в школе или соцсетях.
- Упражнения-тренажёры. Например, задание на классификацию суждений («факт vs мнение») или построение логических цепочек.
- Чек-листы и алгоритмы. Готовые схемы для проверки информации, принятия решений и аргументации.

Итого, эта книга может стать хорошей стартовой точкой для развития критического мышления для читателей старше 12 лет (возвраст указан в книге). Она особенно полезна в образовательном контексте — для уроков по логике, факультативов или семейного чтения. Для углублённого изучения темы стоит дополнить её академическими источниками, но в качестве практического руководства она выполняет свою задачу на отлично.

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

#Thinking #CriticalThinking #Reasoning #Philosophy #SelfDevelopment #Brain #Management #Leadership

AI и Platform Engineering (Рубрика #AI)

Интересное выступление Игоря Маслова, VP of Coretech & Data в Т-Банке, на открытии конференции Platform Engineering Night, про которую я уже рассказывал. Игорь открывал конференцию и рассказал о том, как AI влияет на работу инженеров и развитие инженерных платформ. Основные мысли выступления примерно следующие

1. AI как усилитель существующих платформ
Сейчас нужно "обмазывать" существующие инженерные сценарии AI - от создания пайплайнов до анализа телеметрии. В этом разрезе интересно глянуть whitepaper Google "Measuring Developer Goals", чтобы посмоттреть какие основные сценарии выделяет Google (я рассказывал о нем раньше), а также девятый выпуск "Research Insights Made Simple", в котором мы с коллегой Колей Бушковым разбирали whitepaper "What Do Developers Want From AI?" от ребят из Google
2. Когнитивная нагрузка и потеря навыков
Игорь отмечает, что активное использование AI приводит к потере низкоуровневых навыков, но считает это нормальной эволюцией - условно, мало кто пишет на ассемблере и большая часть инженеров его уже не понимает и это никого не смущает. Примерно также мы будем писать код с ассистентами на условной Java и часть людей без ассистентов его уже не смогут написать/прочитать:)
3. Режим "копайлота" как базовый уровень
Ответственность за финальный результат остаётся за человеком, что минимизирует риски "галлюцинаций" AI-моделей. Anthropic реализует эту философию в Claude, где модель действует как ассистент, а не замена разработчика. Такой подход особенно важен в критически важных системах, таких как финансы или здравоохранение, где ошибки AI недопустимы
4. Будущее: AI как платформенная инженерия
В долгосрочной перспективе AI может стать основным интерфейсом для управления инженерными процессами, устраняя необходимость в традиционных инструментах. Это направление напоминает эволюцию Kubernetes, который стал стандартом для оркестрации контейнеров, но для AI аналогичный "момент" ещё не наступил
5. Vibe Coding и персонализированный софт
Генерация кода под конкретные бизнес-кейсы или индивидуальные потребности пользователей — ключевой тренд. Однако, как предупреждает Игорь, подобные системы требуют тщательной валидации, чтобы избежать проблем с поддерживаемостью кода
6. Разгрузка разработчиков от рутины
80% экспериментальной работы можно автоматизировать, освободив время для более важных задач. OpenAI's Code Interpreter позволяет итеративно решать сложные задачи программирования и анализа данных.
7. ML-платформы: гибкость и готовность к изменениям
Инвестиции в ML-платформы оправданы, но требуют готовности к технологическим сдвигам. Например, переход от традиционных нейросетей к трансформерам в 2020-х потребовал полного пересмотра инфраструктуры у большого количества компаний. Спикер подчёркивает, что платформы должны сохранять модульность, чтобы адаптироваться к новым алгоритмам и аппаратным решениям
8. Отсутствие "момента Kubernetes" в AI
Пока нет универсального стандарта для AI-платформ, и стоит дождаться его появления. Каждая компания развивает свои подходы: OpenAI с Agents SDK, Anthropic с фокусом на безопасность, Google с комплексными AI решениями.
9. Высокорискованная природа current AI R&D
Современные AI-решения требуют больших ресурсов и подходят в основном крупным компаниям. Это подтверждается масштабными инвестициями OpenAI, Google и Microsoft в платформенные решения.
10. Постепенный подход к внедрению
Рекомендация: начинать с улучшения инструментов, но пока воздержаться от сложных low-code процессов. Anthropic следует схожей философии, предоставляя мощные модели с акцентом на контролируемое внедрение.

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

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx