Книжный куб

Доклад про инженерную продуктивность на конференции MTS True Tech Day (Рубрика #Management) Сегодня на главной сцене конференции от MTS я буду выступать с докладом про developer productivity. У этой конференции интересный слоган: "код науки и технологии", который мне понравился. Мое выступление у меня будет отчасти экспериментальным, так как часть доклада мне придется рассказывать в формате стендапа без слайдов (не уложился в дедлайн их отправки). Но у меня есть полная версия со всем визуалом и расшифрокой в виде статьи в моем блоге. План выступления примерно следующий - Затравка про важность этого вопроса - Как я предлагаю сузить границы рассмотрения только продуктовыми компаниями и частью delivery без discovery - Какие подходы были в академической среде: DORA и Accelerate, SPACE, DevEx - тезисы со ссылками на материалы доступны здесь - Как это делают в Bigtech, например, в Google используют подход QUANTS - тезисы доступны здесь - Что есть на рынке в виде коммерческих платформ - тезисы и ссылки здесь - Как это делаем мы в Тинькофф - тут я расскажу про наш инструмент T-Meter - Ну и какие выводы из этого всего следуют P.S. Так как мой доклад - это не питчинг раунда финансирования для стартапа, то я решил исключить часть про влияние AI на developer productivity, что тянет на отдельный доклад (который недавно как раз рассказывал VP of Product из GitHub) #Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

CTO Day Light от Yandex Вчера была интересная тусовка для технических директоров от Yandex в центре Москвы. Мероприятие получилось для меня очень интересным, так как удалось пообщаться с умными людьми и обсудить интересные вопросы от полушуточных до серьерзных, например - Как выстраивать end-to-end процессы продуктовой разработки и какие проблемы тут могут быть - Как выстраивать оргструктуру под требования бизнеса и как понять оптимальна ли структура под текущие запросы - Что такое культура компании и как она влияет на взаимодействие команд и процессы - Как подходить к процессам архитектуры и проектирования - тут и про написание дизайн доков, про нотации моделирования, про описание стейта архитектуры vs изменений, про TLA+ и не только - Кто такие системные аналитики и что они делают в командах разработки - Как выглядит работа в европейское компании vs российской:) - и так далее В общем, мероприятие получилось топовым для меня и вечер прошел отлично. А вообще этот формат мне нравится больше конференций - плотность крутых специалистов высока и всегда можно найти себе интересного собеседника:) P.S. Спасибо организаторам, что позвали в гости на это мероприятие. Кстати, оно было продолжением того, что было на CTO Day в Дубае, про которое я рассказывал раньше. #Engineering #Software #Management #SystemDesign #SystemEngineering #Leadership

Google I/O 2024: Everything Revealed in 12 Minutes (Рубрика #AI) Прошел один день с анонса GPT-4o от OpenAI и состоялся Google I/O, который пропустившим можно посмотреть в виде 12-минутной нарезки ключевых моментов от CNET. Забавно, что само мероприятие Google I/O можно заменой одной буквы переименовать в Google AI, о котором в основном и говорили со сцены:) - Project Astra - как Gemini умеет работать с видео с камеры телефона и воспринимать окружающее пространство - Veo Generative AI Video Model - модель для генерации видео навроде Sora - Trillium TPU - шестое поколение процессоров для обработки тензоров (в 4.7 раза эффективнее, чем раньше) - Axion Processor - custom ARM процессор - Gemini AI Google Search - как AI встраивается в Google Search: AI Overviews в качестве дополнительного блока сверху поисковой выдачи, дальше пример с поиском ресторанов под определенную задачу - Gemini AI Video Search - поиск по видео, когда ты снимаешь камерой смартфона что-то и задаешь вопрос, выглядит интересно - Gemini AI 'Live' Voice Chat - голосовой ассистент, с которым можно естественно разговаривать в real-time - Gemini AI Gems - персонализированные ассистенты, которым можно задать инструкции и дальше они будут вести себя в соответствии с ними - Android 15 AI Powered Search - AI полным ходом заезжает в Android (сначала на Pixel, а потом и на другие телефоны), где были показаны три изменения: доработки поиска, gemini становится ассистентом на Android, новая AI gemini модель будет работать на устройстве - Circle To Search - поиск по кружочку:) - Gemini AI Context Aware - обсуждение с учетом контекста (в демо пример с общение насчет pickleball и теннисом - вопросы, генерация картинок, вопросы по видео) - Android 15 with Gemini Nano with Multimodality - подробнее про модель, работающую на устройстве (Geini Nano с мультимодельностью, on-device foundational model) - How many times AI was mentioned at Google I/O - шутка на тему частого упоминания AI P.S. Но даже в день Google I/O у OpenAI была интересная новость про уход из компании Ilya Sutskever, chief scientist, а также со-основателя компании. Если вспомнить мелодраму с уходом Сэма Альтмана и его возвращением в OpenAI, то эта новость не кажется особенно неожиданной, так как Илья поучаствовал в этой истории как один из зачинщиков, большая часть из которых уже давно покинула компанию. Но Илья сначала потерял место в совете директоров после возвращения Сэма, а теперь вообще пошел заниматься чем-то, про что он написал в своем твитте так

I am excited for what comes next — a project that is very personally meaningful to me about which I will share details in due time.

#AI #DataScience #ML #Bigtech

Introducing GPT-4o (Рубрика #AI) Вчера был интересный анонс новой модели от OpenAI и живое демо ее возможностей. Видео длится 26 минут и его интересно посмотреть в оригинале, так как там было несколько интересных новостей: - Появление настольной версии ChatGPT (для Mac) - Запуск новой флагманской модели GPT-4o, которая действительно мультимодальна и с ней можно разговаривать, показывать видео и картинки и задавать по ним вопросы. - Latency на ответы у модели такое, что с ней вполне можно приятно разговаривать без задержек в несколько секунд на генерацию ответа - это мне напомнило фильм "Она", который был про взаимоотношения AI как персонального ассистента и главного героя, кстати фильм вышел в 2013 году - GPT-4o в 2 раза быстрее, на 50% дешевле и рейт-лимиты в 5 раз выше, чем в GPT4-Turbo - GPT-4o будет доступен для всех пользователей (даже бесплатных) - В демо был интересный кейс помощи в решении линейного уравнения - похоже GPT-4o теперь еще больше импакта способен принести в Edtech - Дальше был пример работы с python кодом, код конечно простой был, но ChatGPT хорошо рассказал что это за код, зачем он нужен, а потом еще проанализировала график, который этот код и рисовал - Другой пример с переводом в режиме реального времени тоже выглядел вдохновляюще - Ну и последний пример - это анализ эмоций по выражению лица, которое транслируется при помощи селфи-камеры В общем, очень интересная демка после которой вспоминается третий закон Артура Кларка

Любая достаточно развитая технология неотличима от магии.

И кажется технологии от OpenAI приближаются к этому достаточно развитому уровю:) #AI #DataScience #ML

Немного картинок к отчету, на которых представлены значимые модельки за 2023 год, а также видно как performance моделей приближается или превосходит человеческий уровень.

Artificial Intelligence Index Report 2024 Недавно почитал этот отчет от Stanford University for Human-Centered AI, который в виде pdf занимает солидные 500+ страниц:) Отчет является достаточно значимым в индустрии и затрагивает большое количество тем (он разбит на 9 отдельных глав вида: RnD, tech performance, responsible AI, economy, science & medicine, education, policy & governance, diversity, public opinion). Каждая глава содержит большое количество отсылок к исследованиям, различные визуализации и нетривиальные выводы, которые выливаются в следюущие top-level находки 1. AI beats humans on some tasks, but not on all - железные друзья уже превосходят людей в ряде задач, пока не во всех, но еще не вечер 2. Industry continues to dominate frontier AI research - создание foundational моделей - дело дорогое, поэтому крупные компании его могут себе позволить, а вот академическим исследователям не хватает бюджетов для конкуренции. Поэтому многие прорывные результаты рождаются в корпорациях 3. Frontier models get way more expensive - интересно наблюдать экспоненциальный рост стоимости моделек, который дает стабильный рост результатов 4. The United States leads China, the EU, and the U.K. as the leading source of top AI models - USA пока впереди Китая в рамках AI (а если посмотреть на другие новости про запрет экспорта части технологий в Китай, то кажется, что USA хочет продолать быть лидером) 5. Robust and standardized evaluations for LLM responsibility are seriously lacking - вопрос оценки моделей достаточно сложен (во второй части про tech performance авторы рассказывают про разные варианты бенчмарков) 6. Generative AI investment skyrockets - видно, что тема инвестиций в AI горячая и все стартапы теперь пытаются добавить себе в описание рассказы про искусственный интеллект, чтобы повысить оценку бизнеса у инвесторов:) 7. The data is in: AI makes workers more productive and leads to higher quality work - есть исследования, что показывают повышение продуктивности и качества работы с использованием искусственного интеллекта 8. Scientific progress accelerates even further, thanks to AI - искусственный интеллект теперь помогает естественному двигать науку вперед. Интересно посмотреть что будет в отчете следующего года - по-факту, это позитивная спираль обратной связи и если AI сможет ускорять научные исследования, то лучше ему начать с области исследований AI:) 9. The number of AI regulations in the United States sharply increases - как обычно с большими возможностями приходит и большая ответственность, которую накладывают регуляторы. По-идее, это фиксирует границы и правила игры, но одновременно замедляет исследование нового. Но AI теперь слишком большой слон, чтобы регуляторы им не заинтересовались:) 10. People across the globe are more cognizant of AI’s potential impact—and more nervous - люди нервничают, так как появляется ощущение, что мы живем в эпоху перемен и технологическая сингулярность не за горами. Одновременно, не ясно когда и чью работу отдадут нашим железным друзьям и как потеря работы отразится на нашей жизни. Правда, пока AI скорее идет в сторону ассистентов людей, но при такой скорости развития моделей и получения данных для обучения ассистент скоро сможет превзойти учителя и ... В общем, рекомендую отчет к ознакомлению всем интересующимся в современных технологических трендах. #AI #ML #Software #Engineering #DataScience

Обложки книги про Agile Modeling. Английское издание очень пестрое:)

Гибкие технологии: Экстремальное программирование и унифицированный процесс разработки (Agile Modeling: Effective practices for XP) (Рубрика #Management) Достал с полки раритетную книгу Скотта Амблера (Scott Ambler), которую я читал еще в 2005 году в самом начале своей карьеры как инженера. В то время еще все не молились на Agile Manifesto, каскадная разработка была еще в полном порядке, а по миру шагал унифицированный процесс разработки вида RUP (Rational Unified Process). А в этой книге автор пытался поделиться своим опытом моделирования программного обеспечения. В итоге, в книге было 400 страниц, 30 глав и пять частей, про которые стоит рассказать подробнее 1. Введение в гибкое моделирование - здесь автор рассказывает про agile manifesto и на базе него формулирует свои принципы agile modeling навроде того, что надо ожидать изменения, изменения надо делать небольшими, нам нужно множество моделей, быстрая обратная связь, что содержание важнее формы и так далее. Дальше автор рассказывает про разные методики моделирования: инкрементальные, работа в группе, важность тестирования модели и проверки ее в коде, используйте стандарты моделирования и не увлекайесь паттернами. В общем, мне эта часть была очень полезна почти 20 лет назад 2. Гибкое моделирование на практике - все начинается с важности общения для моделирования софта, дальше развенчиваются мифы вида "заморозки требований" или "высеченного в камне дизайна", дальше упоминается моделирование интерфейса, требований, написание документации, а также использование нотаций - тогда UML была впереди планеты всей, но уже в этой книге была глава с название "По ту сторону UML":) 3. Гибкое моделирование и экстремальное программирование - здесь автор рассматривает XP (extreme programming) и показывает как agile modeling укладывается в этот подход. Из этой книги видно, что XP тогда был на коне и важно было дать отсылку к нему, а не к Scum, Kanban или еще чему-то 4. Гибкое моделирование и унифицированный процесс - а здесь автор говорит про унифицированный процесс, который потом превратится в RUP (rational unified process). Это другая часть спектра, где мы смотрим на бюрократический процесс, что пришел на смену каскадному. Автор показывает, что и здесь agile моделирование может пригодится 5. Глядя в будущее - в этой части автор говорит про то, как внедрить в свои процессы моделирование софта Итого, книга для своего времени была очень хороша - качественный разговор про моделирование и дизайн софта, обсуждение того, как это встраивается в тогдашние процессы разработки. Обсуждение практических подходов, инструментов, нотаций и так далее. Я из книги в то время узнал и почерпнул многое. Но сейчас эта книга скорее динозавр из прошлого и читать ее стоит только археологам процессов разработки или ностальгирующим вроде меня:) P.S. Интересно, что дальше автор книги, Скотт Амблер, продолжил копать тему Agile подходов и вылепил Disciplined Agile (DA) в 2012 году, который потом был куплен с потрохами PMI (Project Management Institute) в 2019. PMI дальше постаралась с помощью этого тулкита закрыть свое отставание в гибких подходах. Историю про Disciplined Agile я уже рассказывал раньше. #Processes #Management #Agile #Leadership #Software

You Keep Using That Word • Sam Newman • GOTO 2023 (Рубрика #Architecture) Это доклад Сэма Ньюмана, известного популяризатора термина микросервисы, по которым он написал известные книги "Building Microservices" в 2015 году, "Monolith to Microservices" в 2019 году, которые поспособствовали буму микросервисов. В этом докладе автор решил разобраться не с самими сервисами, а со связами между ними. Эти связи часто классифицируют как синхронные или асинхронные, но что же такое асинхронность и как она соотносится с синхронностью? Автор рассказывает про свой тред в сети X (ex-Twitter) трехлетней давности, где он устраивал дискуссию на эту тему и получил примерно следующие мнения о том, что входит в концепцию асинхронности: - Immediacy (незамедлительность) - пример звонка по телефону по сравнению с отправкой email - Temporal coupling (временная связанность) - связь действий во времени - Non-blocking (не блокируемость) - возможность делать неблокирующие выщовы (аля promises или async конструкций в языках) - Intermediary (посредник) - наличие промежуточного посредника навроде Rabbit MQ, Active MQ, Apache Kafka Также автор вспоминает про предыдущий подход к снаряду с асинхронностью от создателей Reactive Manifesto, который был создан пока написание манифестов еще не превратилось в булшит бинго. Конкрентно автор сомневается в полезности определения Asynchronous из этого манифеста

Asynchronous The Oxford Dictionary defines asynchronous as “not existing or occurring at the same time”. In the context of this manifesto we mean that the processing of a request occurs at an arbitrary point in time, sometime after it has been transmitted from client to service. The client cannot directly observe, or synchronize with, the execution that occurs within the service. This is the antonym of synchronous processing which implies that the client only resumes its own execution once the service has processed the request.

Конкретно у Сэма есть претензия к словам обработки запроса "after it has been transmitted", как будто обработка запроса возможна до этого. Тут сразу вспоминается Герберт Уэллс и его Машина Времени:) Но дальше Сэм сам не предлагает точного определения для асинхронности и говорит о том, что все зависит от контекста. В итоге, в социотехнической системе присутствуют люди, которые вкладывают смысл в слова языка и этот смысл может отличаться для одного и того же слова в разном контексте. На эту тему я рекомендую почитать книгу Александра Пиперски "Конструирование языков. От эсперанто до дотракийского", про которую я рассказывал раньше. В книге речь идет не о лингвистике в общем, а скорее про искусственные языки: краткую историю их исследований и принципы классификации. А при обсуждении искусственных языков мы можем наблюдать весь процесс дизайна языка, начиная с целей, проходя через принципы и приходя к имплементации. Это сильно интереснее обсуждения естественных языков, где многое объясняется тем, что "так исторически сложилось":)) #Architecture #Software #Engineering #SoftwareArchitecture #SystemDesign #DistributedSystems #Design

Всё о Малыше и Карлсоне (илл. А. Савченко) (Karlsson pa taket flyger igen. Karlsson pa taket smyger igen) (Рубрика #Kids) Многие взрослые смотрели в детстве мультики про Малыша и Карлсона. Потом взрослые показывают его своим детям, а дальше покупают книжку для того, чтобы читать истории про Карлсона детям перед сном. Мы с женой так и сделали и купили книгу с обалденными иллюстрациями из старых советских мультиков. И все бы хорошо - книга отличная, знакомая история про друга Малыша, что живет на крыше и умеет летать благодаря своему пропеллеру на спине ... но что-то не так. В книге гораздо ярче, чем в мультике проступает истинное обличие Карлсона - человека без определенного места жительства (если не считать чердак), что разводит детей на еду и игрушки, минимально думаюет об окружающих вокруг и считает себя лучшим в мире по всем активностям. В мультике у Карлсона роль забавного толстячка, с которым Малыш интересно проводит время, а в книге этот забавный толстячок не очень-то и забавен. В итоге, мы за полгода смогли с детишками прочитать 320 страниц из 420, а дальше ни жена, ни сыновья не хотят дальше читать истории про Карлсона. P.S. Сама книга вышла качественной - большой формат, плотная бумага, знакомые иллюстрации. Все сделано отлично. #ForKids #ForParents

Обложки для книги про Китай, интересно сравнить как они поменялись при переиздании книги на русском

Краткая история Китая (The Shortest History Of China) (Рубрикак #History) Эта книга Джейвин Линды про историю Китая напомнила мне набор разноцветных четок, где каждая из четок - это отдельный исторический период. И этот калейдоскоп начинается с императоров древних времен и заканчивается их аналогами в настоящием:) Одновременно при чтении мне показалось, что каждая глава настолько перегружена событиями и ключевыми персонажами, что она напоминает детский калейдоскоп - если его встряхнуть, то мы получим совсем другую картину, под другим углом и дальше можно будет вглядываться в нее заново. В общем, книга отлично подходит для начального знакомства, которое позволит узнать о многом и дальше нырнуть в то, что заинтересовало, а помогает этому содержание, которое напоминает американские горки:)

1. Истоки - Яйцо проклевывается, и рождается цивилизация 2. Чжоу - От идеального правления к периоду Сражающихся царств 3. Цинь - Объединение, тирания и Поднебесная 4. Хань - Интриги, инновации и короткое междуцарствие 5. Великий разлад - Три царства, две женщины-воительницы, семь мудрецов и порошок из пяти минералов 6. Тан - От золотого века до вечной печали 7. Сун - Протосоциалисты, неоконфуцианы и городское житье 8. Монгольская Юань - От "славной резни" к великолепному городу 9. Мин - Великолепие и упадок 10. Великая Цин - Трудный путь к современности 11. Республика - Большие надежды и жестокие предательства 12. Японское вторжение и гражданская война - Республика распадается 13. Годы Мао - Непрерывная революция 14. Эпоха реформ - Процветание и недовольные 15. Новая эра Си Цзиньпина - Появление воинов-волков

P.S. По мере прочтения этой книги до меня доходили истинные масштабы Китая: количество разных национальностей, людей, городов, героев и злодеев, а династистий, что сменяли друг друга. И мне вспомнилась фраза из 1984, которой пользовались часть из правителей для того, чтобы управлять будущим

Кто управляет прошлым, тот управляет будущим; кто управляет настоящим, тот управляет прошлым

Кстати, рекомендую почитать 1984 хотя бы в виде комикса, про который я рассказывал раньше. #History #Economics

Интересно как издатели по разному подходят к обложке книги о дизайне, о которой я рассказывал утром:)

Дизайн всего (How Design Makes the World) (Рубрика #Design) Очень простая и короткая книга на тему дизайна от Скотта Беркуна, который написал много книг, включая "Откровение оратора" (подробнее в посте) и "Искусство управления IT-проектами" которые я читал до этого. Как обычно Скотт пишет очень просто и легко, приводит кучу примеров и много шутит, но глубина проработки тем такова, что читать ее интересно начинающим. Но вы не узнаете много нового, если вы уже в теме и читали упоминаемые Скоттом книги типа - “Дизайн привычных вещей” ("The Design of Everyday Things") Дона Нормана (подробнее в моем посте) или - "Предсказуемая иррациональность" ("Predictably Irrational") Дэна Ариели На протяжении книги автор подводит к тому, что дизайн - это не просто про интерфейсы или визуал, а это про осмысленное создание предметов, которые служат определенным целям определенной аудитории. В итоге, у него получаются 4 главных вопроса, которые задают хорошие дизайнеры

1. Что вы хотите улучшить? 2. Для кого вы хотите это улучшить? 3. Как вы добьетесь того, чтобы дизайн оказался успешным? 4. Кому может навредить ваша работа - сейчас или в будущем?

Для того, чтобы оценить повестование можно взглянуть на главы, которые входят в книгу 1. У всего есть дизайн - даже если о дизайне не думали, то он какой-то получился, но чаще всего он получился не очень 2. Производить или проектировать - что сложнее? - Ответ автора в том, что чаще проще сделать вещь, чем ее спроектировать 3. Что такое хорошо? - зависит от цели 4. Люди прежде всего - рассказ про сигвеи и что бывает, если идти от технологии 5. Дизайном занимается каждый - и инженеры при проектировании софта тоже:) 6. Улица за окном - про проектирование городов и районов, а также про прямоугольную сетку улиц (что использовалась с древних времен) 7. Стиль - это послание - про бренд и особенности стиля, которые передают мысль окружающим 8. Дизайн - это функциональность - про ментальные модели, которые дизайнеры используют для облегчения использования предметов, например, про кнопки-плацебо, багажную ленту в аэропорту и так далее 9. За чей счет? - кому-то придется заплатить за улучшенный дизайн: покупателю, продавцу или государству. Тут приводится интересный пример с ремнями безопасности в машинах 10. Как скажут сверху - политики и руководители компаний тоже являются дизайнерами, так как обычно они принимают финальное решение:) 11. Дизайн - это действие - про итеративную работу дизайнеров и дизайн-мышление (design thinking) 12. Билет в кармане - разбор посадочного билета на самолет и почему он такой (спойлер: это обусловлено работой с ограничениями реального мира и наличии legacy систем) 13. Идеи и системы - если системам такова, что там принимаются неудачные решения, то и дизайн там получится неудачный (пример с госучереждениями) 14. Как для себя? - суть главы в том, что вы - нерепрезентативны. А для того, чтобы принимать удачные решения надо иметь разношерстную команду и думать о разных потребителях 15. Образ мышления: это важно! - важно не заставлять клиентов думать о том, как пользоваться вашими спроектированными решениями + если они все-таки ошибаются при использовании, то это не должно приводить к серьезным проблемам 16. Ценности и компромиссы - компромиссы - это то, к чему мы приходим в реальной жизни. Важно понимать к чему мы стремимся и как оценивать альтернативы (и больше не значит лучше) 17. Хороший дизайн незаметен - все должно быть ясно без объяснений и инструкций 18. Дизайн раздора - про темные паттерны дизайна и противоречие между людьми, которое возникает из-за спроектированных решений 19. Новые решения - новые проблемы - примерно про day-2 проблемы (что будет после того, как спроектированное решение будет внедрено) 20. Куда смотреть - чеклист для понимания дизайна от автора 21. Рекомендации - куча отсылок к источникам В общем, читать интересно и полезно. Но если вы гуру дизайна, то вам будет скучно:) #Architecture #Management #Thinking #Leadership #SystemDesign #SystemThinking

Adaptive Architectures • Marty Pitt • GOTO 2023 (Рубрика #Architecture) Интересный доклад от Marty Pitt на ту же самую тему, которую он поднимал за год до этого в докладе "Using Semantic Metadata to Create an Automated Microservice Data Mesh", про который я рассказывал раньше. Правда, теперь эта идея подается через адаптивную архитектуру, которая достигается за счет того, что мы не пишем связующий код (glue code), который нам требуется для интеграции наших отдельных API для выполнения полезной работы. Как и в прошлый раз это достигается за счет: - Языка Taxi для семантической разметки наших существующих API, когда мы поверх ним добавляем этим языком метаданные для описания семантики - Декларативного языка запросов TaxiQL для описания того, что мы хотим выбрать с точки зрения семантики - Платформы Orbital для хостинга этих метаописаний и исполнения этих декларативных запросов, когда под капотом платформа выполняет все запросы и выплевывает готовую информацию В итогe, Taxi похоже на GraphQL в плане целей предоставления единой точки входа для объединения нескольких API. Но в Taxi не требуются resolvers, Taxi независима от протокола и может объединять разные API (OpenAPI, RAML, JsonSchema и Protobuf, ...), TaxiQL позволяет потребителям определять свои контракты данных. Но и проблемы похожи на те, что есть у GraphQL. В итоге, адаптивную архитектуру по мнению автора можно построить на базе

- Taxi - semantic metadata for APIs - TaxiQL - declarative query language - Orbital - TaxiQL engine + observability

#Data #Software #SoftwareArchitecture #Architecture #Engineering

Людей в команде стало больше в 2 раза, а результаты в 2 раза не увеличились (Рубрика #Management) Вчера в офисе беседовал на эту тему со своим коллегой на эту тему. Он раньше руководил несколькими командами, а теперь как staff engineer работает над вопросами архитектуры и проектирования. Коллега отметил насчет одной из команд, с которыми раньше он много взаимодействовал, что она значительно увеличилась, а результат увеличился не соразмерно. И дальше мы ушли в обсуждение причин такого эффекта, которые я объясняю следующими факторами 1. Убывающая предельная полезность - по мере добавления инженеров в команду их предельная полезность уменьшается. Суть в том, что добавление первого инженера позволяет начать развивать продукт, решая самые приоритетные задачи. Добавление второго инженера позволяет уделить время важным задачам, а добавление условно седьмого инженера позволяет заняться nice to have фичами. Примерно тоже самое наблюдается и в жизни, условно, когда вы страдаете от жажды в пустыне - первый стакан воды вам просто необходим и вы готовы за него заплатить много денег, второй полезен и вы все еще готовы платить, а условно десятый стакан для вас уже не несет пользы и платить за него вы не готовы:) 2. Групповая динамика отношений и онбординг новых людей - при добавлении новых людей в команду их требуется обучить и вписать в общую динамику группы (модель Такмана). На онбординге мы тратим время самих онбордящихся, а также сильных людей из команд. Кроме того, перформящая по Такману команда может проваливаться в стадию storming, где бурлят обсуждения и команда работает менее эффективно, чем до этого 3. Стоимость коммуникаций - даже если человек уже заонбордился, а динамика команды вернулась в норму, то у нас все равно остаются затраты на коммуникации. Если у нас в команде все общаются со всеми, то у нас получается полный граф, где количество связей равно n*(n-1)/2. Каждую связь требуется поддерживать, поэтому накладные расходы на коммуникации растут квадратично с ростом команды. Отсюда у нас получаются ограничения вида two-pizza team 4. Проблемы с параллелизацией работы - тут нам нужно вспомнить закон Амдала

В случае, когда задача разделяется на несколько частей, суммарное время её выполнения на параллельной системе не может быть меньше времени выполнения самого медленного фрагмента.

А значит что парараллелизация работы внутри команды не позволяет линейно масштабироваться с увеличением количества человек, так как у нас есть часть работы, которую мы должны делать последовательно (планнинг, ретро, часть архитектурной работы, работа над местами с bottleneck в коде, про что рассказывалось в докладе "How Technical Problems Cause Organizational Friction", о котором я упоминал вчера). Кстати, именно поэтому все стремятся сделать автономные команды и топологию команд (можно почитать про team topologies или послушать первую серию подкаста Code of Leadership). Если подводить итоги, то эти факторы приводят к тому, что масштабируя команды мы получаем сублинейное масштабирование эффекта. Причем если процессы на уровне компании выстроены совсем печально, то сублинейное время скорее похоже на ассимптотику log(N) 🙂 P.S. Отдельным постом птом напишу про решение действительно сложных задач и почему там требуется не просто наращивать команду, а скорее искать центр кристализации (супер-крутого эксперта) и дальше вокруг него выстраивать команду из инженеров с высоким потенциалом. #Management #Leadership #Processes #Team #Software #SoftwareArchitecture

How Technical Problems Cause Organizational Friction • Adam Tornhill • GOTO 2023 (Рубрика #Architecture) Интересный доклад от Adam Tornhill на тему социотехнических запахов (презентация доступна здесь). Суть в том, что наши современные системы очень сложны и они включают как software, так и людей, которые его пишут (пока не это не стали делать LLMs самостоятельно). Обеспечить баланс достаточно сложно, так как из кода напрямую не ясен социотехнический контекст - кто и зачем его написал, а также какие в нем были изменения. Adam Tornhill предлагает использовать подход behavioral code analysis, где мы сочетаем в себе анализ кода с данными о том, как команды взаимодействуют внутри кода, например, кто вносит изменения и насколько параллельно это происходит, как выглядят параметры cohesion и coupling, а также насколько сложно поддерживать код с высоким техническим долгом. Интересно, что за год до этого Adam рассказывал крутой доклад на тему приоритизации техдолга и я об этом рассказывал. Если же возвращаться к behavioral code analysis, то автоор предлагает, использую их, уменьшить организационное трение и сосредочить внимание на ряде общих задач - Выявите узкие места архитектурной координации и поймите технические root causes - Визуализируйте неявные зависимости между командами, а дальше действуйте так, чтобы отделить (decouple) команды - Выявите риски знаний, измерив bus factor. Узнайте, как смягчить его - Сообщите о рисках масштабирования, присущих закону Брукса, показав данные о том, как он влияет на вашу доставку - Выйдите за рамки технического воздействия, зная, как плохой код приводит к низкому моральному духу и увеличению истощения Ну и социотехнические факторы, которые называет автор звучат примерно так 1. The overcrowded system - когда слишком много людей работают над одной системой и дают слишком маленький выхлоп:) 2. Coordination bottlenecks in the code - проблема с большим количеством изменений в одних и тех же файлах вашей системы людьми из разных команд. Здесь очень велика сложность поддержания ментальной модели кода, поэтому это приводит к большему количеству багов и более сложным внесениям изменений. Кажется, что в этой части еще пригодились бы подходы из whitepaper "Architecture Anti-patterns: Automatically Detectable Violations of Design Principles", про которую я рассказывал раньше 3. A propagating cost of change - про change coupling и как изменения в одном месте тянут за собой большое количество изменений в других местах, если change coupling высокий. Как раз недавно я рассказывал про книгу Кента Бека "Чистый дизайн" ("Tidy First?"), где неплохо разбирались вопросы change couplin 4. Dependent work crossing team boundaries - здесь автор говорит примерно про обратный маневр Конвея, где нам нужно так выбрать структуру команд, чтобы она матчилась с желаемой архитектурой. Плюс нам надо так организовать архитектуру системы, чтобы она хорошо укладывалась на problem domain и позволяла организовать естественные границы для команд 5. Unhealthy code with a low Truck Factor - тут автор вспоминает про bus factor и выбывающих людей, а дальше показывает, что если это наложить на нездоровый код, то мы получаем большую проблему. Условно, если мы теряем эксперта по запутанному коду, то наши знания о деталях реализации систем сильно уменьшаются и осуществлять изменения становится дольше и дороже. P.S. У автора есть сайт https://codescene.com/ и книга "Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis", в которой этот подход подробно разобран. Лицензция стоит $300 в год на разработчика. P.P.S. Whitepapers, на которые ссылался автор - The business impact of Code Quality - On-boarding costs in unhealthy code - Happiness and the Productivity of Software Engineers - The Influence of Organizational Structure On Software Quality #SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Architecture #TechDebt #Management

Обложки для книги про глубокое обучение

Глубокое обучение и анализ данных. Практическое руководство Прочитал эту книгу Дмитрия Малова за пару недель, что пришлись на отпуск и разъезды. Книга издана в 2023 году и сопровождается кодом и графиками, что доступны на Github. В книге 270 страниц, разделенных на 8 отдельных глав, причем автор пытается сначала изложить необходимые основы, а дальше уже переходить к практике и примерам: 1. Основы машинного обучения - здесь автор начинает с базиса, в который входит - Линейная алгебра - скаляр, вектор, матрица, тензор, норма - Теория информации и теорвер - случайная величина, распределение вероятности, условная вероятность, матожидание, дисперсия, ковариация, правило Байеса - Основные понятия машинного обучения и решаемые задачи - классификация, регрессия, обнаружение аномалий, машинный перевод, структурный вывод, синтез и выбборка), а также отношение к опыту при обучении и варианты обучения с учителем, без учителя, с частичным привлечением учителя, а также обучение с подкреплением - Основы разработки: синтаксис python, основы ооп (абстракция, инкаспусляция, полиморфизм, наследование и композиция), процессы разработки: waterfall и agile:) 2. Основные алгоритмы машинного обучения - здесь автор начинает с предобработки данных, а дальше рассматривает алгоритмы снижения их размерности: линейные и нелинейные методы, линейную и логистическую регрессию, деревья решений, метод опорных векторов, наивный байесовский классификатор, k-means, k nearest neighbors, случайный лес и алгоритм градиентного бустинга. Все это умещается в 30 страниц, поэтому если вы отдельно не изучали все эти вещи, то иногда сложно успевать за мыслью автора (я слава богу до этого это все уже ботал лет 10 назад, когда у меня был приступ самообразования и я зависал на Coursera и Edx) 3. Основы глубокого обучения - здесь автор начинает с обратного распространения ошибки (backpropagation), дальше рассказывает про персептрон, цепь Маркова, машину Больцмана, сеть Хопфилда, сверточные нейронные сети (CNN), трансформеры, рекуррентные нейронные сети (RNN), автокодировщики, генеративно состязательные сети (GAN). А в конце приводит пример системы, которую автор походу делал для whitepaper или диплома:) 4. Основы data science - интересно, что тут рассказ начинается с методологии работы с данными, а точнее с CRISP-DM (Cross-Industry Standard Process for Data Mining, дальше рассказывается про роли в команде ML-разработки, где примечательны data analyst, data engineer, data scientist. Дальше автор рассказывает про тренды: deep fakes и борьба с ними, интерес бизнеса к обучению end2end моделей, Auto ML для low-code и no-code использования, MLOps (я недавно писал про whitepaper на эту тему от Google и участвовал в подкасте на эту же тему). А заканчивает эту главу автор тем, что рассматривает популярные библиотеки для ML разработки, среди которых хотелось бы упомянуть TensorFlow, PyTorch, Keras 5. Задачи глубокого обучения - в этой главе автор приводит примеры задач и показывает как их можно решать при помощи deep learning. Тут как раз пригодится код из репозитория, чтобы поиграть с задачами самому. Тут есть примеры аугментации данных, компьютерного зрения и использования OpenCV, классическая задача на распознование символов, обработка естественного языка, обработка аудио, а также обработка видео. В общем, в этой и следующих трех главах собрана самая мякотка:) 6-8. Последние три главы посвящены знакомству с TensorFlow, Keras и PyTorch. Здесь показано как решать задачи из 5 главы с использованием конкретной библиотеки. Если финализировать саммари по книге, то она показалась мне кратким интро в область deep learning. В ней есть вся нужная базовая инфа, но чтобы ее понять придется почитать дополнительные материалы. Здесь же есть примеры задач и код, который может стать стартовой точкой для ваших экспериментов. В общем, книга мне скорее понравилась, но надо учесть, что за исключением конкретных библиотек TensorFlow, Keras и PyTorch все остальное я уже достаточно давно и неплохо изучил:) #AI #Math #Statistics #Software #DataScience #ML

Остановка. Мокьюментари-драма с элементами детектива @ Театр "Практика" Вчера мы с женой ходили на эту постановку и нам понравилось. Завязка всей истории звучит так

Однажды муж, отец и успешный бизнесмен Виктор Волков остановил свой BMW 5-й серии возле трамвайной остановки, вышел из машины и сел на скамейку. Это событие привлекло внимание всего города и разрушило две счастливые семьи.

На самом представлении ты попадаешь в небольшой зал, где восемь рядов сидений по 11 мест и сцена начинается прямо от первого ряда:) Сама сцена минималистична - есть наклоненный полукруг в центре диаметром в 3-4 метра с кубиком на нем и 4 отдельных кубика по краям, на которых могут сидеть артисты. Логично, что актеров как раз четверо - двое мужчин и двое женщин, которые играют семейные пары. Все остальные персонажи появляются в виде больших голов прямо внутри наклоненного круга, который оказывается экраном, на котором транслируются их мини-видео интервью в нужные моменты постановки. В общем, интерьер не отвлекает от игры актеров, которые показывают как может выглядеть остановка в жизни каждого человека и к каким последствиям она может привести. Эта постановка местами веселая, а местами грустная, подталкивает на размышления:) #Theater #SelfDevelopment #Culture