Книжный куб

How We Write Better Software with Low-Code • Michiel Overeem • GOTO 2023 Интересное выступление про low-code платформу от Michiel Overeem, который рассказал как голландская компания AFAS пришла в своем SaaS продукте (смесь ERP, CRM, CMS, и других трехбуквенных слов) к подходу с low-code. По-факту, продукту уже почти 3 десятка лет и за это время он прошел путь от MS DOS программы до того, что разворачивается где-то на серверах и превратился в legacy:) Дальше появилась задача разделить доменную логику и технологическую часть. Знания о бизнесе должны были остаться в моделях, чтобы можно было спокойно развивать технологии. В компании решили это сделать через создание low-code движка, которым будут пользоваться внутренние сотрудники, доменные эксперты, для создания/редактирования бизнес-процессов и пользовательских сценариев работы с системой. Модели из домена по этой логике должны быть свободной от технологий, описывать процессы и роли в реальном мире. В low-code платформу пришлось нехило вложиться и поработать над архитектурой, получился в итоге фреймворк для создания интерфейсов и бекенд фреймворк. 95% функциональности генерируется на основе модели, что создаются citizen developers (это люди, что используют low-code платформу и о самом термине я рассказывал подробнее раньше), а 5% пишутся вручную силами инженеров. Дальше автор выступления рассказывает про преимущества такого подхода: - Создание модели предметной области позволяет разработчикам писать код, тестировать его и помещать в генератор, что упрощает процесс разработки. - Модель предметной области позволяет заменять технологии и интерфейсы, сохраняя знания в модели. - Citizen developers могут вносить изменения в модель без вмешательства инженеров, что повышает продуктивность и позволяет им создавать прототипы и экспериментировать. - Citizen developers могут создавать программное обеспечение, используя свои знания в области бизнеса, что позволяет им создавать прибыльные подпродукты Но есть и проблемы - Citizen developers могут вносить вносят ошибки в модель, что усложняет процесс отладки и требует привлечения программистов для консультации. - Citizen developers должны понимать как их изменения в модели влияют на runtime свойства софта, что требует дополнительных инструментов и обучения Ну и дальше идут выводы - Low-code не является универсальным решением для всех частей приложения - Стоит использовать low-code только в определенных частях, где можно найти повторяющиеся фрагменты, так как это позволяет работать над этими частями не инженерам, а citizen developers - Low-code стоит рассматривать как дополнительный инструмент для повышения производительности и создания лучшего программного обеспечения. В общем, достаточно простой и понятный доклад про то, как компании приходят к low-code решениям как части своего продукта. У нас по такому принципу сделана, например, low-code платформа для маркетинга, в которой сами аналитики могут выстроить процесс маркетинговых коммуникаций с определенными сегментами наших клиентов. #Software #Engineering #Architecture #PlatformEngineering

Искусство системного мышления (The Art of Systems Thinking) Эта книга Джозефа О'Коннора и Иана Макдермота является одной из самых простых и понятных книг по системному мышлению, что я читал. Вместо заумной теории и сложных объяснений авторы предлагают кучу практических примеров, которые они вплетают в повествование так, что концепции системного мышления вы узнаете в бытовых ситуациях, навроде, ссоры со своей второй половинкой, потребления алкоголя или обучения новому. Книга читается буквально влет, благо она компактная и состоит из следующих частей Часть 1 - Мышление за пределами очевидного 1. Что такое система? - авторы дают простое определение "Система есть сущность, которая в результате взаимодействия ее частей может поддерживать свое существование и функицонировать как единое целое", а дальше используют его для сравнения систем и просто групп объектов, чтобы показать разницу. Дальше идет речь про системные или эмерджентные свойства, когда целое больше суммы частей. Обсуждаются простые и сложные системы, система как паутина взаимосвей, стабильность и принцип рычага. 2. Контурное мышление - авторы рассказывают про feedback loops, которые позволяют системе обрести интересные свойства, но одновременно усложняющие предсказание происходящего в системе. Эти петли бывают усиливающими (положительная обратная связь) и уравновешивающими (отрицательная обратная связь). Авторы показывают кучу примеров и объясняют почему терминология усиливающие/ослабляющие лучше:) Плюс они показывают какой интересный эффект возникает, когда обратная связь запаздывают и возникают колебания в системе. Часть 2 - Построение ментальных моделей 3. Ментальные модели - при мышлении мы опираемся на встроенные ментальные модели (идеи, верования и убеждения), которые определяют нашу интерпретацию событий, выбор варианта действия и его реализацию. Нам надо знать про свои ментальные модели, т.к. мы используем их для придания смысла другим системам. В создании и поддержании этих моделей участвуют 4 механизма: вычеркивание, конструирование, искажение и обобщение. Ну и есть другие факторы, что приводят к искаженному восприятию опыта: регрессия, временные рамки, избирательная трактовка опыта 4. Причина и следствие - причинно-следственная связь в системах сложнее линейной - из-за циклов причина может порождать следствие и наоборот. Есть три стандартных заблуждения из линейного мира: разделимость причины и следствия, отсутствие учета времени (следствие сразу идет за причиной), пропорциональность следствия причине. Дальше авторы говорят, что работая со сложными системами, надо определять границы системы, а также искать аттракторы (стабильные состояния, к которым тяготеет система) 5. За пределами логики - формальной логики не достаточно, когда мы имеем дело с системами. Нужен системный подход и метапозиция, что позволяет выйти за пределы стандартной системы отсчета. Для изменения состояния систем часто лучшими точками приложения усилий являются наши ментальные модели Часть 3 - Мыслить по новому 6. Обучение - рассказ про 2 типа обучения: простое и порождающее. В простом обучении мы используем обратную связь для корректировки своих действий для лучшего достижения нашей цели. В порождающем обучении у нас 2 контура обратной связи и мы не просто корректируем свои действия, но корректируем и свои ментальные модели. 7. Ракурс, перспектива - рассказ про важность точки зрения и расширение наших ментальных моделей. В системном мышлении используется как объективный подход (взгялд на систему снаружи), так и субъективный подход (взгляд на систему изнутри). Причем выбор подхода зависит и от того, а как мы определяем границы системы. Часть 4 - Рисуем выводы - рассказ как можно визуализировать структуру системы и взаимосвязи, используя контуры обратной связи (куча примеров) Часть 5 - Замыкаем круг - авторы показывают как использовать весь приведенный до этого инструментарий системного мышления, например, если результаты не соответсвуют усилиям. Часть 6 - Источники - история того, как системное мышление появилось и развивалось в 20 веке. #Brain #SelfDevelopment

How Cognitive Biases Affect our Software Architectures • Birgitta Böckeler • YOW! 2022 Это интересный доклад для архитекторов, в котором рассматривались следующие предубеждения, которые важны нам при проектировании софта: - Confirmation biases характеризуется тем, что люди подсознательно работают с информацией так, чтобы подтвердить свою точку зрения. Это приводит к тому, что люди с трудом принимают изменения и склонны к повторению своих предыдущих решений и действий. Именно поэтому часто нам так сложно менять устоявшиеся процессы разработки или архитектуру решения - обычно это требует от руководителей мастерского управления изменениями. Я часто сталкивался с этим bias у других, да и ловил его у себя самого. - Zero risk bias — этот bias влияет на то, как люди управляют рисками. Зачастую есть желание полностью исключить небольшой риск, а не смягчить общий риск даже на большую величину. Это относится к security рискам, избеганию vendor lock in или наличию преждевременных оптимизаций, которые могут защитить нас от рисков масштабирования, но часто не пригождается в итоге, а стоят дорого. Этот bias можно обойти, если иметь фреймворк для работы с рисками и использовать его в своих проектах. - Availability heuristics - этот bias про принятие быстрых, но иногда не самых правильных решений. И мы строем свои выводы на доступной информации. В разработке софта это например проявляется в том, что часто про техдолг забывают, так как он бывает явно не зафиксирован и его как бы нет:) Поэтому стоит идти от обратного - делать так, чтобы информация о важных вещах была легко доступна. В разработке софта это относительно легко сделать используя логи, метрики, трейсинг как для технических систем, так и для самих процессов разработки. - Base rate fallacy - этот bias влияет на то, как мы оцениваем вероятность разных сценариев, а дальше как мы распределяем силы своих команд. Часто мы уделяем больше внимания edge cases, про которые мы знаем много, в ущерб каким-то более общим сценариям. Этот bias влияет на приоритизацию усилий, поэтому классно, если у вас есть +/- стандартные метрики для оценки и сравнения важности задач между собой. - Outcome bias - этот bias про то, что люди оценивают принятые решения на основании результатов. У нас есть поговорка “победителей не судят” и она как раз про это. Но гораздо продуктивнее поменять подход к оценке решения, ориентируясь на ту информацию, которая была доступна в момент принятия решения. В разработке этот подход применяют, когда используют процессы с написанием RFC (request for comments) и ADR (architecture decision records). Это позволяет постфактум оценивать качество решений, а не просто отталкиваться от результатов. - Self-serving bias - этот bias о том, что люди склонны приписывать успех своим способностям и усилиям, а неудачи - внешним факторам. Это тоже влияет на то, как мы оцениваем свои решения. И этот bias мешает нам расти над собой, потому что мы свои точки роста выводим из своей зоны контроля апеллируя к слепому случая. Гораздо конструктивнее следовать пословице “на ошибках учатся”. P.S. Доклад хорошо продолжает вчерашний пост про Sunk cost fallacy (Невозвратные затраты) #Thinking #CriticalThinking #Reasoning #Philosophy #SelfDevelopment #Brain #Management #Leadership

Sunk cost fallacy (Невозвратные затраты) Sunk cost fallacy - это интересное явление, при котором человек не хочет отказываться от стратегии или курса действий, потому что он вложил в них значительные средства, даже если очевидно, что отказ будет более выгодным. Забавно, что есть и смежные эффекты вида: - Эффект Икеи - когнитивное искажение, проявляющееся когда покупатели непропорционально высоко оценивают значимость (ценность) товаров, которые они создают отчасти сами (например, собирают из деталей) - Синдром NIH (not invented here) - позиция в социальной, корпоративной или организационной культурах, при которой избегается использование или покупка уже существующих разработок, исследований, стандартов или знаний из-за их внешнего происхождения и затрат. Эти ошибки мышления проникают во многие важные решения, даже если мы знаем про них:) Для того, чтобы с ней бороться, можно задавать себя явные вопросы вида: - Если бы я не вложил столько сил в проект, то я бы настаивал на его продолжении? - Если бы мы уже не было сделано X, то мы бы сделали его заново? - Какие у нас есть альтеративы ? Причем туда входит как активные опции по изменению текущего состояния, так и сохранение статуса кво. В общем, полезно знать про собственные предубеждения и пытаться принимать решения, избегая их:) А для того, чтобы знать про них можно посмотреть выступление "Keynote: Debug your thinking - Laila Bougria - NDC London 2024", про которое я писал раньше, а также почитать книги из подборок 1) На тему системного и критического мышления 2) На тему работы мозга Плюс можно глянуть седьмой выпуск Code of Leadership про работу мозга "Your brain at Work", который был с Эрнесто Инаркиевым, чемпионом Европы по шахматам, гроссмейстером, который входит в ТОП-100 лучших шахматистов мира и в ТОП-30 по быстрым шахматам. #Thinking #CriticalThinking #Reasoning #SelfDevelopment #Brain #Management #Leadership

MLOps в теории и на практике Недавно вышел первый эпизод совместного подкаста Тинькофф Образования и Высшей Школы Экономики. Он был посвящен теме MLOps. Сейчас темы AI/ML у всех на слуху: все пытаются использовать LLM для оптимизации существующих процессов, кто-то старается придумать прорывные идеи, а кто-то боится этих изменений. В университетах сейчас есть большое количество курсов по обучению data science и machine learning, но в реальных компаниях зачастую надо не просто создать хорошую модель, но и сделать кучу других приседаний, которые можно назвать MLOps. Если описывать суть, то нужна четкая связь между Data engineering, App engineering и, собственно, ML engineering. Причем выстроенные процессы работы с данными нам нужны как пререквизиты для эффективной работы над ML-моделями, а App engineering нужен, чтобы обученные модели хорошо работали в продакшене и обслуживали запросы. В обсуждении участвовали - Дмитрий Ушанов, технический директор ML платформы - Евгений Соколов — академический руководитель ПМИ ФКН ВШЭ - и я Кстати, узнавать про новые выпуски эпизодов этого подкаста и о других образовательных новостях Tinkoff можно в telegram канале "Тинькофф Образование" (@tinkoff_fintech). P.S. Я уже разбирал в двух постах в этом канале (1 и 2) тот простенький whitepaper об MLOps от Google, который мы использовали в качестве каркаса обсуждения на подкасте. #ML #Devops #Data #AI #Software #Architecture #Processes

Calista Luxury Resort Только в воскресенье вечером мы вернулись с семьей из отпуска, который провели в Турции в отеле Calista. Мы туда летаем уже второй год подряд в апреле и я решил поделиться впечатлениями от отеля, который мне кажется отличным вариантом для отдыха - Во-первых, это крутой отель для поездки семьей - у нас трое сыновей разных возрастов (18, 8, 3) и очень сложно найти место, где все они смогут заняться чем-то интересным для них, но в Calista с этим полный порядок - для малышей есть крутой детский клуб, для подростков - подростковый клуб, а родители могут отмокать в море. - Во-вторых, есть какое-то ощущение в отеле, что все сделано на уровне и ты можешь отпустить ситуацию и, пристроив детей, отдохнуть на пляже, посидеть в кафешке, попить капучино и съесть чизкейк:) - В-третьих, в этом отеле не так много людей в начале апреля - я не люблю толпы людей, но уже все есть, чтобы искупаться даже при холодном море - В-четвертых, в Calista есть футбольный кемп от Paris Saint-Germain Football Academy для детей от 6 до 16 лет, так что если вы и ваши дети любят футбол, то можно записать их в этот летний лагерь:) В общем, мне в этом отеле нравится отдыхать в апреле, поэтому я и в следующем году планирую продолжить эту традицию:) #ForKids #ForParents

Code of leadership #14 - Interview with Artem Ivanov about Risk Tech В четырнадцатом выпуске подкаста я общаюсь с Артемом Ивановым, техническим руководителем отдела Риск Технологий. В этом видео Артем делится историей о том, как можно вырасти от джуна до руководителя отдела, причем отдела, который влияет на весь бизнес большой компании. А также он преоткрывает завесу тайны над тем как инженерно устроена работа с рисками внутри Тинькофф. За час мы успели поговорить про - Инженерный путь Артема и становление его руководителем - Развитие домена рисков и выстраивание взаимодействия с другими командами - Имплементацию топологии команд с платформенными и продуктовыми командами - Как Артем управляет своим временем и распределяет его по разным активностям - Как Артем участвует в развитии профессиональных community внутри компании и зачем он этим занимается - Советы от Артема на тему саморазвития #Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

ЦЕХ 4 - Урок #5. "Как преодолеть писательские блоки. Практическое занятие. Эксперт — Юлия Баяндина" Продолжая серию постов про свое обучение книгописательству (смотри предыдущие посты: 1, 2, 3 и 4), я расскажу про пятый урок. Он был посвящен тому, как преодолевать писательские блоки. Это практическое занятие вела Юлия Баяндина — партнер и содиректор МИФа, которая девять лет назад с нуля выстроила систему контент-маркетинга. Занятие было практическим - каждый участник работал со своим листом A4, который он постепенно заполнял текстом в следующем порядке 1) Воспоминания о своем детстве, юности и других периодах жизни. Я родился на берегу Белого моря в городе Северодвинске и до 18 лет жил с видом на побережье, за которым начинался хвойный лес, который уходил в бесконечность и сливался с горизонтом:) 2) Светлые воспоминания о каждом десятилетии, например, в детстве мне очень нравилось понимать что-то новое об окружающем мире - я был любопытен и любил мучить окружающих вопросами:) 3) Воспоминания о начале писательской деятельности. У меня первым опытом было написание фанфика на трансформеров, которые мне нравились в детстве. В итоге, я попробовал написать что-то по ним в первом классе ... круто, что старых тетрадок не сохранилось:) Ну а сейчас у меня есть желание перейти от статей к крупной форме и соединить их в книгу. 4) Мысли о том, что такое творчество. Мне кажется, что моя текущая работа тоже имеет творческую природу, так как решение комплексных задач до сих пор тешит мою любознательность и позволяет не скучать:) Ну и последние несколько лет я творчески подхожу к изложению своих мыслей в блоге и канале 5) Описание того, а что для нас это книги. Для меня книги - это способ отдохнуть и зарядиться энергией. А своя книга - это способ выгрузить на бумагу мысли, которые крутятся уже давно. Надеюсь, что потом я смогу чуток отпустить эти темы и переключиться на смежные 6) Наши мысли про профессию или роль писателя. И кто из авторов может быть для нас примером. Конкретно для меня авторы - это люди, которые проявили силу воли и смогли дописать свою книгу и изложить свои мысли на бумаге. Я прочитал много книг и мне нравится слишком много авторов, чтобы выделять конкретных. 7) Чем мы хотим поделиться с аудиторией. На этот вопрос я отвечал еще в первой домашке и я хотел рассказать про менеджмент и техническое лидерство в IT. Книга о том, с какими задачами сталкиваются лидеры в технологических компаниях России и мира. В книге не стоит задача описать каждую ситуацию и ее решение, скорее я хочу поделиться своей системой мышления, которая позволит читателям стать эффективнее в плане лидерства. 😍 Описание своих читателей и целевой аудитории. Для меня целевыми читателями будут инженеры и инжиниринг менеджеры, которые сталкиваются с техническими и управленческими вызовами при разработке софта в своих организациях. 9) Описание группы поддержки - обычно именно им посвящены благодарности в начале или конце книги. Мне понравилась фраза вида "спасибо моей семье за то, что эта книга вышла на пару лет позже, чем могла бы":) 10) Список людей, что нас вдохновляют. Мне нравятся ребята вида Джеффа Дина, Эндрю Танненбаума, Вила Ларсона 11) Создание обложки книги с отзывами на книгу, которые мы придумываем сами от лица людей, что нас вдохновляют. 12) Создание аннотации к книге, которая в одном абзаце должна заинтересовать потенциального читателя, взявшего книгу в руки. 13) Название книги и свое имя на обложке. 14) Ну и в конце надо представить, что книга уже вышла, вы получили свою бумажную копию книги и дальше вспомнили, что прошло между стартом работы и выпуском, а также что вам помогло дойти до конца. 15) Ну и в конце надо написать заголовок к эссе, которому у нас получилось в результате этого урока. P.S. Мне этот урок очень понравился - он позволил немного по другому взглянуть на написание книги:) #Writing #SelfDevelopment #Management

How To Be A Great Programmer • Dave Farley • GOTO 2023 Это короткое видео Дэйва Фарли посвящено тому, как быть крутым разработчиком. Интересно, что сам Дейв - тертый калач, который в давние времена написал книгу Continuous Delivery (я про нее рассказывал), а недавно - "Modern Software Engineering: Doing What Works to Build Better Software Faster", которая стоит у меня на полке и ждет своего часа. В этом видео Дейв выделил шесть вещей, которые он считает важными для крутых инженеров - Code as communication - тут Дейв говорит о том, что код - это средство для коммуникации людей между собой, а не просто для общения с компьютером. Удобочитаемость кода важная для экономии времени и денег, если мы не пишем одноразовый скрипт. Так совокупная стоимость владения на протяжении работы с кодом меньше, так как большую часть времени мы читаем и дорабатываем код, а не раз и навсегда высекаем его в камне:) Интересно, что у Google есть отдельный процесс насчет поддержания readability в их огромной кодовой базе, про который я рассказывал в прошлом посте "Measuring Engineering Productivity". У ребят из Google как раз был вопрос насколько этот процесс окупается и стоит ли его отменить в силу появления линтеров и статических анализаторов. В итоге, ребята поняли, что он приносит пользу и решили его оставить - Be coutious of framework - здесь Дейв говорит о пользе фреймворков, которая сопряжена с риском. Фишка в том, что фреймворки определяют структуру вашего кода (через концепцию inversion of control) и это влияет на развитие и поддержание проекта. Дейв предлагает прибегать к изоляции стороннего кода за собственной абстракцией. В терминальной стадии риск подсаживания на фреймворки выглядит как разработчик на Spring Boot или Angular/React, которые под свой фреймворк ... и все:) - Code is design - код и проектирование неразделимы. Автор говорит о том, что зачастую люди под проектированием понимают выбор конкретных технологий навроде K8s, что заменяет решение изначальной проблемы. Другая проблема - это выделение отдельной должности архитектора, к которому отъезжают вопросы проектирования и архитектуры. Кстати, на эту тему был выпуск подкаста "Code of Leadership", где мы с Лешей Тарасовым, техдиром социальных платформ в Тинькофф, обсуждали staff+ трек для индивидуальных контрибьюторов и почему архитектор - это роль высокоуровневых инженеров, а не выделенная должность. В итоге, Дейв заканчивает тезисами хороший код - это выбор организационных принципов для решения проблем. Дизайн - это выбор, который мы делаем каждый день, когда пишем код. - Quality over features - великие программисты гордятся своей работой и стремятся сохранить и поддерживать свою способность вносить изменения в течение длительного времени. Это имеет смысл, если вы делаете не одноразовые скрипты. Так совокупная стоимость владения на протяжении работы с кодом меньше, так как большую часть времени мы читаем и дорабатываем код. Качество кода проще поддерживать, если у вас есть настроенный CI/CD и вы работаете в продуктовом, а не проектном подходе - Software development is a social activity - автор говорит о том, что разработка софта - это социальная активность и для того, чтобы быть крутым инженером надо уметь хорошо общаться, уметь активно слушать окружающих, а также внятно доносить свои мысли. - Avoid code ownership - великие разработчики открыты для критики и готовы учиться новому. В профессиональной среде важно разделять ответственность за код и избегать единоличной ответственности. P.S. Раньше я уже рассказывал про другое видео Дейва "The Most Powerful Software Development Process Is The Easiest", которое может быть интересно посмотреть в продолжение этого видео. #Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE #SelfDevelopment

Measuring Engineering Productivity (from Software Engineering at Google) - Part II Продолжая первый пост, расскажу про исследование readability процесса, в котором авторы сформулировали цель относительно developer productivity, разложив ее на пять отдельных компонент со звучным акронимом QUANTS: - Quality of the code - качество создаваемого кода, тест-кейсов, архитектуры, ... - Attention from engineers - как часто инженеры достигают состояния потока, насколько у них много переключений контекста. - Intellectual complexity - насколько большая когнитивная нагрузка возникает при выполнении задачи. Какой баланс между присущей и привнесенной сложностью (условно есть внутренняя сложность проблемы, а есть дополнительная, которая внесена нашими процессами, инструментами, ...) - Tempo and velocity - скорость решения задач, пропускная способность (количество задач в единицу времени), темп поставки изменений - Satisfaction - насколько инженеры довольны своими инструментами, насколько они удовлетворены своей работой и создаваемыми продуктами, насколько они ощущают выгорание Дальше авторы исследования про readability разложили свои цели по этим 5 критериям: - Quality of the code - инженеры пишут более качественный код в результате процесса readability review - Attention from engineers - по этому пункту авторы не выставляли никакой цели - Intellectual complexity - инженеры изучают кодовую базу Google и лучшие практики в результате процесса, а также получают менторинг от опытных сотрудников - Tempo and velocity - инженеры выполняют рабочие задачи быстрее и более эффективно в результате процесса - Satisfaction - инженеры видят пользу readability процесса и испытывают позитивные ощущения от участия в нем Дальше авторы зафиксировали ожидаемые сигналы и метрики и провели исследование. Интересно, что почти все темы были покрыты метриками из опросов (квартальный опрос и отдельный readability опрос) и только часть про tempo/velocity отчасти опираются на метрики из логов: по медианному времени ревью Changelist (аля MR). В общем, результаты исследования показали, что readability процесс приносит пользу даже в самых инструментализированных языках (C++, Java). Поэтому сам процесс остался на месте (по крайнейм мере на момент написания книги в 2020 году). #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

Measuring Engineering Productivity (from Software Engineering at Google) - Part I Пока у меня отпуск я знакомлюсь с крутой книгой от инженеров из Google, где они преоткрывают завесу тайны над своими инженерной культурой, процессами и практиками. Книга мне нравится и я решил поделиться актуальной главой про то, как в Google подходят к измерению инженерной продуктивности и вот основные мысли из этой главы - Google - это data-driven компания, где решения принято строить на основе объективной информации, а не субъективных мнений - При росте бизнеса растет и инженрная команда, но если организация растет условно линейно, то затраты на коммуникацию растут квадратично (можно вспомнить количество ребер в полном графе - n*(n-1)/2). Поэтому мы не можем просто масштабировать организацию линейно - надо уметь делать каждого инженера более продуктивным - Для повышения продуктивности надо уметь находить неэффективности в инженерных процессах и фиксить найденные проблемы. Для этого в Google собрали отдельную команду исследователей, изучающих инженерную продуктивность. В этой команде есть как инженеры, так и social scientists из множества областей, включая когнитивную психологию и поведенческую экономику. Эти ученые изучают человеческую сторону инженерных процессов - Эта команда очень щепитильна к темам своих исследований - померить можно конечно многое, но сначала надо ответить на вопрос, а стоит ли вообще это измерять. И у них есть особый процесс для триажа (triage), где они задают вопросы командам, которые пришли к ним с запросом на исследование -- What result are you expecting, and why? - этот вопрос позволяет понять изначальные предубеждения и учесть их при оценке эксперимента -- If the data supports your expected result, what action will be taken? - есть смысл измерять что-то, если этот приведет к каким-то решениям и действиям -- If we get a negative result, will appropriate action be taken? - если негативный результат исследования не повлияет на решение, то проводить исследования тоже не стоит -- Who is going to decide to take action on the result, and when would they do it? - надо понимать кто ЛПР (лицо принимающее решение) и имеет ли он отношение к заказу исследования. Надо понимать какие подходы к исследованию этот ЛПР считает валидными - ему нужны количественные данные, качественные (в виде интервью), он верит результатам опросов или доверяет только данным из логов систем (activity based stats). В общем, это совет из серии того, что надо знать свою аудиторию и ее потребности:) Если вовремя задать эти вопросы, то многие измерения просто не стоят того, например, авторы приводят такие примеры

- You can't afford to change the process/tools right now - Any results will soon be invalidated by other factors - The results will be used only as vanity metrics to support something you were going to do anyway - The only metrics available are not precise enough to measure the problem and can be confirmed by other factors

- Дальше авторы рассказывают про свой подход GSM (goals - signals - metrics) для -- Goal - это ожидаемый конечный результат, он формулируется в высокоуровневых терминах и не содержит отсылок к тому, как его измерять -- Signal - это то, как вы поймете, что результат достигнут. Его бы вы хотели измерить, но не всегда это просто -- Metric - это прокси для сигнала. Это то, что мы реально можем померить, может быть это не идеальное измерение сигнала, но достаточно близкое В качестве примера исследования авторы говорят про процесс readability review, который принят в Google. По-факту, это подход к тому, чтобы кодовая база имела единообразный стиль и вид. Этот процесс пришел из ранних лет Google и напоминает обычное code review, но фокус в котором не на семантику изменений, а на идиоматичность использования кода. Исследование решили провести потому, что было мнение, что современные линтеры и статические анализаторы могут выдавать хорошие результаты и без привлечения людей. Продолжение обзора этой главы будет в следующем посте. #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

GitHub Copilot: Coding Will Never Be The Same Again • Ryan J. Salva • YOW! 2023 Интересное выступление от Ryan J. Salva, VP of Product в Github, который рассказывает о том, как работает Copilot, и сопровождает все это несколькими демо. Ну и основным лейтмотивом выступления является обсуждение того, как Copilot помогает инженерам повышать свою продуктивность и изменять свой способ работы с кодом. Основные мысли в выступлении следующие - Copilot умеет делать подсказки кода, который возможно вам будет полезен, исходя из контекста - Контест обычно задается тем промптом, который вы пишите вначале в виде комментария на естественном языке - Кроме того, у пользователя есть возможность общаться с помощником в чате, задавая вопросы по кодовой базе или прося сгенерировать какой-то кусок кода - Архитектура системы на пальцах состоит из трех частей: code editor <-> proxy <-> model - Контекст обирается со всего редактора (автор показывает на примере VS Code). В дело идут другие открытые вкладки, что тоже используются для контекста - Для разных целей используются разные модели - условно для подсказок нужно low latency, поэтому используется модель попроще и побыстрее (GPT-3.5), а для чата приемлемо некоторое время ожидания, поэтому можно использовать модель помощнее и помедленнее (GPT-4) - В принципе, в чате можно попросить Copilot сгенерировать ответ, используя данные всего вашего проекта (workspace) - Дальше есть возможность использовать RAG (retrieval augmented generation), когда к вопросам пользователя «подмешивается» дополнительная информацию из каких‑то внешних источников для расширения возможностей copilot -- Пример с документацией по внутренней дизайн системе для создания интерфейсов -- Пример с информацией из observability платформ (splunk, datadog, ...) для связки условного сбоя, изменений за последнее время и имен авторов (чтобы подключить их к разбору инцидента) - Дальше автор рассказывает про fine tunning модели, например для внесения смещения в сторону определенных стилей, версий API или SDK, языков программирования. Тут автор говорит, что модель дообучается на той обратной связи, что ей доступна (принятые и отклоненные suggestions, код, что прошел код ревью на merge request и код, что в результате код ревью был исключен и так далее) - Ребята в Github проводили много экспериментов по исследованию влияния использования LLMs и результаты показывали значимые эффекты. Особенно мне понравилось исследование, где качество MRs оценивали инженеры вслепую, когда не знали использовали ли авторы MRs при работе LLMs или нет. И эта слепая оценка показала значимо более высокие оценки качества MRs у тех, кто пользовался помощью LLMs - Интересно, что LLMs больше бустят начинающих разработчиков, а у продолжающих эффект меньше - Дальше автор рассказывает про экономический эффект, что они посчитали в результате исследования с командой McKinsey и там получилось число 1.5 триллиона долларов за следующие три года (вообще консультанты любят рисовать большие цифры) - Ну и завершается все тем, что ИИ не отнимет работу и инженеров, а скорее избавит их от рутины и в будущем для инженеров будет важна креативность и системное мышление, что позволит решать более сложные задачи, а вот зубрить синтаксиса языка придется меньше:) #AI #Software #Leadership #Future #ML #DataScience #Productivity #Engineering #Processes

Как я получаю информацию, чтобы быть в теме IT и не только Недавно ко мне прилетел примерно такой вопрос от моего коллеги, Вовы Коноплева, CTO нашего банка для юрлиц, который ведет свой канал @konoplevthoughts Мне вопрос понравился и я решил ответ на него превратить в отдельный пост, где я расскажу про свои источники информации 1) Книги Я отслеживаю важные книги по интересным мне темам. Для этого я ориентируюсь на новинки на платформе - Сайт онлайн-платформы O’Reilly, где есть книги разных издательств, а также видео и курсы - Сайт издательства Питер, где интересно отслеживать новинки, а потом читать их неисковерканные в английском варианте - Сайт издательства ДМК Пресс, где интересно отслеживать новинки и их даже можно покупать и читать (например, тут я писал про последнюю купленную партию книг из ДМК насчет статистики) - Сайт издательства МИФ, где я покупаю много книг, но редко какие из них посвящены IT, так как это не профильная тема для МИФ Отдельно отмечу, что меня интересуют книги как по IT, так и по современной науке, но обычно в формате научно-попуплярной литературы. Это позволяет мне поддерживать знания в актуальном состоянии. 2) Whitepapers Я люблю читать важные whitepapers на темы, что меня задевают: архитектура , менеджмент, распределенные системы. Для этого у меня есть тоже набор источников - Сайт ACM (Association for Computing Machinery) - сайт ассоциация вычислительной техники, старейшей и наиболее крупной международной организации в компьютерной области. На этом сайте есть куча whitepapers. Отдельно отмечу, что вступление в ряды членов ACM позволяет здорово сэкономить на доступах: само членство стоит 99$, за 75$ можно получить доступ к уже упоминавшейся выше платформе O'Reilly, Skillsoft Percipio и Pluralsight, а еще за 99$ к ACM Digital Library. В итоге, 273$ в год дают бандл, что стоит дешевле в 2 раза, чем доступ к O'Reilly отдельно - Сайт Google Research, где есть куча интересных whitepapers, например, я уже публиковал такую подборку - Сайт Amazon Science, где тоже много отличных материалов, например, "Dynamo: Amazon’s highly available key-value store" 2007 года, "Amazon Redshift and the case for simpler data warehouses" 2015 года, "Amazon Aurora: Design considerations for high throughput cloud-native relational databases" 2017 года, "Amazon DynamoDB: A scalable, predictably performant, and fully managed NoSQL database service" 2022 года - Сайт Meta Research (запрещенной в России Meta), где тоже куча интересного материала 3) Telegram каналы Приведу тут не весь список каналов, а тот, из которого я частенько узнаю что-то новое - Сиолошная (@seeallochnaya) - здесь я читаю понятные тексты про LLMs и все, что с ними связано. По этим текстам мне кажется, что я неплохо все понимаю - gonzo-обзоры ML статей (@gonzo_ML) - здесь я узнаю про whitepapers и понимаю, что пока не слишком хорошо во всем этом разбираюсь:) - Инжиниринг Данных (@rockyourdata) - здесь я узнаю про современный ландшафт технологий работы с данными, но с фокусом на западных SaaS решениях и примесью on-prem решений - Архитектура ИТ-решений (@it_arch) - отсюда я узнаю про интересные статьи на тему архитектуры и проектирования - DDDevotion (@dddevotion) - тут я черпаю новости относительно DDD и той же архитектуры и проектирования 4) Популярные ресурсы на тему IT - Сайт консультантов Thought Works и конкретно их выпуски про техрадары - Сайт InfoQ и их ежемесячные рассылки по архитектуре 5) Каналы в Youtube - Канал конференции goto, где есть записи с конференций крутых спикеров, многие из которых являются популярными авторами - Канал конференции NDC, где тоже есть крутые выступления 6) Обучающие платформы - Leetcode, где можно практиковать написание кода - Edx - ресурс с крутыми университетскими курсами (я его использовал активно раньше) - Coursera - ресурс с крутыми университетскими курсами (я его использовал активно раньше) - Stepik - российский ресурс с хорошими курсами #SelfDevelopment #Education #Software #Architecture #Management #Leadership

ЦЕХ 4 - Урок #4 "Как организовать работу. Эксперт — Ренат Шагабутдинов" Продолжая серию постов про свое обучение книгописательству (смотри предыдущие посты: 1, 2 и 3), я расскажу про четвертый урок. Он был посвящен тому, как выстроить свое расписание так, чтобы систематически работать над книгой. Советы опираются на опыт разнообразных авторов, которые уже успели издать свои книгу, иногда и не одну. Ниже основные моменты, что я вынес с этого урока 0) Есть много авторов книг на тему писательского мастерства и можно почитать их, чтобы вдохновиться идеями 1) Важно помнить, что все мы разные и советы авторов не всегда применимы именно к нам 2) Писать надо о том, что нам интересно и нравится - это чувствуется по книге 3) Надо уметь работать с помехами и сопротивлением. Первое - это другие дела, что отнимают время от писательства, а второе - это когда высвободили время под наипсание, но книга не пишется. 4) Важно в своей работе опираться на принципы,а не инструменты. Например, среди принципов может быть однозначность, работа над книгой в самое продуктивное время (что для каждого из нас свое), отказ от уведомлений. 5) При работе важен темп и ритмичность. Это можно обобщить на расписание внутри дня, недели, месяца. Классно, когда внутри дня у нас есть слоты, когда мы можем поработать над книгой. 6) Системность в работе важна - важно фокусироваться не на большой цели, а на ежедневной системной работе. Причем можно так спроектировать окружение для работы, чтобы не отвлекаться на лишнее и не тратить усилия на самоконтроль. Про это есть в книге "Теория игр", про которую я вспоминал раньше 7) Важно вести здоровый образ жизни - достаточно спать, есть, двигаться. Именно это позволяет достичь оптимальной физической продуктивности, а в здоровом теле - здоровый дух:) 😍 Если вы уперлись в писательский блок, то можно продолжать писать и не оценивать себя в процессе работы. Можно переключиться на другое дело и немного погулять, отпустив свои мысли в свободное плавание, ну и есть еще куча советов 9) При старте написания можно использовать разгонные блоки для того, чтобы расписаться. Плюс, некоторым помогает проговаривание текста вслух. 10) Можно использовать отпуск для работы над книгой, но помогает он редко, так как отпускные дела забирают все время:) 11) Структура книги бывает полезна в самом начале книги, но по мере написания она обычно претерпевает много изменений:) 12) Структуры книги бывают разные: от общего к частному, от частного к общему, хронологические и так далее 13) Композиция книги тоже может быть разной: линейной, параллельной, полифонической, кольцевой 14) Большинство авторов используют Word или Google Docs, но есть и более продвинутые приложения. Бывает полезно использовать аля Miro для mind maps 15) Объем книги в России считают в авторских листах, объем книги обычно бывает в пределах от 4 до 40 авторских листов. Объем книги должен быть обусловлен ее содержанием, плюс полезно смотреть на объем по частям и главам и контролировать, что они примерно равны 16) Сроки написания книги всегда больше, чем вы планировали (здесь работает закон Хофштадтера) 17) Важно делать бекапы в разных местах, чтобы не потерять внезапно черновик рукописи 18) Можно использовать LLMs для генерации чернового материала 19) Полезно иметь систему для работы с заметками, например, как описана в книге "How to take smart notes, Zettelkasten", про которую я уже вспоминал 20) Бывает полезно использовать бета-ридеров, которым доступен для прочтения черновик книги и которые дают полезную обратную связь #Writing #SelfDevelopment #Management

Колобанга. Только для пользователей Интернета Отпуск - это время, когда много времени проводишь вместе с детьми и видишь во что они играют и какие мультики смотрят. И тут мне внезапно понравился мультик про смайликов "Колобанга", на который подсел мой трехлетний сын Кирилл. Этому мультику уже почти десять лет, но в свое время он как-то прошел мимо меня. Главными героями мультика являются смайлы в Интернете, которые путешествуют по разным знаковым местам: от социальной сети до библиотеки Вики-Вики и Фидонета. Оригинальность мульика можно оценить по списку главных персонажей - Колобок — отважный и амбициозный персонаж с задатками супергероя. - Умник — эрудит и просто грамотный колобок, не держащий в руках ничего тяжелее книги. - Чёлка — рассудительная и справедливая подруга Колобка и Умника. - Глюк — герой, вносящий нотку беспорядка в мир Интернета, о котором он знает всё. - Полифагус, он же Правитель Фидо — главный злодей интернета, который когда-то был борцом с вирусами, но из-за вируса доктора Хака стал злым - Майдум — приспешник правителя Фидо, опаснейший вирус по совместительству, промышляющий воровством почтовых собачек. - Доктор Хак — ученый, он же предатель, он же Крот, главной разработкой которого стал супервирус, превративший Полифагуса в Правителя Фидо. В общем, классно когда смотреть детский мультик интересно не только детям, но и их родителям. А этот мультик именно такой:) #Software #ForKids #ForParents

Это обложки книги "Доверительное a/b тестирование". Давайте проведем тест и в комментах напишем какой вариант вам нравится больше:))

Доверительное a/b тестирование (Trustworthy Online Controlled Experiments) Уже после начала отпуска я дочитал книгу по a/b экспериментам, которые являются необходимым инструментом для bigtech компаний для того, чтобы оценить эффективность тех или иных идей по оптимизации веб-сайтов, приложений, ml-моделей. Это дейстительно крутая книга, которую написали совместно три автора: - Ron Kohavi - Technical Fellow and corporate VP of Microsoft's Analysis and Experimentation (previously director of data mining and personalization at Amazon) - Diane Tang - Google Fellow, with expertise in large-scale data analysis and infrastructure, online controlled experiments, and ads systems - Ya Xu - head of Data Science and Experimentation at LinkedIn Эта книга на русском вышла в издательстве ДМК Пресс и ее даже можно читать, сверяясь периодически с первоисточником. Книга состоит пяти частей: 1) Введение для всех - объяснение мотивации проведения экспериментов, как выглядит полный цикл проведения экспериментов, как оценить надежность полученных данных и как прокачать культуру экспериментирования и прийти к платформе 2) Избранные темы для всех - пример известных экспериментов по оценке влияния скорости вебсайтов на бизнес показатели (full дизайн эксперимента и разбор его результатов), какие организационные показатели бывают, как выбрать OEC (overall evaluation criteria) для оценки эффектов экспериментов, как проведенные эксперименты формируют институциональную память и как их можно использовать для метаанализа, как проводить этичные эксперименты 3) Дополнительные и альтернативные методы контролируемых экспериментов - что делать, если честный a/b тест не провести (экспертная оценка, исследование UX, фокус-группы, обзоры, ...), как дизайнить наблюдательные исследования для исследования причинно-следственных связей 4) Платформы для экспериментов - очень важный раздел для тех, кто решил делать свою платформу. Здесь идет речь про эксперименты на стороне клиента (например, в мобильном приложении), про инструментарий для экспериментов, как выбрать еденицу рандомизации (страница/экран, сеанс пользователя, пользователь, компания, ...), как найти компромисс между скоростью/качеством/риском при дальнейшем развитии экспериментальной платформы, как анализировать масштабные эксперименты 5) Развернутое описание анализа экспериментов - тут наступает время статистики и авторы рассказывают про t-тест, p-значение и доверительные интервалы, ошибки первого и второго родов. Рекомендую почитать книгу "Understanding Statistics and Experimental Design. How to Not Lie With Statistics", про которую я писал раньше. Тут же идет речь про оценку дисперсии и повышение чувствительности экспериментов, как и зачем проводить a/a тестирование, какие существуют ограничительные показатели при проведении экспериментов, навроде SRM (sample ratio mismatch), как может происходить утечка и интерференция между вариантами (например, при экспериментах в соцсетях или на e-com платформах), как мерить долгосрочные эффекты. В общем, книга топовая и я рекомендую ее к прочтению тем, кто глубоко погружен в тему a/b экспериментов ... или тем, кому просто нравится статистика:) #Math #Statistics #PopularScience #Science #ML #Data #Software #PlatformEngineering

Keynote: Debug your thinking - Laila Bougria - NDC London 2024 Интересный доклад, посвященный улучшению мышления от Laila Bougria, где она рассказывает о том, чему она научилась и как важно критическое мышление и и ментальный отладчик для решения проблем и принятия решений. Вообще, основная метафора доклада - это debugging мышления примерно тем же способом, как мы действуем в случае с софтом, в котором есть непредсказуемые ошибки. Автор дает следующие советы - Важно анализировать проблемы, сделав паузу и подумав о доступных альтернатив. Можно использовать технику 5 почему (5 whys) - Полезно использовать технику рефрейминга, когда мы переосмысливаем проблему и находим альтернативное решение, которое отсутствовало в списке альтернатив - Надо знать о том, что при решении проблем есть склонность к быстрому их решению и использованию старых подходов, которые раньше сработали. Условно натягиваем сову на глобус, старое решение на новую проблему вместо того, чтобы подумать от проблемы. В эту же тему фраза про "Когда в руках молоток, то все проблемы становятся похожи на гвозди" - Важно научиться нестандартно мыслить - можно посмотреть на детишек, которые переодически выдают очень интересные мысли:) - Для простора мышления надо быть уверенным в безопасности, это та же тема про pshychological safety, что ребята в Google нашли самой важной для эффективности команд в своем проекте Аристотель, про который я уже писал. Здесь же есть поинт про инклюзивность, который расширяет пространство рассматриваемых альтернатив - Важно знать про когнитивные искажения (biases), которые влияют на наше мышление и по возможности устранять их влияние - Для повышения эффективности мышления важно быть осознанным и наблюдать за своими мыслями и предубеждениями, что помогает выявлять и исправлять ошибки. - Важно уметь работать с обратной связью и использовать RFC для получения обратной связи от разных людей. Также важно записывать свои мысли и решения для улучшения коммуникации и повышения ясности (аля ADR, architecture decision records) - На рынке труда востребованы креативность, умение решать сложные проблемы и критическое мышление, поэтому стоит прокачивать эти качества в себе P.S. Раньше я уже публиковал подборку книг 1) На тему системного и критического мышления 2) На тему работы мозга Плюс в седьмом выпуске Code of Leadership я разбирал книгу про работу мозга "Your brain at Work" вместе с Эрнесто Инаркиевым, чемпионом Европы по шахматам, гроссмейстером, который входит в ТОП-100 лучших шахматистов мира и в ТОП-30 по быстрым шахматам. #Thinking #CriticalThinking #Reasoning #Philosophy #SelfDevelopment #Brain #Management #Leadership

Code of Leadership #13 - "Accelerate" Тринадцатый выпуск подкаста "Code of Leadership" посвящен обсуждению крутой книги "Accelerate", которую написали три автора Gene Kim, Jez Humble, and Nicole Forsgren. Популярность этой книги обусловлена тем, что в этой книге приводятся крутые выводы о связи процессов и практик внутри организации и ее эффективности, а это именно те вопросы, которые интересуют менеджмент. В отличие от многих других книг здесь утверждения подтверждены систематическими исследованиями. Саму книгу я обсуждаю с Игорем Курочкиным, у которого больше 12 лет опыта в индустрии, из которых 6 лет в консалтинге. Он помогает развивать инженерную культуру, процессы и практики, платформенные и продуктовые команды в больших компаниях. В этом выпуске мы обсуждаем следующие темы - История книги, знакомство с авторами и их исследованиями - Краткий обзор трех частей: модель авторов, методология исследования, как применять модель на практике - Сравнение моделей зрелости (maturity models) и модели практик (capabilities models) - Как раньше пытались мерить эффективность разработки (lines of code, velocity, compleated story points) - DORA метрики - Культура по Шейну и по Веструму - Принципы continuous delivery, их связь с инженерными практиками - Архитектура имасштабирование - Shift left everything и pipeline driven organization - Lean management и продуктовые практики - Как дизайнилось исследование, какая модель получилась, как анализировались полученные результаты - Как дальше развивалась модель Accelerate и что можно почитать из новенького (DORA отчеты с 2019 года по текущий) Дополнительные материалы для изучения включают в себя: - Модель исследования - Все отчеты State of DevOps - Инструмент для быстрой оценки своей команды - Whitepapers: -- The role of continuous delivery in IT and organizational performance -- DevOps Metrics - Выступление Игоря Курочкина про NextOps на DevOpsConf 2024, где он рассказывал чем сейчас занимаются авторы книги Accelerate - Обзор книги в 3х частях от Александра Поломодова: -- Общая информация по книге, формат исследования и DORA метрики -- Технические практики, архитектуру и интеграцию вопросов безопасности в процессы разработки -- Менеджерские и лидерские практики #Devops #Management #Leadership #Processes #SRE #Software #Devops #Architecture #SoftwareArchitecture #SoftwareDevelopment

Intentional Code - Minimalism in a World of Dogmatic Design - David Whitney - NDC Porto 2023 Занимательное выступление David Whitney, head of architecture в компании New Day, на тему дизайна и проектирования софта, в котором прикольные иллюстрации и интересные мысли, которые можно обобщить до следующего - Шаблоны проектирования (design patterns), бум которых начался с книги "Design Patterns" от банды четырех (Gang of Four). Конкретно в этой книге шаблоны были разложены на категории creational, structural, behavioral и каждый шаблон описывал типовое решение стандартной проблемы, с которыми часто сталкивались авторы книги. Но это не было призывом к стандартизации всего и вся. Скорее это был общий язык и набор идиом программирования, которые могут быть полезны - На книгу тему паттернов проектирования в IT большое влияние оказал Кристофер Александер, настоящий архитектор от строительства, а не из IT, который написал знаковые книги "Notes on the Synthesis of Form" и "A Pattern Language: Towns, Buildings, Construction" (стоит у меня на полке и ждет своего часа) - Виды архитектур: hexagonal architecture (port& adapters), clean architecture, 12 factor app. Автор обсуждает эти подходы, а потом говорит, что в разработке софта есть есть не только шаблоны и виды архитектур - Давид вспоминает книгу Кнута "Literate programming" ("Грамотное программирование"), где программа фактически пишется на естественном языке, а инструкции входит в неё в форме макроподстановок и кода на языках программирования. Эту концепцию предложил Кнут в 1981 году и использовал при создании TeX. В этой концепции подчеркивается важность формы, потока и ритма кода, а также его смысла и цели существования. Причем код должен быть написан с уважением к читателю:) - Сложность софта - многие программы чрезмерно сложны, потому что они не формируют правильные абстракции для читателей и им легко потеряться в инфраструктурных моментах и схеме организации кода. Автор выдвигает такой тезис

The complexity of your app should be at most as comoplex as the problem space it inhabits, and no greater

- Эти подходы к управлению сложностью стоит использовать при дизайне своего приложения и проектировании качественных API - Автор вспоминает "Чистый код" ("Clean code") дядюшки Боба и говорит, что много лет назад - это была полезная и прорывная книга, но с тех пор она устарела, как устарел и догматичный подход Роберта Мартина, который фиксирует количество строк в функции. Честно говоря, я согласен с такой оценкой книг Роберта Мартина:) - Дальше автор вспоминает крутую книгу "A philosophy of software design" Джона Остерхута и дальше идет по концепциям из нее. Это крутая книга, которую мы разбирали в рамках клуба Code of Architecture и которую я очень рекомендую к прочтению. И вот какие концепции из этой книги автор освещает -- Сложность софта может иметь накопительный эффект - маленькие уступки на которые мы идем при написании кода приводят к большому техдолгу -- Shallow и deep modules - если мы используем абстракции, то они должны быть глубокими и скрывать сложность, а не поверхностными, которые с этим никак не помогают -- Разработка софта - это компромиссы, что зависят от контекста -- Проектировать софт надо так, чтобы он был готов к изменениям в будущем В принципе, в выступлении есть еще много умных мыслей, так что я рекомендую посмотреть его в оригинале:) #Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Patterns