Подъехала запись вебинара Нила ФОрда и Марка Ричердсона Software architecture the hard parts. Они рассказывают о Granularity and coupling in microservices https://www.youtube.com/watch?v=F9r04PuaOcs

​Отрицание как защита в организациях
#защиты #психодинамика #отрицание

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

Отрицание, хочу напомнить, это одна из примитивных форм психологической защиты. Примитивная - значит детская, т.е. лидеры организаций очень сильно регрессировали.

Также можно вспомнить, что Шок-Отрицание это первая стадия горевания по Кублер-Росс. А значит лидеры организаций не смогли после регресса восстановится за эти несколько недель. И организации, которые они возглавляют, застыли в этой защите вместе с ними.

Есть примеры, когда руководители даже запрещают вообще на работе "подобные разговоры". И мы можем предположить, что идет запрет и на переживания: ведь "мы профессионалы и должны держать эмоции при себе".

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

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

Организация перестает быть контейнером для сотрудников, и остается только источником тревог. Сотрудники, предоставленные самим себе, врубают персональные психологические защиты, которые приводят к дополнительным конфликтам внутренним и организационным.

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

Что это значит для лидеров и что с этим нужно делать?

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

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

Что необходимо сделать в организациях:
- Признать ситуацию на уровне организации и дать посыл сотрудникам, что вы будете работать вместе.
- Не дистанцироваться от людей.
- Сформировать и поддерживать контейнирующие структуры. Необходимы и рефлексивно-эмпатические и структурно функциональные (MHFA, ситуационные центры, периодические апдейты о ситуации, психологическая помощь специалистов, работы в группах, супервизии, группы по интересам, работа сообществ и пр. пр. пр.).

Александр Поломодов @apolomodov продолжает писать о прочитанных книгах (считаю, что мышление письмом очень помогает усваивать знания). В этот раз это обзор книги @vladik_kh

Если не читали – можно пробежать по верхам, если уже прочитали, то можно сверить часы.

https://apolomodov.medium.com/обзор-книги-what-is-domain-driven-design-7128373196e8

Читаю сейчас не спеша новую книгу Вернона. Оказывается по следам публикации книги вышел подкаст на se-radio https://www.se-radio.net/2022/01/episode-495-vaughn-vernon-on-strategic-monoliths-and-microservices/

В целом ничего неожиданного, но Вернона всегда интересно послушать)

Вышел новый техрадар thoughtworks.com/radar

Что приглянулось, чтоб подробнее поразбираться:
- транзитивная архитектура https://martinfowler.com/articles/patterns-legacy-displacement/transitional-architecture.html

- КУПИДон https://dannorth.net/2022/02/10/cupid-for-joyful-coding/

- Четыре ключевые метрики https://www.thoughtworks.com/radar/techniques?blipid=1298

- Сальса https://slsa.dev/

- https://www.testcontainers.org/

и многое другое.

Как вам эта версия радара? Что вы отметили для себя на будущее?

Транзитивная архитектура – только один из паттернов поставки для замещения легаси.

Помимо паттернов поставки (delivery)
Авторы выделяют
– паттерны понимания проблематики
– паттерны разбиения проблематики
– и даже паттерны непрерывных оргизменений.

Рекомендую к ознакомлению https://martinfowler.com/articles/patterns-legacy-displacement/

Коллеги из IT's Tinkoff начинают серию стримов по книге Влада Learning Domain-Driven Design

Первый стрим уже прошел https://www.youtube.com/watch?v=W8aZiL298E8&list=PLLrf_044z4JpIlGkIDn6sdBstsTkKMXU6&index=2

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

Не очень слежу, но тем не менее, в марте в гошечке 1.18 завезли генерики)

Я помню как они появились в c# 2.0 (а до этого я только у читал про них у Майерса). И это был кайф!

https://go.dev/doc/tutorial/generics

вот и следующая часть подоспела

Faster is slower

Иван Закревский напомнил мне про отличную статью, в которой объясняется важность системного подхода к своим решениям и почему быстрота в моменте оборачивается замедлением на дистанции. https://less.works/less/principles/systems-thinking

P.S. Есть русский перевод https://less.works/ru/less/principles/systems-thinking

https://www.meetup.com/Technical-Excellence/events/285738419/

Коллеги проводят митап про эволюционное проектирование.
Термин пришел из архитектуры и ландшафтного дизайна, позже появился и в проектировании ПО. В частности упоминается в LeSS (https://less.works/less/technical-excellence/architecture-design) и SAFe (https://www.scaledagileframework.com/agile-architecture/). Ну и нельзя не вспомнить книгу Building Evolutionary Architectures (https://www.thoughtworks.com/insights/books/building-evolutionary-architectures).

Работая с тактическими паттернами DDD, в очередной раз убеждаешься какой же этот ваш DDD "душный" в хорошем смысле слова. Вот буквально на днях пилили небольшой объект-значение, отражающий количество (при этом количество может быть дробным значением). И в процессе запилки возникли вопросы вида
- Какие могут быть максимальные и минимальные значения?
- Какая должна точность дробной части?
- Как округляется значение при выполнении арифметических операций?
- Какие вообще арифметические операции допустимы, с какими аргументами и в каких диапазонах?
- Как вести себя при переполнении?

И это довольно простой класс, ничего особенного. В обычном случае пишут что-то вроде fun calculate(float: count) и забивают, мы же уделяем столько внимания казалось бы такой незначительной чиселке. И в итоге может показаться, что все это не нужно. Да и вообще тратим больше времени - нужно подумать, написать тесты, etc. Но это не совсем так, ведь мы получаем:
- Снижение когнитивной нагрузки. Мы работаем над небольшим независимым кусочком кода и за счет этого яснее видим граничные случаи.
- Сами тесты получаются проще и шустрее, их дешевле поддерживать. Местами очень хорошо заходит property-тестирование
- Самый главный пункт - мы защищаемся от нелепых багов вида "нам передали отрицательное число в качестве количества, а мы его пропустили, потому что забыли провалидировать. Теперь надо полбазы перетряхнуть на проде, чтобы устранить последствия".
- За счет инкапсуляции упрощается сам код, ведь нам не нужно таскать и копипастить разного рода проверки.

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

как много леденцов в вашем коде? 🍭

Moscow Python Podcast продолжают копать тему Domain-Driven Design. В этот раз они позвали Колю Фоминых (@tigrrrus) из Медси Digital.

Приятного просмотра https://www.youtube.com/watch?v=nxiMm3tyDL4

Часто в индустрии слышу противопоставление заказная разработка vs in-house или outsource vs продуктовая разработка.
Причем иной раз работаешь в продукте, а отношение как к заказной. Или наоборот, ребята на аутсорсе, но настолько вовлечены – очень приятно работать.
Эта статья чуть лучше разделила для меня эти два мира и подсветила разницу.

Что я вынес из статьи:
1. Если в продуктовой компании вам кажется, что вы продаете (покупаете) время – что-то идет не так.
2. Если вам вашим разработчикам важно успеть сделать все запланированные таски (output) – возможно им будет менее интересен реальный результат (outcome).
3. Мы очень часто сталкиваемся (начиная со школьных оценок) с тем, что у нас фейковые, не приносящие ценности цели. Фича, написанная в стол. Отчет, который никто не читает.

И напоследок, пара цитат на эту тему

“The righter we do the wrong thing, the wronger we become” (Russell Ackoff)
"Successful outcomes over efficient delivery" (из статьи)

Понимайте своего потребителя и делайте правильные вещи

Пять монументальных статей о размере микросервиса:
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов

#DDD #MSA

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

По итогам нашего часового разговора я накидал такой список того, что я рекомендую почитать и посмотреть
1) Для будущих CTO - Technology Strategy Patterns - https://bit.ly/TechStrgPatterns - тут классно рассказано про подходы к мышлению бизнесменов и паттерны, которые они используют, например, Value Chain, SWOT Analysis, Growth Matrix, Futures Funnel, ... Эти подходы неплохо знать технарям, чтобы коммуницировать с бизнесом насчет техннических решений в терминах и подходах, которые будут им понятны
2) Про деливери - Визуализируте работу - https://apolomodov.medium.com/review-making-work-visible-8ff41a044f9b - базовая книжка про Kanban подход и чем он хорош при оптимизации Delivery
3) Про создание крутых продуктов - Дизайн привычных вещей - https://apolomodov.medium.com/review-design-of-everyday-things-part-1-ab86566431c6 - это книга про human centric design
4) Крутая книга про мышление - The Model Thinkign - https://apolomodov.medium.com/the-model-thinker-review-8ff710d38f96 - крутая книга, что улучшает понимание подходов к моделированию окружающего мира
5) Книга про топологии команд - Team Topologies - https://apolomodov.medium.com/review-team-topologies-part-1-205533a027c0 - здесь про струткуру команд и их эффективное взаимодействие
6) Мой доклад про изменение роли руководителя по мере роста компании и команды - Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - https://apolomodov.medium.com/highload-what-is-cto-406afab7fd5
7) Про изменение процессов (лучше прочитать и посмотреть видео, так как в тексте нет части про delivery managers) - Как мы меняли разработку лучшего* мобильного банка под требования бизнеса - https://apolomodov.medium.com/refactoring-of-mobile-bank-d40858d96f73
8) Моя статья про качество и скорость разработки - Качество vs скорость разработки — как найти баланс? - https://bit.ly/speedVsQuality
9) Книга про лидерство - The Art of Leadership - https://bit.ly/artOfLeadership

#SelfDevelopment #Software #Architecture #Management

В продолжение темы продуктовой разработки. На моем опыте хорошие инженерные практики (в том числе Domain-driven design) намного лучше приживаются если продакт взаимодействует с командой не с позиции "заказчик-исполнители", а активно вовлекает в свою работу и интересуется техническими аспектами реализации.