Alexa Is in Millions of Households—and Amazon Is Losing Billions (Рубрика #Management)

В продолжение обзора книги "Working backwards" подоспела статья от "The Wall Street Journal" на тему того, как юнит smart devices в Amazon создавал успешные продукты, которые генерировали миллиарды убытков каждый год. Этот кейс интересно разобрать в стыке с примером про Kindle из второй части книги (подробнее здесь). Суть статьи примерно следующая
- В 2014 году был запущен Echo и Alexa с моделью типа Gillette, где сам станок продавался за гроши, а дальше заработок был на сменных лезвиях. Примерно так же делал и Amazon, который демпинговал, продавая Echo
- Через 10 лет Echo у сотен миллионов человек, но этот подход не сработал - люди не стали значимо покупать через товары на Amazon через голосовой ассистент Alexa
- Когда CEO был Джефф Безос направление устройств имело зеленый свет и его значимость измерялась при помощи метрики "downstream impact", который присваивает финансовую ценность продукту или услуге на основе того, как клиенты тратят деньги в экосистеме Amazon после их покупки
- Для некоторых продуктов такой подход работал хорошо - например
-- Для Kindle, так как после покупки читалки пользователи покупали на Amazon электронные книги
-- Для Fire TV, где рекламные объявления можно было аттрибутировать к самому продукту Fire TV
- Но вот для части устройств это работало не очень хорошо и в 2021 году, когда CEO стал Andy Jassy, то он сделал ревью прибыльности бизнес линий и погрузился в бизнес девайсов, где были закрыты: Astro, Halo fitness tracker, Amazon Glow и так далее
- А вот сейчас для Alexa ключевой момент - ребята добавят gen AI, что расширит функции ассистента, а также принесут дополнительные деньги в копилку компании за счет дополнительной подписки

P.S.
В общем, книга + статья смотрятся вместе интереснее:)

#Management #Leadership #Processes #Strategy

Complexity is the Gotcha of Event-driven Architecture • David Boyne • GOTO 2024 (Рубрика #Architecture)

Интересное выступление от David Boyne, Senior Developer Advocate at AWS, который рассказывает в своем докладе про преимущества и недостатки event-driven architecture (EDA). Суть в том, что сложность присуща архитектуре, управляемой событиями, сразу с самого начала, но если использовать правильные подходы, то по мере роста системы эта сложность не увеличивается настолько быстро, как при других подходах к проектированию.
Собственно автор выстраивает свое выступление следующим образом
- Сначала он рассказывает про потенциал EDA - как EDA делает архитектуру эволюционной, а не статичной:)
- Потом он рассказывает про guardrails для того, чтобы справляться со сложностью EDA
- Как можно обосраться с EDA

Потенциал EDA можно увидеть, построив график по двум осям: size и time. Дальше на графике надо отобразить решения, которые надо принимать, а также знания, которые у нас имеются для этого. Суть в том, что в начале проекта знаний у нас мало, а решения нам надо принимать крупные. Это называется "project paradoxon", для решения которого нам надо уметь откладывать крупные решения до получения нужного количества знаний ... или учиться быстрее. Но, принимая решения без нужного количества знаний, мы часто оказываемся в условиях статичной архитектуры, которая характеризуется свойствами: tightly coupled, low cohesion, resistance to experimentation, team interdependency. В противовес этому автор утверждает, что использование EDA позволяет создать эволюционную архитектуру (как в книге "Building evolutionary architecture", подробнее здесь), у которой как говорит автор есть свойства: loosely coupled, high cohesion, platform to experiment, team dependency. К тому же она
- Позволяет создавать компоненты, которые можно менять местами в зависимости от ситуации.
- Повышает качество кода и позволяет экспериментировать.
- Может привести к инновациям, но также увеличивает сложность.

Дальше автор показывает как определить события, а дальше как начать им обмениваться между producers и consumers. Дальше это все начинает эволюционировать и легко получить ад из разных событий, разных producers и consumers и с отсутсвием любого понимания о том, как все это работает:) Для решения этих проблем автор предлагает использовать guardrails
1) Behavior vs implementation - начинать надо не с деталей имплементации, а с поведения системы. Здесь автор вспоминает про Альберто Брандолини и его подход Event storming, про которую я уже вспоминал. Эта техника позволяет начать с событий внутри системы, а в итоге понять ее поведение и заодно разобраться с bounded contexts:)
2) Event evolution strategy - при старте EDA проекта надо подумать про эволюцию событий. Автор приводит метафору о том, что events рассказывают историю, а tables - описывают состояния прямо сейчас. Автор предлагает контролировать сложность схемы событий через обратную совместимость, опциональные поля и параллельные версии событий
3) Define coupling strategy - это можно сделать через использование в консьюмерах подходов conformist, ACL (anti-corruption layer) и open-host principle (хорошо описано в книге "Learning DDD", подробнее здесь). Тут же автор предлагает разделять public и private events - внутри домена или между ними

Но самая большая проблема в том, что есть мантра

Producers should not know about consumers

приводит к тому, что управлять этой системой по мере эволюции становится невозможно. Поэтому автор предлагает использвать следующие инструменты
- cloudevents - cпецификация для общего описания данных о событиях.
- AsyncAPI - фактически, OpenAPI для асинхронных API
- EventCatalog.dev - open source проект автора с описанием, который помогает документировать сообщения, команды, запросы и события, а также создавать версии доменов и служб.

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

#Architecture #SoftwareArchitecture #DDD #SystemDesign #DistributedSystems

How Google Works (Как работает Google) (Рубрика #Management)

Интересная книга от Эрика Шмидта (ex CEO Google) и Джонатана Розенберга (ex VP Google), которая была издана в оригинале 10 лет назад и рассказывает про внутреннее устройство Google. Книга хорошо структурирована и состоит из следующих частей
1) Введение - авторы рассказывают про то, как они оказались в Google и как им пришлось отвыкать от диаграмм Ганта и следовать совету "просто пойди и поговори с инженером". Также они говорят про скорость изменений, которые происходят сейчас в бизнесе, а также тут появляется определение умного креативщика, условного инженера, которым теперь и приходится руководить менеджером. Этот умный креативщик сильно отличается от синего воротничка с конвейера, так как он зачастую лучше знает как именно сделать сложную задачу, которая не пугает его, а скорее заставляет проявить свои лучшие качества.
2) Корпоративная культура - эта глава начинается с рекомендации, что надо "поверить в собственные лозунги", так как культура - это про поведение, а не про громкие фразы. Глава начинается историей про AdWords, когда записки Ларри Пейдж в 2002 году нашел проблему с релевантностью рекламы в поиске и повесил на кухне примеры этой рекламы с комментарием "эта реклама - полный отстой". Дальше за выходные команда умных креативщиков (во главе с Джеффом Дином) никак не связанная с командой AdWords разобралась с проблемой, придумала концепцию и запилила прототип. Это стало возможным благодаря культуре стартапа, где умные креативщики верили в ценности компании и важность пользователя и то, что они делают этот мир лучше. Дальше идет совет про то, что креативщикам лучше работать в тесноте (аля в open space), не слушать Hippo при принятии решений. Авторы делятся своими мыслями про плоскую структуру и организацией команд - приводится совет о том, что команды под одним руководителем должны насчитывать не меньше 7 человек. Вообще, в этой главе много интересных мыслей и хороших историй - рекомендую ее прочитать в оригинале.
3) Стратегия - основная мысль здесь в том, что тяжеловесные стратегии из прошлого не работают в современном динамичном мире. Авторы предлагают делать ставку на технические инсайты, а не на маркетинговые исследования.
4) Кадры - глава посвящена тому, что подбор персонала - это самое важное. А умение проводить собеседования - это важный навык:)
5) Решения - здесь авторы рекомендуют принимать решения на основе данных, говорят о том, как принимать меньше решений, а также, что у решений должен быть "хозяин"
6) Коммуникации - менеджерам авторы советуют быть хорошими маршрутизаторами информации, а также быть открытыми by default. Здесь опять всплывает история про psychological safety и проект Аристотель
7 Инновации - авторы используют метафору первичного бульона, из которого появились первые аминокислоты. Именно такой первичный бульон для зарождения инноваций они и предлагают создавать внутри компании. Они отмечают, что на первом месте при инновациях должен стоять пользователь, а также рассказывают про использование OKR для постановки целей. Также авторы настаивают на том, что надо отгружать продукт пользователям, а потом итеративно его улучшать.
8) Заключение - здесь авторы заботливо приводят основные мысли относительно того, что в современном мире побеждают платформы (подробнее в книге "Machine, Platform, Crowd", про которую я уже рассказывал), а также про важность информации и умения работать с ней.
Книгу действительно интересно читать, хотя есть ощущение, что история получается слишком красивой, чтобы быть правдой:)

#Management #Leadership #Processes #Strategy #SelfDevelopment #Software #Bigtech

AMA сессия нашего core и data tech в Т-Банк (рубрика #Management)

Мои коллеги из наших технологических платформ собрали сегодня сессию Ask Me Anything. Они делают крутые инженерные штуки, но раньше им не хватало внутреннего пиара и открытости. Теперь они решили с этим побороться и собрали на нашей крыше большую встречу, на которой откровенно ответили на вопросы, часть из которых была довольно острой. Думаю, что такие встречи станут доброй традицией.

#Engineering #Management #Processes #Software

ЦЕХ 4 - Урок #11 "Правила сильной книги захватывающего текста. Эксперт — Лариса Парфентьева" (Рубрика #Writing)

Очередной урок из курса МИФа для начинающих/продолжающих авторов на пути к своей книге. Интересно, что этот урок был больше сфокусирован на художественной литературе, а я неторопливо пишу non-fiction. Но даже так его было интересно послушать и попытаться намотать на ус подходы, которые можно использовать в своей книге. Эксперт построила свой рассказ прямо по пунктам и вот они
1) Проверьте начало и конец каждой главы - если начало главы не интересно, то дальше можно и не читать. А если окончание не интересное, то конверсия перехода к новой главе может просесть:)
2) Проверьте героя на симпатичность - читатели обычно хотят сопереживать героям, но если герой совсем не вызывает симпатии, то высока вероятность закрыть книгу вместо погружения в приключения героя
3) Задайте вопрос "Можно ли отложить достижение цели" - если ответ да, то конфликт не достаточно мощный для того, чтобы за ним было интересно следить читателям. Важно, чтобы было ощущение urgency
4) Герой должен сомневаться в себе - если это не так, то читателям не интересно следить за приключениями идеального героя, у которого нет никаких сомнений
5) Не рассказывайте, а показывайте - картинка является важным инструментом для движения сюжета.
6) Проверьте плотность фактуры - в тексте должна быть определенная плотность смысла.
7) Проверьте скорость текста - если скорость разная, то где-то читатель заскучает, а где-то наоборот начнет пробуксовывать и упустит какую-то важную мысль
😍 Не забывайте про метафоры - я помню, как про их важность узнал больше 20 лет назад из классической книги Стива Макконелла "Code Complete", о которой я уже рассказывал
9) Сокращайте - если что-то можно выбросить из текста без потери смысла, то это стоит сделать. Тут вспоминается цитата Антуана де Сент-Экзюпери

Совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять.

Ну и эксперт предлагает
- Убирать лишние слова и детали, которые не влияют на смысл текста.
- Использовать активный залог вместо пассивного.
- Избегать причастных и деепричастных оборотов, слов-паразитов и усилителей.
- Не злоупотреблять восклицательными знаками.
10) Не останавливайтесь на одной книге - первая книга - это только начало:) После первой книги будет вторая, третья, ...

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

Предыдущие посты доступны здесь:
1) Увидеть свое имя на обложке может каждый
2) Целевая аудитория и ее потребности в создании книги
3) Жанры и стили. Как найти тему для нон-фикшн-книги
4) Как организовать работу
5) Как преодолеть писательские блоки. Практическое занятие
6) Жду музу, а она все не приходит
7) Книга по полочкам
😍 MS Word для работы с большими и сложными текстами
9) Рассказываем истории: сторителлинг в книге
10) Саморедактура: работа с текстом, сокращения, фактчекинг

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Дизайн пользовательского опыта (Design for How People Think: Using Brain Science to Build Better Products) (Рубрика #Design)

Эта книга Джона Уэлена рассказывает про создание UX дизайна продуктов с использованием знаний о человеческой психологии. Автор пытается разложить опыт клиентов на шесть компонентов, а дальше использовать их для создения идеального продукта. Английская версия была издана в 2019 году, а в этом году ее неплохо перевел МИФ. Автор неплохо разбирается в когнитивной психологии и использует ее для того, чтобы быть лучше как продуктовый дизайнер.

Если говорить про 6 основных составляющих подхода автора, то это
1) Визуальное восприятие, внимание и автоматизм - что привлекает потребителей? Какие слова, изображения и объекты они стремятся найти?
2) Навигация - Как потребители понимают пространство, в котором они находятся (в физическом мире и в виртуальном)? Как они ориентируются в этом пространстве, как представляют себе взаимодействие с ним, а также с другими участниками?
3) Язык - Какие слова используют потребители? Какой смысл они вкладывают в эти слова? Как можно понять их уровень подготовки из того, какие слова они используют?
4) Память - Какой прошлый опыт используют потребители при взаимодействии с вашим продуктом? Какие ментальные модели и стереотипы участвуют при этом, какие у них ожидания того, как будут работать вещи в этом мире и что будет дальше?
5) Принятие решений - Какую проблему решают потребители с их точки зрения? Совпадает ли их мнение о проблеме с реальной проблемой? Какие промежуточные проблемы надо решить на пути к главной цели?
6) Эмоции - В чем состоят глубинные цели, желания и страхи потребителей? Какие из этих эмоций влияют на принятие решений? Чего они стремяться добиться?

На эти моменты автор обращает внимание при проведении контекстных интервью, которые автор ценит выше фокус-групп, опросов и глубинных интервью. Если объяснять на пальцах, то это такой тип интервью, что
- Проводится в обычной рабочей/домашней обстановке потребителя
- Исследовать наблюдает за выполнение работы потребителем
- И задает уточняющие вопросы для того, чтобы понять почему потребитель делает то или другое действие
Автор предлагает проводить десятки таких интервью в поисках инсайтов и дальше их классифицировать по 6 приведенным выше категориям. Дальше после такого анализа можно провести сегментацию потребителей и сформулировать гипотезы о том, как улучшить продукт. Например, автор рассказывает про создание лендинга для малого и среднего бизнеса, что хочет подключиться к Paypal. Он объясняет как было проведено исследование, какие гипотезы были созданы, а дальше получился лендинг. Мне кажется, что он пропускает часть с большим количеством a/b тестов, но ему это простительно, так как он скорее занимается качественными исследованиями.

Ближе к концу книги автор рассказывает про дизайн-мышление (design thinking) и процесс дизайн double dimond.
В общем, это очень простаяя, но полезная книга для создаетелй продуктов:)

P.S.
Мне на самом деле ближе количественные исследования, поэтому рекомендую глянуть книги на тему проведения a/b экспериментов, про которые я рассказывал раньше
- Как лгать при помощи статистики (How to Lie with Statistics) - на пальцах объясняется как врут с помощью статистики, а отсюда становится ясна мотивация создания системы подведения итогов экспериментов
- Understanding Statistics and Experimental Design. How to Not Lie With Statistics (Статистика и планирование эксперимента для непосвященных) - в этой книге рассказывается про дизайн экспериментов и математику, что стоит за ними
- Доверительное a/b тестирование (Trustworthy Online Controlled Experiments) - а эта книга позволяет еще и понять как сделать платформу для проведения экспериментов на уровне всей компании
- Темные данные (Dark Data. Why What We Don’t Know Is Even More Important Than What We Do) - книга про то, как можно облажаться с данными и что с этим можно сделать

#Architecture #Management #Thinking #Leadership #SystemDesign #SystemThinking #Design

Stackoverflow Developer Survey 2024 (Рубрика #Management)

Последние N-лет я участвую в опросе stackoverflow для разработчиков, а потом с большим интересом рассматриваю результаты. В этом году они представлены в виде красивого сайта, на котором есть крутые визуализации, собранные в 7 категорий, в каждой из которых были следующие важные моменты
1. Developer Profile - профиль разработчика, что участвовал в опросе.
- Топ 5 участников было из стран: США, Германии, Индии, UK, Украины
- У 66% разработчиков есть бакалавраская или магистерская степень.
- Обучение программированию онлайн предпочитают 82% участников
- Также 90% читают документацию к API и SDK для обучения
2. Technology - этот блок посвящен технологиям
- Postgres - самая популярная база данных (49% используют ее)
- Docker - самая популярная технология (59% используют ее)
- Jira и Confluence - самые популярные средства для асинхронной работы
- JavaScript, Python и SQL - это востребованные и почитаемые языки программирования, но Rust наиболее почитаем (83%)
- 73% хотят поработать со Svelte (очередной фронтовый фреймворк)
- Большинство разработчиков, использующих chatGPT, хотят продолжить его использовать (75%), конкуренты в виде Replit Ghostwrite или Tabnine имеют показатели в 2 раза ниже
- Самыми популярными AI инструментами являются chatGPT и GitHub Copilot
3. AI - блок про проникновение AI в разработку
- 76% участников планируют использовать AI инструменты в разработке в этом году
- Участники видят такие топ 3 сценария использования AI: documenting code (81%), testing code (80%), and writing code (76%)
- 70% не видят угрозы своей работе от AI
- Основные опасности AI видятся в неверной информации (79%) и source attribution (65%)
4. Work - блок про работу
- 84% работают, большая часть full-time, но часть part-time или на фрилансе
- Большинство работают по гибридному графику (40%), полностью удаленно (38%), полностью очно (20%)
- При приобретении технологии важен доступ к API, 75% участников отметило, что с большей вероятностью одобрят вашу технологию, если вы предоставите доступ к API
- Медианы зарплат почти по всем стекам уменьшились где-то на 10 тысяч долларов с прошлого года
5. Community - блок про сообщество
- 93% участников посещают сайт stackoverflow несколько раз за месяц
- Приходят они за ответами на свои вопросы
- Чаще посещают stackoverflow начинающие учить код
6. Professional Developers - блок про профессиональных разработчиков
- 25% IC (individual contributors) имеют опыт от 1 до 4х лет, и большинство IC, что участвовало в опросе, в начале или середине своей карьеры. А вот people managers ближе к середине или поздней части своей карьеры
- 87% участников - это IC, 13% - это менеджеры
7. Methodology - блок про методологию
- Участников опроса было 65,437 человек, из которых 48,019 пошарили информацию о зарплате

#Software #Management

ЦЕХ 4 - Урок #12 "Авторская стилистика. Эксперт — Екатерина Дронова" (Рубрика #Writing)

Очередной урок курса МИФа про написание книг был посвящен авторской стилистике. Екатерина Дронова, эксперт и автор курса "Сильный текст" рассказывает про стилистику и подачу для разных видов книг, включая художественные и нехудожественные. Основные моменты, которые мне отозвались в этом уроке следующие
1) Классификация видов нон-фикшен текстов
- Книги для систематизации знаний - отвечают на вопрос "что нужно знать в этой области?"
- Обучающие книги - отвечают на вопрос "как это сделать?"
- Книги, направленные на познание - отвечают на вопрос "как это устроено?"
- Книги для развлечения - отвечают на вопрос "как живут другие люди?"
2) От типа книги зависят особенности подачи
Систематизирующий, обучающий и познавательный текст
- Может не иметь художественной ценности
- Должен быть информативным, но не должен быть наукоемким (иначе читатели не поймут)
- Должен быть четко структурированным по главам, которые должны иметь повторяющуюся структуру
Познавательный текст
- Должен иметь художественную ценность и содержать элементы драматургии и саспенс
- Должен говорить на понятном читателю языке и передавать личную историю
Эксперт приводит такую метафору

Сюжет - это вагон, который автор нагружает смыслами. Если вам нужно проиллюстрировать понятие, опыт, процесс - расскажите историю.

Тут рекомендую почитать материалы про сторителлинг, о чем я уже писал раньше в этом канале
- про мастер класс по сторителлингу
- про то, как сторителлинг сделал нас людьми
- про тысячеликого героя - классическая книга про путь героя
- про работу сценаристов - классический подход для написания сценариев
- про создание подкастов и рассказывание историй
- про фрирайтинг для решения задач
- про черную риторику и власть слова
- про искусство словесной атаки
- про публичные выступления с прошлого MBA с Ниной Зверевой
- пример крутого выступления с рассказом истории - последняя лекция Randy Pausch
- про откровения оратора про выступления и истории
- про построение историй и выступления в лекции от Yandex
- про риторику и поэтику от Аристотеля
- про нейробиологию чтения

А предыдущие посты на тему этого курса писательского мастерства доступны здесь:
1) Увидеть свое имя на обложке может каждый
2) Целевая аудитория и ее потребности в создании книги
3) Жанры и стили. Как найти тему для нон-фикшн-книги
4) Как организовать работу
5) Как преодолеть писательские блоки. Практическое занятие
6) Жду музу, а она все не приходит
7) Книга по полочкам
😍 MS Word для работы с большими и сложными текстами
9) Рассказываем истории: сторителлинг в книге
10) Саморедактура: работа с текстом, сокращения, фактчекинг
11) Правила сильной книги захватывающего текста

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

The Philosophy of Architecture - Barry O'Reilly - NDC Oslo 2024 - Part I (Рубрика #Architecture)

Очередное крутое выступление Barry O'Reilly на тему архитектуры (про выступление "An Introduction to Residuality Theory" я уже рассказывал). Здесь автор делает краткий обзор философских идей со времен древних греков до текущего момента и приходит к философскому подходу, который лежит в основе его Residuality Theory.

Основные идеи выступления следующие
1) Барри работал над PhD и смог взглянуть на архитектуру и разработку софта по новому - я тоже хочу заняться PhD в ближайшие годы:)
2) Барри задумался о том, как философские идеи влияют на процесс принятия решений (философия предполагает, что вы задаете вопросы к своим assumptions)
3) Барри выделяет основные проблемы с архитектурой
- Время, изменения во времени, неопределенность с тем, а какие это будут изменения
- Что такое единица измерения для софта - автор для начала вспоминает про 4 стихии древних греков (земля, огонь, ветер, вода), потом физику (атом, частица), химию (молекулы), биологию (клетки), а потом переходит на SWE, где у нас есть комьютеры, процедуры, модули, объекты, сервисы, функции, микросервисы, процессы, фичи, паттерны. В общем, разработка софта еще в фазе "древних греков" по мнению автора
4) Барри вспоминает Томаса Куна с его книгой "Структура научных революций" 1962 года, где появилась идея про сдвиг парадигмы и то, что научное знание развивается скачкообразно, посредством научных революций. Любой критерий имеет смысл только в рамках определённой парадигмы, исторически сложившейся системы воззрений. Научная революция — это смена научным сообществом объясняющих парадигм. Автор говорит, что в софтостроении такие изменения происходят каждые шесть недель (типа выход нового js фрейморвка) 🙂
5) Дальше автор дает введение в философию
- Эссенциализм - это идея о том, что у всего есть основная сущность, и что мудрость обретается, когда мы приближаемся к пониманию этой сущности. Объектно-ориентированное программирование примерно про это - мы имеем идеальный класс и его экземпляры, выполняющиеся в реальности.
- Позитивизм - философское учение и направление в методологии науки, определяющее единственным источником истинного, действительного знания эмпирические исследования и отрицающее познавательную ценность философского исследования. Этот подход свойственнен многим разработчикам
- Interpretivism (антипозитивизм) - подход в социальных науках, который противоположен позитивизму. Он позволяет существовать разным взгядам на одну и ту же реальность. Отрицает научные подходы в применении к социальным системам (а разработка софта - это социотехническая система), а также говорит о том, что мы не обнаруживаем знания, а создаем и передаем идеи в ходе обсуждений:)
- Структурализм - в языке источник истины, поэтому надо заниматься анализом требований и отсюда же рождается DDD (domain driven design)
- Кибернетика - наука об общих закономерностях получения, хранения, преобразования и передачи информации в сложных управляющих системах, будь то машины, живые организмы или общество. Отсюда у нас есть страсть к моделированию организаций и людей как машин на основе control systems и feedback loops
- Causality - концепт того, что между разными событиями существуют причинно-следственные связи (конструкции вида if ... then)
- Models - идеи о том, что мы создаем модели реальности и живем с помощью этих моделей, а не реальности. Здесь автор вспоминает про французского философа Бодрийяра и его книги "Симуляция и симулякры" (говорят, что фильм "Матрица" отчасти основан на этой концепции). Дальше проводится параллель между архитекторами в software engineering и архитектором из матрицы
- Complexity - при попытке сбежать из матрицы мы сталкиваемся с проблемами сложности. Иногда их пытаются подавить (например, YAGNI) или просто двигаться итерациями (авось как-нибудь победим). Но тут нужны новые концепции

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

#Philosophy #DistributedSystems #SystemDesign #Math #Engineering #Architecture #SoftwareArchitecture #ComplexityTheory #Software #Processes

The Philosophy of Architecture - Barry O'Reilly - NDC Oslo 2024 - Part II (Рубрика #Architecture)

Продолжая пост про философию и архитектуру расскажу какую концепцию предлагает Барри для борьбы со сложностью.
1) Substance philosophy - западный подход к философии сконцентрирован на вещах и похож на интеллектуальную тюрьму. Но есть выход
2) Process philosophy с тезисами вида

- Identity is about becoming
- Nothing is truly static
- Including our phenomena - every time we look at a static thing we contemplate it differently

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

3) Отсюда автор выводит концепцию criticality, которая говорить про возможность выдерживать условия, которых не было в спецификации. На самом деле это свойство, описанное автором больше похоже на выживаемость (survivability). Автор говорит о том, что биологические системы обладают такими свойствами, но в software engineering есть такая вилка, что
- SDE (software developemnent engineers) больше целятся в корректность систем, то есть в том, чтобы система делала то, что ее попросили
- Архитекторы больше целятся в survivability, когда система адаптируется к условиям и продолжает работать
- И это две большие разницы

Дальше автор на примере показывает как ключевые концепции, заложенные в создание системы, ломаются при изменениях. Этот пример основан на концепте "Customer", который сначала является физлицом, потом добавляются юрлица, а потом зарубежные юрлица. Это приводит к изменениям в архитектуре, а точнее к сдвигу парадигмы (как у Томаса Куна в книге "Структура научных революций"). И здесь появляется концепция residue, на которой зиждется подход автора, что он изложил в научной статье "Residuality Theory, random simulation, and attractor networks" и рассказал в крутом докладе с введением в эту теорию, о котором я уже рассказывал. Основная суть в том, что residue по мнению автора теории
- Является единицой архитектуры софта
- Является контейнером для компонентов
- Описывает архитектуру для алтернативных временных линий
- Каждая архитектура состоит из residues
- Они происходят в последовательности
- Мы их обнаруживаем исследуя
- Мы принимаем гипотезы посредством случайного моделирования
- У нас есть стат значимые результаты

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

P.S.
Рекомендую почитать книги про системное и критическое мышление, о которых я как-то уже писал раньше.

#Philosophy #DistributedSystems #SystemDesign #Math #Engineering #Architecture #SoftwareArchitecture #ComplexityTheory #Software #Processes

*Next-Door Tech CEO 2024* (Рубрика #Management)

Офигенное видео про CEO технической компании. Забавно, что я прямо до Тинькофф успел поработать deputy CTO чуть меньше четырех месяцев в стартапе примерно с таким бизнесовым руководителем. Когда я смотрел это видео, то ловил флешбеки от фраз вида

- You're supposed to be intrinsically motivated.
- We pivoted 4 times this week
- I'm fully on a keto diet because Steve Jobs said stay hungry
- We'll forever maintain a flat hierarchy
- I don't think you've put in enough midnight oil
- Full time is 27-27
- This is our employee of the month (про собаку)
- It isn't just a web3 blockchain integration company, a new civilization
- Technology, the solution to man's deepest problems
- 10x, vibes, techno, technology

Уже после моего перехода в Тинькофф я посматривал на этот стартап и
- Этот CEO в какой-то момент понял, что бизнес - это не его и пошел инфоцыганить про продуктовый менеджмент, а дальше про web 3.0.
- Сама компания через некоторое время свернула свое направление разработки и продолжило заниматься маркетингом поверх общедоступных инструментов.
Со времен этой компании я обращаю больше внимания на свой bullshit bingo метр при общении с людьми, а также если меня зовут помочь, то я задаю вопрос, а куда делся человек с той позиции, на которую меня зовут:)

P.S.
У автора этого канала есть очень крутые видео и про другие профессии в IT:)

#Management #Leadership #Processes