ЦЕХ 4 - Урок #23 "Продвижение автора. Личный кейс. Эксперт — Лариса Парфентьева" (Рубрика #Writing)

В очередном уроке разбирался пример личного продвижения автора. О своем пути рассказывала Лариса Парфентьева. Основные моменты, что я вынес из урока такие
1) У авторов есть внутренние стандарты при написании книг, иногда они мешают довести ее до конца, а значит надо уметь вовремя останавливаться
2) Сначала надо написать книгу, а потом ее продвигать:) Иначе может случиться фальстарта
3) Личный бренд автора включает книгу-бестселлер, личную историю, социальное подтверждение и профессиональные награды.
4) Круто, если биография автора интересна и легко запоминается читателями
5) Важно презентовать свою книгу друзьям, знакомым, чтобы запустить сарафанное радио
6) Завершение книги увеличивает самоуважение и уверенность в других сферах жизни
7) Авторам стоит участвовать в профильных концеренциях и работать с профильными СМИ (писать статьи по своей профильной теме)
😍 Профессиональные награды могут помочь в продвижении книги, но можно обойтись и без них
9) Маркетинговая деятельность требует энергии, за которую она конкурирует с написанием книги
10) Если вы интроверт и не хотите внимания, просто пишите блестящие книги. Издательства сами займутся продвижением.
11) Личная история может помочь в продвижении, особенно если она связана с вашей экспертной книгой.
12) Можно нанять специалиста в SMM (social media marketing) для помощи в продвижении книги, а можно самому вести соцсети
13) Но важнее всего писать хорошие книги, так как без этого маркетинговые активности пропадут втуне

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)
21. Ведение блога и его продвижение в Телеграме
22. Взаимодействие с обозревателями, критиками и СМИ

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Research Insights Made Simple #5 "DORA Metrics, SPACE, DevEx, Human Approach to Dev Productivity" (Рубрика #Management)

Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы developer productivity, где мы говорим про DORA метрики, фреймворк SPACE, подход DevEx, а также про human approach от Google к теме developer productivity. Для обсуждения этих тем ко мне пришел гость, Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Артем отвечает за развитие платформы для разработчиков, а раньше в Сбере занимался развитие платформы Сбербанк онлайн и рекомендательной платформы. Артем ведет интересный телеграм канал "Плохой Project" (https://t.me/badTechProject). Кстати, выпуск доступен на двух площадках (Yandex Music и Youtube)

1) Мое выступление "Как и зачем измерять инженерную продуктивность в крупной компании" на MTS конференции
2) Обзор книги канонической книги "Accelerate" в трех частях:
-- Общая информация по книге, формат исследования и DORA метрики
-- Технические практики, архитектуру и интеграцию вопросов безопасности в процессы разработки
-- Менеджерские и лидерские практики
3) Выпуск подкаста "Code of Leadership" про "Accelerate" с Игорем Курочкиным
4) Разбор темы developer productivity в фреймворках SPACE, DevEx
5) Разбор начальной статьи ребят из Google "A Human-Centered Approach to Developer Productivity" и рассказ про целую колонку в IEEE журнале от этих авторов
6) Разбор статьи "Measuring Developer Goals" от ребят из Google (продолжение серии про Human-Centered Approach)
7) Разбор статьи "Developer productivity for Humans, Part 7: Software Quality" от ребят из Google (продолжение серии про Human-Centered Approach)
😍 Разбор выступления моего коллеги Вовы Калугина "Почему DevEx важен при разработке IDP и как его померить", где он рассказывает про нашу платформу Spirit и как мы подходим к вопросам developer experience и developer productivity
9) "Грокаем Continuous Delivery" - отличная книга, которая расскажет о CI CD и проведет вас по всему пути эволюции
10) "Гормоны счастья. Как приучить мозг вырабатывать серотонин, дофамин, эндорфин и окситоцин" - прекрасная книга, раскрывающая многие наши поступки. Мы слегка затронули тему длительного цикла обратной связи для менеджера и эта книга попадает туда, чтобы раскрыть тему. Но желание покрасить все тесты в зеленый простым их перезапуском - это, внезапно, про то, как работает наш мозг и желание получения быстрого дофамина. И когда занимаешься Developer Experience такое нужно учитывать

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

System Design for Interviews and Beyond - Курс на Leetcode - Part I (Рубрика #Architecture)

Я наконец-то закончил этот курс с Leetcode, в котором доступно и понятно рассказывали о том, что такое system design interview и что он призван проверять у кандидатов. В этом курсе много теории, но она подана в практико-ориентированном виде - автор не рассказывает про условные сети с начала времен и по сегодняшний день, а раскрывает основные концепции тогда, когда речь заходит про общение компонентов системы между собой. Похожее происходит и с хранением данных - легко уйти глубоко в теорию, но сложно удержаться и рассказать про b-tree и lsm-tree по ходу дела, рассматривая реальные вызовы проектирования системы. Но автор отлично справляется с вызовом и рассказывает одновременно понятно и достаточно точно. Если же возвращаться к содержанию курса, то он состоит из следующих частей

1. How to define system requirements.
Здесь автор говорил про важность функциональных и нефункциональных требования, а дальше проходил по типовым архитектурным характеристикам (-ilities), с которым обычно имеют дело на system design interview: high availability, fault tolerance, scalability, performance, durability, consistency, maintainability, security, cost efficiency. У автора курса отлично получилось объяснить все эти характеристики буквально на пальцах, а также показать их связь между собой, условно, все можно сделать безопасно просто отключив систему и сделав ее недоступной, но кажется, что нам нужен баланс:)

2. How to achieve certain system qualities with the help of hardware.
Здесь автор проводит связку между архитектурными характеристиками системы и тем, как она развернута. Он рассказывает про концепции регионов, зон доступности, дата центров, стоек и финально серверов. Дальше он переходит к рассказу про сервера, виртуальные машины, контейнеры и даже serverless. Я считаю, что эту базу нужно знать, чтобы дизайнить внятные системы.

3. Fundamentals of reliable, scalable, and fast communication.
Для того, чтобы из отдельных частей получилась система, этим частям надо уметь эффективно общаться между собой. В ээтой главе автор про это и рассказывает, а для этого он проговаривает основы
- Синхронные и асинхронные коммуникации
- Паттерны асинхронных коммуникаций (messaging queue, publish/subscribe, competing consumers, request/response, priority queue, claim check)
- Сетевые протоколы (UDP, TCP/IP, HTTP)
- Блокирующие и неблокирующие операции ввода/вывода (i/o)
- Формат кодирования данных (текстовые и бинарные, как шарить схему данных, backward/forward compatibility)

4. How to improve system performance with caching.
В этом разделе автор рассказывает про кеширование, но мне сам раздел показался вырванным из контекста рассказа - условно еще не поговорили про хранение данных, а уже воткнули куда-то кеши:)

5. The importance of queues in distributed systems.
Важный раздел, в котором автор детально разбирает очереди и их использование в распределенных системах (а в system design вы обычно дизайните как раз распределенную систему). В общем, автор говорит про следующие концепции
- Bounded и unbounded queue, а также про circular buffer (например, когда у вас логи по кругу перезаписываются в одно ограниченном по размеру файле)
- Что делать с переполнением очередей и пустыми очередями: load shedding, rate limiting, dead letter queues, backpressure, elastic scaling
- Паттерны producer-consumer, блокирующие очереди, семафоры
- Как работают thread pools, в чем разница между cpu-bound и i/o-bound задачами, как обеспечить graceful shutdown
- Как работает batching и параллельная обработка jobs

Продолжение обзора будет в следующем посте.

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

System Design for Interviews and Beyond - Курс на Leetcode - Part II (Рубрика #Architecture)

Я продолжаю рассказ про крутой курс с Leetcode, в котором доступно и понятно рассказывали о том, что такое system design interview и что он призван проверять у кандидатов. В предыдущем посте мы обсудили работу с требованиями, важные архитектурные характеристики, инфраструктуру, кеширование и очереди. В этой части мы продолжим говорить про хранение данных,  взаимодействие компонентов системы

6. Data store internals.
Здесь автор кратко рассматривает тему хранения данных:
- Log - самый простой способ сохранения данных, но вот читать их сложно в таком виде (full scan на любой запрос)
- Index - индексы в качестве способа подготовки данных для эффективных запросов на чтения
- Time series data - отдельный тип данных, которые полезны, например, при мониторинге
- Simple key/value database - автор объясняет как будет работать база с простейшей моделью данных
- B-Tree index - автор рассказывает про вездесущие b-tree индексы, как они устроены и для каких сценариев подходят оптимально
- Embedded databases - иногда удобно встроить базу прямо в процесс приложения, например, так могут LevelDB, RocksDB, DuckDB
- RocksDB - автор рассказывает как устроена эта база и тут речь про memtable, write-ahead log и SSTables
- Сравнение LSM-tree и B-Tree - автор показывает компромиссы каждого из подходов и сравнивает их границы применимости
- Page cache - заканчивает автор рассказом о том, как все это приземлить на файловую систему внутри OS. Без этих знаний многое из описанного выше не будет хорошо работать

7. How to build efficient communication in distributed systems.
В этой части автор говорит про классику коммуникаций
- Push vs pull модели взаимодействия
- Как выглядит host и service discovery (тут появляется DNS), а также peer discovery
- Как выбирать сетевой протокол под задачу (UDP, TCP, HTTP) и как они ведут себя на практике
- Как обычно передается видео-поток и что такое CDN (content delivery network)
- Что такое short pooling, long pooling, web-socket, server-sent events, зачем они нужны и как они ведут себя на практике
- В конце раздела автор показывает как могут работать пуши на клиентов на большом масштабе (аля Netflix)

8. How to delivery data reliably.
Этот раздел начинается с известного списка fallacies of distributed systems, а дальше автор переходит к практическим средствам обеспечения надежности
- Таймауты и стратегии действий с неуспешными запросами: cancel, retry, failover, fallback
- На конкретных примерах автор разбирает когда и как делать retries
- Дальше наступает время обсудить гарантии доставки сообщений: at most once, at least once, exactly once
- Дальше автор рассматривает как работают log-based message queues (аля Kafka) и что такое consumer offset

9. How to deliver data quickly
Здесь автор рассказывает про подходы к батчингу и компрессии данных, что обеспечивает лучшую пропускную способность.

10. How to deliver data at large scale
В этой части наступает время обсудить вопросы масштабирования обработки данных. Автор рассказывает про
- Партиционирование (шардирование) и рассматривает стратегии: lookup strategy, range strategy, hash strategy
- Как партиционирование работает в реальном мире и какие плюсы/минусы имеет
- Как выглядит роутинг запросов
- Что делать с ребалансировкой шардов
- Что такое consistent hashing

Продолжение обзора будет в следующем посте.

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

System Design for Interviews and Beyond - Курс на Leetcode - Part III (Рубрика #Architecture)

Заканчивая разбор курса о System Design Interview, я хотел рассказать про все оставшиеся части, которые не были в первом посте и втором посте. Первый пост рассматривал работу с требованиями, важные архитектурные характеристики, инфраструктуру, кеширование и очереди. Второй пост был посвящен хранению данных,  взаимодействие компонентов системы, доставке данных быстро и надежно. В этом заключительном посте речь пойдет про защиту серверов от клиентов и наоборот, а также несколько практических задачек

11. How to protect servers from clients
Здесь автор рассказывает о том, как обычно выглядит overload системы, что такое autoscaling, как применять load shedding и как ограничивать количество запросов при помощи rate limiting. В общем, тут идет речь про базовые паттерны для построения надежных систем.

12. How to protect clients from servers
Здесь все начиналось с рассмотрения того, а какие типы клиентов бывают: синхронные и асинхронные. Дальше автор разобрал как работает circuit breaker и как он помогает как клиентам, так и серверам. Дальше речь зашла про fail fast principle, который в моем представлении противоречит концепции resiliency. Ну или это мой bias, когда я видел слишком много примеров небезопасного кода, который оправдывали подходом fail fast:) Следующий принцип bulkhead - я сам его люблю вспоминать в контексте переборок на Титанике, которые были сделаны хреново и на самом деле не защищали от проблем. Ну и финальный паттерн - shuffle sharding, который выглядит действительно интересно в разрезе количества пользователей, которых затрагивает проблемы при выходе нод из строя.

13. Практические задачки
В конце курса автор предлагает потренироваться в проектировании на достаточно стандартных задачках:
- Классический url shortener
- Fraud detection system
- Authn и authz система
- Мониторинговая система

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

System Design Interview by Groks King (Рубрика #Architecture)

На выходных прочитал очередную книгу по system design, которую как-то прикупил с Амазон еще пару лет назад. Меня часто упрекают, что я слишком добро обозреваю книги, но обычно я пытаюсь вытянуть из книг лучшее, но с этой книгой это сложно - в этой книге про system design
- Очень кратко даются теоретические основы и как-то обраывками, из которых не собирается общая картинка
- Нет ни одной схемы - автор предпочитает все описывать словами, поэтому формат взаимодействия компонентов между собой приходится наполовину угадывать
- Разборы практических задач состоят из отдельных частей, которые не всегда собираются в единое целое - например, в задачке про web crawling концовка посвщена защите робота от ловушек для спкам ботов, но рассказ не бьется с предыдущими частями
- В задачках бывают отсылки к векторным часам, CAP и PACELC, моделям консистентности, репликации, но ничего из этого автор не удосуживается не то, чтобы объяснить, а даже расшифровать:)

В общем, книга ужасна для тех, кто хочет подготовиться к интервью. А вот мне было интересно почитать и попробовать сложить из этой россыпи букв что-то осмысленное. Если бы книга не вышла в 2021 году, то я решил бы, что ее написал chatGPT первого поколения:)

P.S.
Если понравился формат и хочется еще отзывов с прожаркой книг, то напишите в комментах и поделитесь своими историями о книгах, что вас разочаровали:)

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

Про system design interview на Highload++ (Рубрика #Architecture)

Сегодня я на конференции Highload++ буду участвовать в дискуссии относительно границ применимости system design interview. Я достаточно много рассказывал о том, что это и чем помогает в найме нам, но есть мнение, что этот тип интервью стал карго-культом, который многие используют просто в силу моды. Собственно, про это мы и поговорим с Филиппом Дельгадо и Владимиром Невзоровым сегодня вечером.

Интересно, что недавно я познакомился с бренд-менеджером издательства Питер и она любезно решила предоставить мне книжку Alex Xu "System Design. Подготовка к сложному интервью", которую я вручу слушателю за лучший вопрос во время дискуссиии. Кстати, у ребят до 3 декабря продолжается черная пятница со сидками: 40% на бумажные книги и 50% на электронные по промокодам "Бумажная" и "Электронная" соответственно. Отдельно отмечу, что при знакомстве я рассказал о качестве переводов, которые могли быть лучше и мне сказали, что над улучшением качества переводов в последнее время активно работают. И я бы хотел помочь в будущем с редактурой книг на темы engineering management и архитектуры.

В итоге, я подготовил подборку книг, доступных в издательстве Питер, которые могут быть полезны при прокачке навыков проектирования систем (список отчасти повторяет мою статью из блога)
1) System Design. Подготовка к сложному интервью - классическая книга про system design interview. В ней неплохо описывается сам подход + есть практические примеры. Конечно она не слишком подробна и местами слабо написана, но это отличный способ познакомиться с этим типом интервью.
2) System Design. Машинное обучение. Подготовка к сложному интервью - книга о том, как выглядят system design задачки в контексте ML инжиниринга. Качество примерно такое же, как у первой книги Alex Xu

Дальше идут более фундаментальные книги, которые позволяют наработать базу для практической работы, а также помогут на интервью
3) Современные операционные системы. 4-е изд.. - классическая книга от Эндрб Танненбаума и ко, из которой можно узнать об устройстве OS. Конечно эта книга достаточно академична, но в ней изложен фундамент. Для изучения вашей любимой OS рекомендую взять ту книгу, которая посвящена конкретно ей
4) Архитектура компьютера. 6-е изд. - классическая книга от Таненбаума про устройство компьютеров. Важно, что написанный нами код исполняется на железе, которое работает определенным образом. Понимание этого позволяет понять какие гарантии мы можем получить, насколько производительными могут быть узлы системы, а также насколько надежна получившаяся конфигурация. Лучше читать вместе с книгой про операционные системы, так как с голым железом большинство инженеров не взаимодействуют, а полагаются на абстракции от OS
5) Компьютерные сети. 6-е изд. - это классическая книга от Таненбаума про сети. В мире распределенных систем от сетей зависит очень многое, поэтому их точно надо изучить. Бонусом идут паттерны из сетевого мира, которые потом реплицируются часто на уровне приложений. Можно глянуть например на ретраи и exponential backoff или подходы к управлению QoS
6) Компьютерные сети - классическая книга про сети от Олиферов. В этой книге рассматриваются примерно те же вопросы, что у Таненбаума, но менее академично и более практично
7) Высоконагруженные приложения - классическая книжка с кабанчиком. В конце 2025 года будет новое издание, но и старое все еще ничего (я про него уже рассказывал)
😍 Распределенные данные - перевод книги "Database internals", которую я разбирал в двух частях: storage engines и distributed systems, а также обсуждали в подкасте "Code of Architecture"
9) Безопасные и надежные системы как в Google - перевод крутой книги "Building Secure and Reliable Systems", про которую я уже рассказывал раньше
10) Делай как в Google. Разработка программного обеспечения - перевод крутой книги "Software Engineering at Google", про которую я уже рассказывал

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

Duolingo (Рубрика #SelfDevelopment)

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

#SelfDevelopment

How to Deliver Quality Software Against All Odds • Daniel Terhorst-North & Julian Wood • GOTO 2024 (Рубрика #Management)

Интересное интервью Дэниела Терхорст-Норта, которое он дал Джулиану Вуду в рамках конференции goto. Интересно, что Daniel - это первый сотрудник лондонского офиса ThoughWorks, который когда-то давно в прошлом помог нанять туда звездную команду, многие из которых уже написали книги и часто выступают на goto конференциях. Но если возвращаться к тезисам доклада, то вот они

1) Дэниэль начинает с воспоминаний о том, как 20 лет назад он в рамках конфы сидел на дискуссии с Мартином Фаулером:) Он говорит, что конференции goto и yow были для него местом получения знаний и инсайтов (там выступали сами создатели технологий)
2) За последние 20 лет многие технологии и подходы прошли путь от новинок до буквально commodity. Например, потрепанный жизнью Agile, который стал просто маркетинговым термином, но вот например adoption CI/CD подходов пока не слишком хорощ (по мнению автора)
3) Сейчас актуальна тема эффективности использования ресурсов, автор упоминает про serverless в этом контексте.
4) Даниэль вспоминает про подход impact mapping от Гойко Аджича, про который я уже рассказывал. Этот инструмент стал популярным для создания гипотез и бизнесовых планов в виде mind maps. А это уже помогает правильно собрать эффективную архитектуру под требования бизнеса. Даниэль предлагает рассматривать архитектуру с точки зрения экономических драйверов
6) Дэниэль был пионером BDD (behavior-driven development) и создал jbehave, поэтому ребята обсудили связь BDD с разработкой, а также с TDD (test-driven development)
7) Даниэль поучаствовал в создании книги 97 вещей, которые должен знать каждый программист", куда он принес принцип о том, что надо писать код, используя язык бизнеса (аля ubiquitous language). Он рассказал пример о том, как это помогло ему в сложном проекте при его рефакторинге и понимании бизнес-правил
😍 Дальше Даниэль размышляет про DDD и важность понимания бизнесовой составляющей для программистов
9) Даниэль интересно рассказывает про свой путь в Thoughtworks, сбор команды и ранние проекты - очень интересно заглянуть за кулисы этого консультанта аля BCG, но из мира технологий:)
10) Так автор доходит до того, что они внедряли CI/CD и DevOps своим клиентам, когда этих слов еще не знали:)
11) Отдельно прикольно, как автор описывает проблемы крупных изменений в организациях - он сейчас консультирует разных заказчиков и есть проблемы с тем, чтобы преодолеит инерцию, запустить изменения и не потерять всю команды на их волне:)
12) К Даниэлю часто заходят топ-менеджеры крупных компаний за помощью в изменениях и он не может рекомендовать ни одной серебрянной пули, поэтому приходиться разбираться на месте с тем, что требуется и как этого достичь:)
13) Даниэль отмечает важность управления продуктом (do the right things), но он говорит, что это не его - он умеет в delivery (do the things right) и зачастую он работает в паре с крутыми CPO (chief product officer), чтобы создавать крутые продукты
14) Даниэль очень точно показывает разницу между продуктами и проектами, которая состоит в том, что мы по разному их финансируем и по разному подходим к управлению рисками (это прямо в точку)
15) У Даниэля есть проблемы с реализацией своих идей - у него их много, но он не умеет доводить свои личные проекты до конца. Уже больше 10 лет он пишет книгу "Software, faster" (еще с 2011-2012 года), но так и не дописал ее, а вот книгу "Patterns of effective teams" он почти дописал и это заслуга со-автора, что ограничил полет фантазии Даниэля:)
16) Напоследок ребята обсудили выступление Даниэля "Лучший программист, которого я знаю", про которое я расскажу отдельно, а дальше финализировали тезисами
- При разработке продукта люди являются ключевыми участниками процесса
- Цель - повлиять на изменение поведения и сделать жизнь веселее

P.S.
У Даниэля есть и другие выступления, про которые я рассказывал
- How to Bake a Change
- The Most Dangerous Phrase

#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking

Code of Leadership #24 - Interview with Konstantin Evteev (Рубрика #Management)

В этом эпизоде подкаста я беру интервью у Константина Евтеева. Костя - директор департамента ИТ сервисов, поддержки и инфраструктуры X5 Digital. В настоящий момент отвечает за инфраструктуру и развитие платформ для разработчиков. Прошел путь развития стартапа сервисов онлайн-доставки до одного из лидеров рынка. Раньше занимался развитием платформы баз данных и продуктовой разработкой в Авито. Активный участник PostgreSQL и других сообществ.

Мы обсудили следующие темы
- Как Костя начинал свою карьеру в Туле, работая в НИИ
- Как он перебрался в Авито и прошел собеседования
- Как в Авито менялась его роль по мере переноса логики из базы в микросервисы, а потом при разъезде на продуктовые и платформенные команды
- Как Костя участвовал в развитии Postgres и ездил на конфу по Postgres в Канаду с докладом
- Как ушел из Авито в X5 Digital (тогда X5 Food tech) за новым вызовом
- Как X5 Digital кратно рос, а Костя с командой справлялся с этим
- Какие советы для инженеров есть, чтобы расти как профессионально

Дополнительные ссылки от Кости
- Качество vs Скорость: технические процессы в растущей команде
- Запуск платформенных команд
- Recovery use cases for Logical Replication in PostgreSQL 10
- Standby in production: scaling application in the second largest classified site in the world
- Pg Saga (Хабр, Youtube)

#Architecture #Software #Management #Leadership #Processes #Architecture #Database

The Best Programmer I Know • Daniel Terhorst-North • GOTO 2024 (Рубрика #Leadership)

Интересное выступление Дэниела Терхорст-Норта (презентация тоже доступна), в котором он поделился своими наблюдениями о том, что делает хорошего программиста отличным. Фактически он разбил все наблюдения на три категории
1) Getting the job done
2) Choosing the right tool
3) Caring about the team

Part 1 - Getting the job done
1) Just start - для того, чтобы сделать работу, важно ее начать, а многим инженерам перфекционизм мешает это сделать:)
- Resist procrastinating - иногда перфекционизм превращается в прокрастинацию, с которой надо бороться
- Know you don’t know - первая версия не обязана быть правильной или хорошей, все равно она будет переписана
- Iterate wildly - это про test and learn и извлечение знаний из опыта (Try, fail, learn, repeat)
2) Build a product - мы не просто пишем код, а создаем продукт
- Invest in the outcome - собственно, должна быть какая-то цель и привязанность должна быть не к коду, а к достижению результата
- Study the domain - важно понимать домен и разговаривать на языке домена
- Watch your users - лучший способ получить обратную связь от пользователей — провести время с ними. Так вы сможете понять что мешает им и поправить это в продукте
3) Solve for now
- Learn to see what is really there - важно научиться видеть глубже
- Solve the real problem - важно решать реальные проблемы, а не те, которые кажутся таковыми.
- Strive for simplicity - нужно стремиться к простым решениям, а не плодить complexitty

Part 2: Choosing the right tool
1) Choosing the right tool for the product, not the team! - выбор инструментов должен основываться на продукте и ситуации, а не на предпочтениях команды.
- Teams can learn! - внутри команд работают инженеры, которые могут учиться новому:)
- Do the simplest thing, not the easiest - нужно выбирать инструменты, которые лучше подходят для решения конкретной проблемы.
- The ‘right tool’ may change over time - тут пример Scala для создания первой версии торговой системы, а потом замена ее на другой язык
2) Make the change easy
- Minimise blast radius - для упрощения изменений надо ограничить радиус их поражения:)
- Reduce, reuse, recycle - надо строить модульную систему, чтобы можно было менять отдельные компоненты
- Then do the same with production code! - Дэн рекомендует упрощать и продакшен код (рефакторинг)
3) Be a polyglot - важно быть универсальным разработчиком
- Explore languages, tools, paradigms - Дэну часто помогает с этим Advent of Code - 25-дневная игра с головоломками.
- Be ‘full-stack’ - тут про фронт, бек, API, мобилу
- Be really full-stack - здесь про инженерные процессы, железо и вопросы к тому, а зачем мы вообще делаем задачу:)

Part 3: Caring about the team
1) Caring about others
- Find joy in helping others learn - лидерские качества, работа в команде, наставничество и коучинг важны.
- Send the team home! - нет переработкам
- Be kind - предполагай, что люди вокруг делают лучшее из возможного, а также работай над психологической безопасностью в команде (подробнее я говорил об этом при обзоре проекта "Google's Project Aristotle" про команды)
2) Caring about staying current
- Join communities - контрибьють в коммьюнити и знакомься с новыми крутыми людьми
- Try new things - но подходи к этому со здоровым скептицизмом
- Practise, practise, practise - чтобы быть хорошим инженером, надо практиковаться
3) Caring about yourself
- Have interests outside of programming - нужны хобби вовне:)
- Go home on time - не забывай о доме
- Be kind to yourself - будь добр к себе и ведите себя так, как хотите, чтобы вели себя другие

Итого
- Наша работа - создавать полезные продукты, а не писать программы.
- Выбирайте правильные инструменты для конкретной ситуации.
- Заботьтесь о команде, себе и своем развитии.

P.S.
У Даниэля есть и другие выступления, про которые я рассказывал
- How to Bake a Change
- The Most Dangerous Phrase
- How to Deliver Quality Software Against All Odds

#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking

Откуда я беру интересные whitepapers (Рубрика #RnD)

Я люблю изучать научные статьи и уделяю этому много времени. Меня часто спрашивают где я их нахожу и я постоянно отвечают, что самые интересные статьи есть на сайтах bigtech компаний
1) Google Research. Основные области исследований Google включают машинное обучение, алгоритмы, квантовые вычисления, вычислительные системы, а также исследования в области науки, общества и ответственных технологий.
2) Amazon Science. В Amazon фокусируются на машинном обучении, компьютерном зрении, обработке естественного языка, квантовых вычислениях, автоматизации логистики и устойчивом развитии.
3) Meta Research*. Исследования охватывают искусственный интеллект, дополненную и виртуальную реальность, обработку естественного языка и социальные взаимодействия.
4) Mircosoft Research. Microsoft фокусируется на следующих областях: искусственный интеллект, машинное обучение, квантовые вычисления, компьютерное зрение, безопасность, взаимодействие человека и компьютера и технологии для социальных благ.
5) Netflix Research. Основные направления у Netflix сфокусированы на нужных для них темах: персонализация контента, оптимизация потоковой передачи, анализ данных и улучшение качества контента с использованием NLP и компьютерного зрения

Также есть общие библиотеки крупных ассоциаций
1) ACM Digital Library (ACM - Association for Computing Machinery)
2) IEEE Publications (IEEE - Institute of Electrical and Electronics Engineers)

P.S.
Я уже как-то рассказывал про свое увлечение whitepapers
1) Мое выступление на Techlead Conf "Как RnD появляется в крупных IТ-компаниях"
2) Новогодный выпуск "Code of Architecture" по white paper «Google's Hybrid Approach to Research»
3) Перечень изученных и разобранных за 1+ год whitepapers
4) Мой подкаст "Research Insights Made Simple" с разбором whitepapers (пока 5 эпизодов, что доступны на Youtube, Yandex Music)

P.P.S.
Meta - это запрещенная в России организация.

#Whitepaper #Architecture #Management #Science

Code of Leadership #25 - Interview with Anastasia Kabishcheva about group dynamics and BART Model (Рубрика #Management)

В этом выпуске подкаста речь идет про групповую динамику и модель BART (boundaries - authorities - roles - tasks), а в гостях у меня Анастасия Кабищева - организационный консультант и ментор, которая помогает разобрать эту сложную тему за счет своего опыта. Настя работала в разных ИТ-компаниях в качестве менеджера проектов и портфельного менеджера проектов, пересобирала команды для проектов заказной разработки, а сейчас заканчивает магистратуру по психоанализу в Вышке и пишет диссертацию на тему профессиональной идентичности продакт менеджеров. Кстати, эпизод доступен и в Ya Music.

За время выпуска мы успели обсудить следующие темы

- Что такое групповая динамика и чем ее знание может быть полезно
- Что такое идентичность человека / компании и как это связано с корпоративной культурой
- Как работают культурные принципы и причем здесь антропология
- Что такое модель BART и как она может помочь руководителю
- Что такое модель Такмана и как она связана с BART
- Как связано лидерство и алгоритм консенсуса Raft
- Как думать о политике внутри компании в парадигме теории игр, шахмат, го, ...
- Как изучить групповую динамику на практике

Дополнительные материалы

0. Сайт Анастасии "Soulcoaching"
1. Конференция про психоаналитические техники работы с бизнесом (10 декабря 2024) - Промокод для подписчиков канала - ENERGY50 (скидка на билет 50%)
2. Конференция GRC онлайн
3. Книга «Бессознательное в организации» (Гирнальзик, Катуржевский, Ломер)
4. Книга "Личность и групповая динамика" (Стейпли)
5. Вопросы для каждого блока модели BART
6. Канал про офлайн конференции GRC
7. Фреймворк SPACE на тему developer productivity
8. Книга "The corporate tribe"
9. Эпизод "Code of Leadership" с разбором книги "5 пороков команды"
10. Интервью "How to Deliver Quality Software Against All Odds • Daniel Terhorst-North & Julian Wood • GOTO 2024"

#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking

100 мерный арбуз или пару слов про определение успеха (Рубрика #Management)

Чуть раньше я уже рассказывал про научную статью "Assessing IT Project Success: Perception vs. Reality", что была посвящена рассмотрению изменяющегося понимания успеха IT проектов. Раньше эту тему активно педалировали ребята из Standish Group, еще в 1994 году рассказывая в "The CHAOS Report" о том, что большая часть IT проектов проваливается. Они рассматривали успех с точки зрения не просто проекта, а проектного управления, а точнее попадания в проектный треугольник: сроки, бюджет и scope в виде всех заранее определенных фичей.

The project is completed on time and on budget, with all features and functions as initially specified.

Новая статья мне понравилась, а вот старая изначально была с огромным багом в размышлениях. Я этот баг люблю демонстрировать на примере 100 мерного арбуза и оценки того, сколько в нем занимает мякоть, а сколько корочка:) Собственно мякоть - это то, что в Chaos report считается успехом, а корочка - это то, что считается неудачей. Представим, что в условном проекте, что рассматривали в Chaos report 98 фичей, а также отдельно сроки и бюджет. Получается, что у нас сто параметров в многомерном пространстве и прикольно было бы просто представить, а сколько мякоти в 100-мерном арбузе, но его представить себе очень сложно, поэтому давайте начнем разбор с чего-то простого

1) Представим, что у нас одномерный арбуз, а это просто отрезок на линии и его центр точка слева. Причем давайте договоримся, что крайние крайние десять процентов отрезка справа - это корочка. Тогда мякотью будет 90% нашего арбуза
2) Теперь перейдем в двухмерное пространство и здесь арбузом будет круг с радиусом R, причем дальние от центра 10% этого радиуса занимает корочка. Количество арбуза (в двухмерном пространстве это площадь) теперь квадратично зависит от радиуса и получается, что мякоти всего 0.9*0.9 = 81%
3) В привычном трехмерном пространстве арбуз - это шар, количество арбуза (здесь это объем) кубически зависит от радиуса и получается, что мякоти 0.9*0.9*0.9 = 0.729 ~ 73%
4) Продолжая эти размышления мы доходим до 100 мерного арбуза, где мякоти будет уже в гомеопатических количествах, а точнее 0.9^100 = 0.000027 ~ 0.0027%
5) Если же расслабить требования к каждому из критериев в этом стомерном пространстве и сделать так, чтобы мы считали любое отклонение меньше 1% по любому из критериев нормальным, то мы получим мякоти гораздо больше, а точнее 0.99^100 ~ 36,6% (то есть успех будет в 36.6% случаев)

По итогам этих размышлений об арбузах видно, что изначальное определение успеха проекта от Standish Group

The project is completed on time and on budget, with all features and functions as initially specified.

Имело мало смысла и способствовало только нагнетанию страха о том, как плохо управляются IT проекты.
В новом исследовании "Assessing IT Project Success: Perception vs. Reality" с этой точки зрения все сделано гораздо лучше - авторы отделяют оценку успеха по 7 критериям, использую шкалу Лайкерта, а также отдельно спрашивают про глобальный успех проекта. Это позволяет им отслеживать отдельные корреляции между глобальным успехом и остальными критериями.

Если подводить итог, то рекомендую при чтении статьей разбираться с тем, как авторы построили свою модель размышлений и насколько она применима к вашей задаче:)

#Management #Math #Leadership #SystemDesign #CriticalThinking

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

Сто лет недосказанности: Квантовая механика для всех в 25 эссе (Рубрика #PopularScience)

На прошлой недели я решил почитать что-то легкое и ненапряжное ... и снял с полки эту свежую книгу Алексея Семихатова, лекции которого я с большим удовольствием смотрел на ПостНауке. С тех пор Алексей успел написать две научно-популярные книги "Все, что движется" в 2023 и "Сто лет недосказанности" в 2024 году. Начал я с конца, а точнее со второй книги, в которой автор на пальцах изложил ключевые принципы квантовой механики и ее разнообразные интерпретации. В книге 25 отдельных эссе, которые связаны одной нитью, которая ведет нас как нить Ариадны от вопроса "из чего сделаны вещи" к стандартной модели элементарных частиц, проходя через все основные промежуточные станции, навроде молекул и атомов, электронов и фотонов, уравнений Шредингера и Дирака, горячих дискуссий Бора и Эйнштейна относительно верности копенгагенской интерпретации и так далее. Если говорить про основные моменты, которые осветил автор, то это

1) Принципы квантового мира: автор обсуждает особенности квантовой реальности, которая плохо дружит с человеческой интуицией. Он объясняет, как квантовые законы формируют мир вокруг нас, включая существование атомов, взаимодействие света и вещества, а также процессы, лежащие в основе работы Солнца
2) Эволюция квантовых систем: автор рассматривает правила, по которым развиваются квантовые системы во времени (тут появляется уравнение Шредингера и его кошка), а также роль вероятностей в этих процессах (тут отрабатывает правило Борна). Интересно рассматривается коллапс волновой функции при наблюдении
3) Интерпретации квантовой механики: Семихатов исследует различные подходы к пониманию квантовой реальности — от гипотезы параллельных вселенных до вопросов о разрывах в восприятии. Эти интерпретации очень интересны с точки зрения философии (мне особенно понравился кьюбизм, который напомнил мне солипсизм по своему подходу)
4) Переход к макромиру: В книге объясняется, как привычная нам реальность возникает из чуждого ей квантового мира. Семихатов показывает, что классические законы физики не могут объяснить многие явления без учёта их квантовой природы
5) Спин и его значение: спин электрона проходит через всю книгу, автор описывает его как квантовую меру вращения, и при помощи этого свойства проще всего демонстрируется фундаментальная квантовая природа нашего мира. Для измерения направления спина используется прибор Штерна — Герлаха, который появившись в одной из первых глав дальше упоминается постоянно:)

Итого, книга мне очень понравилась - я прочитал ее буквально на одном дыхании за пяток вечеров. Думаю, что она мне бы пригодилась для наглядной визуализации концепций, изложенных Ландау и Лифшицев в их знаменитой серии, которые я читал лет 20 назад, когда изучал теорфиз на Физтехе:) Особенно, это верно, если учесть, что в книге Алексея Семихатова нет ни одной формулы:)

#PopularScience #Physics #History

Манюня (Рубрика #Kids)

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

А вообще книга наполнена теплым юмором и, читая ее детишкам, я сам часто улыбаюсь:)

#ForKids #ForParents #Humor

Архитектурная ката от клуба { между скобок } (Рубрика #Architecture)

Несколько недель назад Гриша Скобелев, основавтель клуба { между скобок } (@backend_megdu_skobkah) собрал людей для участия в архитектурной кате. А в группу экспертов он позвал несколько человек, включая меня. Задача была в проектировании масштабируемой и отказоустойчивой системы поддержки клиентов, работающей через чат. Фокус был в том, чтобы разобраться а как обеспечить связь клиента и оператора поддержки в режиме реального времени с минимальными задержками. Сейчас стала доступна запись этой каты

Полезные ссылки:
- ArchDays - конференция по архитектуре, где я в программном комитете
- Объединение ИТ-Архитекторов
- Канал Игоря Антонова про разработку
- Хорошее видео про event storming
- Про микросервисы от Сергея Баранова

#Architecture #DistributedSystems #SystemDesign #Engineering #Software

Introducing Domain-Oriented Microservice Architecture - Part I (Рубрика #Architecutre)

В 2020 году Adam Gluck написал интересный пост про редизайн микросервисной архитектуры Uber и переход на DOMA. А потом Адам уволился и пошел пилить свой стартап, но к делу это не относится:) Если вернуться к статье, то Адам описал стадии эволюции архитектуры

1) Монолитная архитектура (примерно 2012-2013), где было 2 больших сервиса и набор проблем: риски доступности, опасные деплои, poor separation of concerns, плохой execution изменений в бизнес-логике. Эти проблемы возникли при росте от десятков инженеров к сотням
2) При решении этих проблем ребята пошли в микросервисную архитектуру ради: общесистемной надежности, separation of concerns, ясной ответственности и владения (ownership), скорости разработки (developer velocity). Ребята на начальных этапах получили все запланированное, но при росте команды до тысяч инженеров возник распределенный монолит
3) С 2018 года шла работа над новой концепцией под названием DOMA (Domain-oriented microservice architecture), в которой ребята решили, что микросервисы - это просто i/o-bound библиотеки, а микросервисная архитектура - это большое распределенное приложение, то для его архитектуры можно использовать стандартные подходы
- Domain-driven design - про эту концепцию интереснее всего читать у Влада Хононова в книге "Learning DDD", на которую я написал 4 кратких обзора: общий обзор DDD, DDD и микросервисы, DDD и event-driven architecture, DDD и data mesh
- Clean architecture - лучше всего изучить книгу Книга "Clean Architecture" и ее часть про дизайн модулей - мое краткое саммари этой части здесь
- Service-oriented architecture - это предтеча микросервисной архитектуры:)
И на выходе получаться принципы для дизайна крупных распределенных систем в больших организациях.

Основные принципы DOMA такие

1) Вместо ориентации на отдельные микросервисы надо ориентироваться на их коллекции, что организованы вокруг доменов
2) На самом деле домены тоже объединяются в коллекции, которые называются уровнями. Уровни определяют то, какие зависимости могут быть у микросервисов внутри домена. Базовое правило - это то, что микросервисы из верхних уровней могут зависеть только от микросервисы с нижних уровней. Авторы называют это слоенным дизайном. Для меня он напоминает семиуровневую модель OSI (технологии часто развиваются по кругу)
3) Домены предоставляют чистые интерфейсы (clean interfaces), которые являются единой входной точкой в коллекцию. Такие входные точки называются gateways
4) Зависимостями между доменами быть не может - ни по коду, ни по моделям данных. Для того, чтобы сделать доступным включение логики из одного домена в другой (например, для кастомной валидации или мета контекста) авторы предоставляют точки расширения внутри доменов

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

1) Infrastructure layer. Provides functionality that any engineering organization could use. It’s Uber’s answer to the big engineering questions, such as storage or networking.
2) Business layer. Provides functionality that Uber as an organization could use, but that is not specific to a particular product category or line of business (LOB) such as Rides, Eats, or Freight.
3) Product layer. Provides functionality that relates to a particular product category or LOB, but is agnostic to the mobile application, such as the “request a ride” logic which is leveraged by multiple Rides facing applications (Rider, Rider “Lite”, m.uber.com, etc).
4) Presentation. Provide functionality that directly relates to features that exist within a consumer-facing application (mobile/web).
5) Edge Layer. Safely exposes Uber services to the outside world. This layer is also mobile application aware.

Окончание обзора в следующем посте.

#DistributedSystems #Architecture #SystemDesign #Engineering #Software

Introducing Domain-Oriented Microservice Architecture - Part II (Рубрика #Architecutre)

Заканчивая рассказ про DOMA, начатый в первом посте, я хотел бы рассказать про оставшиеся компоненты архитектуры и получившиеся результаты.

Третьим архитектурным принципом является gateway. Он достаточно стандартен с точки зрения технической реализации, но на уровне домена он позволяет обеспечить за счет четкого котракта уменьшение сложности для взаимодействующих с доменом, а также более простые миграции внутри самого домена. Четвертый элемент - это точки расширения предлагают две возможности: расширение логики и расширение модели данных. Логические расширения реализованы через возможность подключения плагинов с интерфейсами определяемыми для каждого сервиса самостоятельно (приводится пример с кейсом, когда водитель выходит на линию и дополнительными проверками, что ему можно это делать). А данные можно расширять через добавление к core-модели данных произвольных опций. Также команды внутри доментов могут придумывать и другие точки расширения.

На выходе авторы получили
1) Снижение сложности: благодаря объединению 2200 микросервисов в 70 доменов DOMA упрощает управление зависимостями и обслуживание системы (за счет доменов и слоев)
2) Улучшенная масштабируемость и гибкость: архитектура позволяет осуществлять независимую разработку и развертывание доменов, сохраняя гибкость для будущих миграций (за счет gateways)
3) Улучшенный опыт разработчиков: структурированный подход снижает когнитивную нагрузку на разработчиков, позволяя быстрее разрабатывать функции и упрощать устранение неполадок (за счет понятных API и точек расширения)
4) DOMA доказала свою эффективность в управлении крупномасштабными operations в Uber

Напоследок автор рекомендует использовать стартапам монолиты, средним по размеру организациям микросервисы, а большим идти в сторону дома (DOMA)

Итого, это интересная статья от ребят из Uber из 2020 года. Если сейчас поискать дополнительную информацию, то кажется, что этот подход до сих пор используется Uber. Ради интереса я поискал whitepapers от Uber на тему DOMA и не нашел ни одной - Uber не Google, чтобы писать научные статьи:)

#DistributedSystems #Architecture #SystemDesign #Engineering #Software