Code of Leadership #51 - Interview with Alexey Fyodorov about Management & Conferences (Рубрика #Management)

В очередном выпуске подкаста ко мне пришел интересный гость, Алексей Федоров, один из основателей компании JUG.RU, что проводит крутые конференции по различным технологиям на российском рынке. Мы с Алексеем поговорили про его интересный путь через науку в технологии, а потом к организации конференций. Отдельно мы поговорили про первую конференцию для менеджеров, которая называется InBetween, про которую я уже рассказывал отдельно. Краем мы задели даже ICPC, финал которого с 31 августа по 5 сентября - мы записывали этот выпуск, когда Леша уже прилетел в Баку, чтобы помочь в организации финала чемпионата мира по программированию. В общем, за два часа мы успели обсудить много тем

- Введение и знакомство с гостем
- Принципы и традиции выбора названий конференций от JUG.RU
- Биография Алексея Фёдорова, академический путь, переход в ИТ
- Особенности работы с Java и интеграция в мировое комьюнити
- Размышления о роли и подготовке спикеров, критика качества выступлений, путь к евангелизму
- Рост и стандартизация вендерских конференций, примеры крупных ивентов от компаний
- Ощущения участников от повторных посещений конференций, скорость изменений
- Появление и специфика менеджерских конференций, развитие треков по управлению, вопросы специализации
- Влияние Agile на рынок, книги как источники знаний
- Коллаборации между российскими ИТ-компаниями, опыт совместных академий и стажировок, проблема отсутствия обмена экспертизой
- Фронтирные модели: стоимость, доступность, дилемма заключённого и борьба за ресурсы между компаниями
- Роль государства, эволюция рыночных механизмов и регулирование
- Менеджмент, прозрачность и доверие в командах, контроль результатов, анализ мотивов через вопросы и рефлексию
- Влияние платформенной инженерии и формализации процессов на скорость и предсказуемость разработки, инертность крупных систем
- Обзор онлайн активностей на конференции InBetween, что уже прошли в августе
- Примеры докладов с оффлайн части конференции, что будет 8 сентября
- Предполагаемая аудитория конференции
- Влияние кризисов на менеджмент
- Экосистемы и их устойчивость к кризисам
- Конкуренция в экосистемах
- Анонс финала ICPC, где Алексей помогает проведению этих соревнований по программированию

Рекомендации для чтения от Алексея
- Джоэл о программировании
- Серия «Профессионально (Символ)»
Также Леша упоминал про Академию современного программирования

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

#Software #Engineering #Management #Career #Science #Conference #Leadership

Auf Wiedersehen, GitHub ♥️ (Рубрика #AI)

Так Томас Донке, CEO Github с 2021 года, в начале августа попрощался и объявил о своем уходе. Это решение стало поворотным моментом в истории GitHub, так как Microsoft решило не назначать нового "независимого" CEO. Вместо этого платформа глубже интегрируется в блок CoreAI, а руководящая команда будет репортить внутрь структуры Microsoft. Изменения произошли по двум причинам
1. Томас Донке решил вернуться к своим стартап-корням (насколько это правда оценим по дальнейшей деятельности Томаса)
2. Microsoft решила усилить консолидацию AI-продуктов в единую стратегию CoreAI, где Copilot - один из ключевых активов. СМИ отмечают именно это смещение центра тяжести с "платформы-репозитория" к "AI-платформе разработки"

Что ждет GitHub в будущем
GitHub станет центральным элементом AI-стратегии Microsoft. CoreAI под руководством Джея Париха сфокусируется на
- Создании AI-платформы для внутреннего использования и клиентов Microsoft
- Развитии агентного AI и автономных систем разработки (copilot станет полноценным агентом)
- Углублении интеграции с Azure, Windows и Office 365
- Усиление корпоративных функций: security, миграции, расширение marketplace

Если говорить о том, а что это значит для экосистемы разработчиков, то можно описать это так
1. GitHub теперь "Copilot-first" платформа.
Ожидайте ускоренной интеграции агентных сценариев (автозаведение PR, фиксы по задачам, рефакторинги по описанию) в веб-интерфейсе и IDE, плюс более тесной связки с Azure/CoreAI. Для вас это означает рост продуктивности… и рост значимости "правил использования ИИ" в командах.
2. Новая экономика AI с отдельными бюджетами
Бюджеты на ИИ-запросы станут таким же нормальным CAPEX/OPEX, как минуты CI/CD. Планируйте квоты "premium-requests", обратную связь командам и политики выбора моделей.
3. Безопасность и комплаенс добавлены в платформу по умолчанию
Дальнейшее развитие GitHub Advanced Security/Dependabot/Secret scanning и риск-оценок будет стандартом для enterprise. Это снизит time to recovery на инциденты в цепочке поставки и потребует "security-by-design» в процессах (кстати, про secure by design мы общались с моим коллегой, Артемом Меретцом, в подкасте «Research Insights Made Simple»)
4. GitHub - это часть экосистемы Microsoft
Плотная интеграция с Microsoft ускорит релизы AI-фич, но увеличит стратегическую зависимость от экосистемы MS (идентификация, биллинг, облачные сервисы). Это важно учитывать, если вы мульти-вендор.

#AI #Engineering #PlatformEngineering #Cloud #Software #Leadership

Machine Learning System Design (Рубрика #ML)

Пока я отдыхал на плато Путорана без интернета, то читал книгу "ML System Design" от Валерия Бабушкина и Арсения Кравченко. Она была интересна для меня по двум причинам: мне близка тема классического system design и я интересуюсь machine learning:) Мне близка идея авторов о том, что проектирование систем (ML систем в том числе) - это многоэтапный процесс, где пригодятся навыки из различных областей, которые стоит использовать в рамках системного подхода. Причем для ML этот многоэтапный процесс содержит гораздо больше шагов, чем просто выбор правильной модели/алгоритма.

Если сравнивать обычный и ML дизайн, то есть такие моменты, что их отличают друг от друга
1. Детерминизм vs вероятность
Обычные системы мы стараемся проектировать с определенной долей детерменизма, причем для проверки предсказуемости покрываем их тестами. ML системы носят by design вероятностный характер. В обычных системах у нас обычно есть четкий алгоритм, превращающий входные данные в выходные, а всю недетерминированная часть обычно находится на стороне эксплуатации (работа под нагрузкой, надежность и работа с отказами). В ML системах сама модель исполнения недетерминирована, что добавляет сложности оценке качестве ее работы
2. Одно и двух-фазная архитектуры
В ML системах обычно есть две сильно отличные фазы работы: training и inference. В обычных приложениях у нас нет фазы тренировки - оно руками инженеров уже обучено выполнять нужную работу (ака работать в режиме inference).
3. Зависимость от данных
В традиционной разработке у нас обычно есть структурированные данные, с которыми работают приложения - при дизайне мы проектируем модели данных и моделируем их взаимосвязи, часто это OLTP системы. В ML системах у нас степень контроля над данными сильно меньше - нам приходится городить пайплайны и зачастую при обучении работать с OLAP конструкциями, одновременно на inference работать в формате более близком к традиционным системам, чтобы успевать делать Inference с приемлемым временем отклика

В своей книге авторы уделяют много времени и места обсуждению архитектурных соображений
- Конвейеры данных
Построение надежных data pipeline становится фундаментальным компонентом архитектуры, поддерживающим поглощение данных, обработку в реальном времени и масштабируемые решения для хранения.
- Модульный дизайн
Необходимость отделения ML-компонентов от основной логики приложения, что позволяет независимо обновлять модели без нарушения работы основной системы.
- Мониторинг и наблюдаемость
Традиционные системы логирования должны эволюционировать для включения специфических метрик ML, таких как drift данных и производительность модели.

Отдельно отмечу интересный формат историй у костра (campfire stories), где авторы делятся своими историями из прошлого, рассказывая о решении реальных задач из своего опыта. Это выглядит интересно и похоже на то, когда мы рассказываем байки у костра за кружечкой горячего напитка. В общем, мне книга показалась интересной и полезной - ее полезно почитать как ML инженерам, так и классическим software engineers, которым все больше приходится проектировать Gen AI приложения.

P.S.
У авторов есть свои tg каналы, где они пишут про ml и не только
- У Валеры - @cryptovalerii
- У Арсения - @partially_unsupervised

#ML #AI #Engineering

Распродажа в издательстве «Питер» в последний викенд лета (Рубрика #Sales)

В издательстве Питер очередная распродажа со скидками в 35% на бумажные книги и 50% на электронные. Для получения этой скидки надо использовать промокод "Бумажная" (или "Электронная", если покупаете элетронную версию) при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг, а в этот раз обратил внимание на следующие книги, последние три из которых докупил себе в коллекцию

- Технический директор. Эффективное техническое лидерство - в оригинале эта книга называется "The Engineering Executive's Primer" и я бы перевел ее как букварь технического директора:) Я прочитал ее с большим удовольствием год назад и могу порекомендовать ее любому техническому руководителю
- Разработчик ПО: Путеводитель по карьерной лестнице для будущих сеньоров, техлидов и стаффов - я уже рассказывал, что у меня появилась эта книга и я ее потихоньку пока читаю. Впечатления от нее отличные.
- Масштабируемые данные. Высоконагруженные архитектуры, Data Mesh и Data Fabric. 2-е изд. - в наш век GenAI приложений меня очень интересуют подходы к созданию платформ данных. Примерно про это мы говорили с моим коллегой, Сергеем Михалевым, в выпуске моего подкаста Code of Leadership
- Causal Inference на Python. Причинно-следственные связи в IT-разработке - я глубоко погружен в разработку нашей a/b платформы, а также в дизайн некоторых опросов (в стиле DORA), поэтому в последнее время я много читаю про статистику. Еще одна книга на эту тему будет не лишней.
- Дизайн и поведение пользователей. Применение психологии и поведенческой экономики в разработке и UX - эта тема продолжает планирование исследований и экспериментов, но уже внутри продукта.

#Sales