Infobesity - How to Cope with the Overload of Information • Fabio Nudge • YOW! 2023

Интересный доклад про инфоожирение (или информационное ожирение) от Fabio Nudge, который написал книгу "Digital nudge". Рассказ Фабио состоит из следующих частей
- Автор вспоминает про поведенческую экономику и рекомендует книги "Thinking Fast & Slow", "Predictably Irrational", "Nudge" (а также дополнительно еще три: "Building a Second Brain", "A World Without Email", "Make time")
- Показывает как работают nudges на примере ранжирования поисковых ответов, а также streaks из snapchat, duolingo
- Дискутирует относительно того, чем отличается push от nudges. Тут он показывает тизер сериала "The push" от Netflix, а дальше говорит, что nudge - это когда человек может отказаться от предложения:)
- Потом опять идет отсылка, но уже к книге "Hooked" и моделе trigger -> action -> variable reward -> investment -> trigger -> ...
- И дальше рассказывает про убеждение (persuasion) и принуждение (coercion), которые похожи, но в убеждении это то, чего хотят и то, что нужно людям, а вот в принуждении наоборот
- Как пример автор показывает кусочек выступления сооснователя Duolingo "How to make learning as addictive as social media", а конкретно Фаби показывает часть про streaks
- Ну и потом начинается история про избыточность информации и то, как нас ей заваливает со всех сторон
- Он сравнивает это изобилие с изобилием еды, что нам доступна сейчас. Но наш мозг развивался в условиях недостатка пищи, поэтому когда мы снабжаем его пищей, то он вознаграждает нас за это ... даже если это четвертая шоколадка за день. А это легко приводит к ожирению. Ну а по отношению к информации это приводит к infobesity
- А дальше автор переходит к советам о том, как блюсти цифровую диету и говорит

Being aware of your sources of dopamine and understanding what’s good and bad for you is one of the best tools to fight infobesity.

- Автор рассказывает про проект "Cognitive Loadometer" для измерения когнитивной нагрузки на команды
- Дальше говорит про модель push и pull - смысл в том, что иногда в нас пушат информацию (например, присылают emails), но потреблять информацию удобнее по моделе pull - так мы можем контролировать ситуацию (фильтровать сообщения, потреблять асинхронно, когда нам удобнее, etc)
- Автор показывает как можно использовать фильтры в почте, чтобы отфильтровать только важное (для этого он использует labels и дальше фильтры по булевым выражениям с ними)
- Дальше автор показывает группировку вкладок в Chrome для объединение вкладок по контексту и переключения между ними
- Заканчивается выступление упоминанием BMI (body mass index), который используют как метрику ожирения. А дальше Фабио предлагает пройти опрос и померить свой infobesity вес, заполнив форму в Google forms и прочитав расшифровку результата на сайте книги

В общем, доклад реально интересный и многие советы реально полезны:)

P.S.
Больше года назад я рассказывал про другой доклад Фабио "The Psychology of UX", который можно считать предысторией к докладу про "Infobesity"

#Conference #PopularScience #Software #UX #Economics #Psychology

Statist — платформа продуктовой аналитики

У нас на tinkoff.ru появилась статья про нашу платформу продуктовой аналитики Statist, которую мы обсуждали с Андреем Цыбиным в выпуске Code of Leadership #8. Собственно статью написал как раз сам Андрей.

Если рассказывать кратко, то Statist
- это единая платформа Тинькофф для сбора продуктовой аналитики и телеметрии с мобильных и веб-приложений
- позволяет собирать, обрабатывать и визуализировать данные как о поведении клиентов, так и о технических деталях работы приложений
- дает возможность отслеживать изменения в продукте, искать инсайты в UX приложений, реагировать на сбои
- позволяет использовать практики data governance, а точнее разметить событиями метаданными и разделить их по клиентским приложениям, их версиям и так далее

В итоге, мы можем принимать решения о развитии продуктов Тинькофф на основе данных, полученных и проанализированных при помощи Statist. Аминь!

#Analytics #Architecture #DistributedSystems

ЦЕХ № 4 от МИФ

На этой неделе у меня началось обучение на "курсе для тех, кто мечтает издать книгу". У меня это сейчас не на уровне мечты, а скорее на уровне задачи на этот год:) Я себя подписал на это еще в октябре 2023, о чем рассказывал раньше, а теперь пришло время начать учиться:) В итоге, вчера я почитал материалы и посмотрел первый урок в записи, так как письмо о начале курса попало в папку с рассылками от МИФа про книги, о чем я узнал постфактум:) В итоге, первый урок был посвящен
- Знакомству с экспертами курса - нам показывли иконостас в виде тех редакторов и авторов, которые будут читать нам лекции
- Рассказу про программу, формат и правила обучения на курсе
- Рекомендациям по прохождению уроков и выполнению домашних заданий
- Рассказу об условиях участия в конкурсе на издание книги в МИФе
Надеюсь, что следующие уроки я смогу посмотреть не в записи:)

P.S.
По плану к концу лета у меня должна быть готова как минимум одна книга:)

#Writing #SelfDevelopment

Patterns of Distributed Systems • Unmesh Joshi & James Lewis • GOTO 2024

Крутое интервью Unmesh Joshi, автора книги "Patterns of Distributed Systems". Расшифровка доступна здесь. Общение состоит из следующих моментов
- Unraveling the Foundations: A Patterns-Based Exploration
Автор книги рассказывает про свой путь как инженера и как он дошел до жизни такой, что написал книгу про паттерны распределенных систем. Мне особенно понравилось как Unmesh рассказывает про изучение реальных распределенных систем (Akka, Kafka, Cassandra, ...), в которых автор находил практические реализации тех концепций, что обычно описаны в whitepapers. Например, в интервью обсуждается часы Лампорта и whitepapers Барбары Лисков (ее принцип отвечает за букву L в акрониме SOLID). В общем, я бы сам с удовольствием поковырялся в реальных технологиях и попробовал сравнить как теоретические концепции реализуются на практике в разных системах и на какие trade-offs идут авторы этих систем
- Should Every Software Developer Should Understand Distributed Systems?
В общем, ответ да:) Но точка зрения зависит от контекста. Условные микросервисы - это тоже распределенная система. Но фокус автора книги был на данных и поддержании их консистентности на многих серверах и он фокусировался на работе систем аля Kafka, Cassandra, Amazon S3, Cosmos DB.
- Comparing Patterns: Raft and Paxos
Здесь ребята обсуждают модели консенсуса - они говорят про
1) Paxos, который предложил уже упоминавшийся Лампорт
2) Raft, одним из соавторов которого был Джон Остерхут, чью книгу "A Philosophy of Software Design" я уже рассказывал в постах: 1 и 2
Тут авторы вспоминают про CAP теорему (я про нее рассказывал), не вспоминают про ее расшширение в виде PACELC (я про нее рассказывал), вспоминают Jepsen с его тестированием гарантий производителей баз данных и проверкой их соответстия моделям консистентности (про них я тоже рассказывал). В обсуждении они говорят про время и вспоминают про TrueTime от Google и гибридные часы в MongoDB, YugabyteDB и CockroachDB.
- Why Are Patterns Useful?
Пользу от паттернов лучше описать словами автора книги

One of the goals for these patterns work as well is that someone reading this material should be able to navigate open-source code bases. And I think navigating, I mean, following open-source products and going through their code bases, trying out, maybe isolating some pieces of it and playing with it, I think that's a great way to learn about distribution. I mean, particularly topics like distributed systems, it's a great way to learn because if you go down the route of theoretical understanding, I mean, there are a lot of nice books, I would say, but you might get lost. So I think it helps a lot to remain closer to code while you are learning stuff.

- Conclusion
Напоследок ребята подводят итоги и James пытается выяснить творческие планы у Unmesh, который планирует продолжать работу над паттернами, а также начать проводить воркшопы на эти темы. Думаю, что я бы на такой воркшоп бы записался:) Ну и обязательно прочту эту книгу - автор мне ее продал в этом интервью.

#Software #Architecture #DistributedSystems #SystemDesign #Patterns #Engineering

Node.js: The Documentary | An origin story

Вчера на канале Honeypot вышел часовой документальный фильм про историю создания Node.js.

История начинается в 2008 году, когда javascript был технологий для написания кода на фронте и исполнения его в браузере. Но потом появился движок Google V8 и Ryan Dahl соединил идею неблокирующих сервисов, javascript и запуска этого в V8. Так появился Node.js. Он рос и развивался под руководством Ryan, но в какой-то момент Joyent Inc решило предложить Ryan денег и выкупить права на trademark Node.js, а также начать руководить этим open source проектом. Ryan согласился и успешно проработал в компании Joyent пока у него не завестились все обещанные плюшки, а потом он передал проект Isaac Schlueter, который когда-то создал npm, менеджер пакетов для Node.js. Дальше эта история закрутилась и привела к ситуации, когда community из ранних контрибьюторов node.js решило форкнуть проект, чтобы развивать его параллельно Joyent ... А как закончилась эта история вы узнаете из самого фильма:)

P.S.
Это интересная история про динамику взаимоотношений внутри open source проектов. Зачастую сложно обеспечить баланс между желаниями core контрибьюторов, запросами community, а также компанией, из которой вышел open source продукт или которая его купила на ранней стадии. В итоге, при неаккуратном развитии событий легко словить split brain и получить вместо единства кучу отдельных форков, что эффективно приводит к падению популярности технологии и скорости инноваций в mainline технологии (так как инновации теперь кусочно распределены между форками).

#OpenSource #Management #Leadership #Engineering #Software

Understanding Statistics and Experimental Design. How to Not Lie With Statistics (Статистика и планирование эксперимента для непосвященных)

Эта книга подойдет даже новичкам - авторы отлично постарались, чтобы донести основы статистики максимально просто, с минимумом формул и максимумом смысла. Если вы когда-то слышали магические слова навроде a/b тесты, статзначимость, t-критерий, p-value и хотели понять что именно это значит, то эта книга для вас. Если вы знаете теорвер, матстаты, матанализ, то вам будет проще следить за мыслью авторов, но даже без этого эта книга позволит вам начать чувствовать bullshit, который иногда показывают под видом отличного эксперимента. В общем, в эпоху повсеметного data-driven эта книга всего в 150+ страниц очень хороша:) Она доступна бесплатно на сайте издательства Springer.

Сама книга состоит из 3 частей и 12 глав
I - Принципы статистики - эта часть must read для людей, что используют статистику для принятия решений
1 - Основы теории вероятностей - авторы говорят про вероятность, распределение вероятностей, условную вероятность и концепцию независимых событий. Дальше рассматривается вариант анализа на некоторую болезнь и дальше вводятся термины чувствительность (sensivity), специфичность (specificity), частота ложноположительных результатов (false positive rate) и частота ложноотрицательных результатов (miss rate). Дальше автор показывает как это все работает вместе и почему даже врачи не всегда понимают статистику:)
2 - Планирование эксперимента и основы статистики: теория обнаружения сигналов - авторы идут от signal detection theory и на примере желтой подводной лодки и эхолокаторов показывают как выглядит дизайн эксперимента и принятие решения. По-факту, у нас есть различимость сигнала и шума, а также некоторый порог принятия решений. В итоге, процент верных решений смешивает их вместе. Этот вывод дальше авторы показывают в части про t-критерий, где размер эффекта смешан с размером выборки:)
3 - Главная концепция статистики - здесь авторы рассказывает про канонический подход к статистике, обсуждают статистику для выборочного среднего, а дальше показывают как можно сравнивать выборочные средние при помощи одностороннего и двухстороннего t-критерия. Дальше авторы показывают, что в стандартном тесте p-value контролирует частоту ошибок первого типа или false positive, когда мы находим эффект, а его нет. Еще интереснее обсуждение рассчета мощности эксперимента, который говорит про вероятность получить значимый результат, если альтернативная гипотеза верна (то есть средние в наших совокупностях отличаются). Концепция мощности нужна в дальнейших главах, особенно в третей части книги. А вообще самая сочная часть этой главы - это следствия в конце, которые напрямую влияют на дизайн экспериментов и говорят про размер выборки, размер эффекта, нулевые результаты и так далее
4 - Вариации на тему t-критерия - это глава со звездочкой относительно третей главы, где рассматривался обычный t-критерий

II - Множественная проверка гипотез - очень интересная часть, про то, насколько сложно задизайнить правильный эксперимент с множественной проверкой гипотез
5 - Задача множественной проверки гипотез
6 - Дисперсионный анализ (ANOVA)
7 - Планирование эксперимента: подгонка модели, мощность и сложные планы - очень важная глава для практика-экспериментатора, где авторы делятся правильной методикой и показывают на примере как можно отстрелить себе обе ноги и не только
8 - Корреляции - сравнение t-критерия, ANOVA и стандартной истории с поиском корреляций между относительными переменными (в ANOVA у нас независимые переменные номинальные)

III - Метаанализ и кризис науки - эту часть интересно прочитать ученым и тем, кто любит читать статьи английских ученых:) Тут авторы на пальцах показывают как в погоне за результатами авторы исследований публикуют слишком хорошие результаты, чтобы они были правдой:)
9 - Метаанализ
10 - Воспроизводимость
11 - Величины избыточного успеха
12 - Предлагаемые улучшения и нерешенные проблемы

#Math #Statistics #PopularScience #Science #ML #Data

Code of Leadership #10 - An Elegant Puzzle - System of Engineering Management (часть 2)

В десятом выпуске Code of Leadership заканчивается обсуждение крутой книги "An Elegant Puzzle: Systems of Engineering Management" (начало в выпуске 9), про которую я уже рассказывал. Эту книгу написал Will Larson, технический директор Carta, который до этого работал в Calm, Stripe и Uber. В этой книге автор рассказывает про подходы к engineering management.
Книгу мы продолжаем разбирать с Eugene Sergueev, senior engineering manager во Flo health, приложении для женского здоровья. У Жени больше 15 лет опыта в индустрии, из которых 7 лет в менеджменте. Он успешно руководил небольшими командами, так и компанией 50+ человек на позиции СТО. Женя любит системный подход к решению проблем, поэтому он и выбрал эту книгу для обсуждения.

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

3. Tools - как проводить инженерную реорганизацию (и стоит ли это вообще делать), как формировать свои карьерные нарративы, как подходить к продвижению сложных тем без формального authority с использование подхода model-document-share, как делать презентации топ-менеджменту и управлять своим временем
4. Approaches - как не погрязнуть в управлении исключениями к собственным policies, как говорить нет, формулировать свою философию менеджмента, как понимать где у engineering managers возникают проблемы, как быть в партнерских отношениях со своим менеджером, находить себе зону ответственности и устанавливать направление развития организации
5. Culture - как формировать культуру инклюзивной организации с использованием возможностей и membership, как выбирать лидов проектов, делать своих peers первой командой, как балансировать positive и negative freedoms в культуре компании, отказаться от культуры героев в пользу устойчивого роста
6. Careers - как выстраивать процесс интервью, как проводить холодный sourcing, работать над воронкой найма, использовать performance management для развития уже нанятых сотрудников через понятные карьерные лестницы, как создавать специализированные роли вроде SRE или TPM (technical product manager), как проектировать циклы собеседований для желаемых позиций
7. Appendix - как оперировать в растущей оранизации: на уровне линейного менеджмента, уровне middle management и дальше менеджмента всей организации, а напоследок автор приводит список книг и white papers по интересным для него темам

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

Developer Joy – How great teams get s%*t done - Sven Peters - NDC Porto 2023 - Part I

Интересное выступление от Sven Peters из Atlassian на тему developer productivity, developer experience и developer joy:)
Автор начинает с того, что возвращается в прошлое и вспоминает про Тейлора и его научный подход к менеджменту на заводе. Правда, там выполнялась однотипная работа на конвейере, но за счет измерения времени выполнения разных активностей Тейлор смог оптимизируя инструменты, время на отдых и другие вещи повысить эффективность завода в разы. Но сейчас в информационный век многие хотят научиться также повышать эффективность разработки, но разработка сейчас достаточно сложна и software development engineer должен уметь работать над quality, работать в облаке, деплоить и эксплатировать свое решение (you build it, you run it). Я говорил про эту же проблему в своем подкасте "Software development engineers в tech компаниях". Но автор предлагает уйти от термина developer productivity к developer joy и разобраться с тем, что делает работу разработчиков приятной и продуктивной и туда попадает
- Dev quality - качество кодовой базы, архитектуры, отсутствие техдолга
- Dev progress - темп разработки и поставки фичей
- Dev value - какую пользу приносят поставленные фичи
Автор рассказывает на примерах из разных команд
- Команда Jira написала code of conduct для проведения ревью кода
- Команда Confluence, которая написала инструмент для поиска нестабильных (флакающих) тестов во время прогонов
- Команда Confluence написала бота для пушинга участвующих в code review - это уменьшило среднее время ревью PR с 3 дней до 1.2 дня

Дальше автор рассказывает про зависимости между командами, что тормозят разработку. Он делает это на примере того, как разные развязки на дорогах влияют на пропускную способность шоссе. Когда мы делаем нормальные развязки, которые позволяют машинам не мешать друг другу, то мы получаем максимальный traffic flow. Этим автор обосновывает стремление к автономным командам. А дальше он рассказывает про команду Trello, где на 1 qa инженера приходится 30 software development engineer. В итоге, сами sde забирают на себя большую часть стандартных функций qa-инженеров, а потому не ждут пока qa-инженеры протестируют их фичи. Плюс автор рассказывает про подход с блиц тестированием, когда вся команда тестирует критически важную функцию. Забавно, что оставшиеся qa-инженеры отвечают за qa-тулинг, тестовые данные, базы и так далее.

Продолжается история тем, что разработчикам надо понимать dev value
- Инженеры (sde) и продакт менеджеры должны работать вместе над одним и тем же делом
- Инженеры (sde) должны быть вовлечены в процесс создания и понимать проблему, которую нужно решить
- Стоит использовать демо, которые важны для всех команд, они помогают увидеть результат и ценность, которую создают для клиентов

Дальше идет речь про измерение производительности и улучшение показателей
- Как помним еще Тейлор говорил о важности измерения производительности труда
- Если у вас ничего нет, то стоит начать с метрик DORA
- А дальше стоит начать использовать свой собственный инструмент для базовых показателей отслеживания прогресса
- Раньше в офисах раньше были настенные панели и телевизоры, на которых можно было видеть состояние сборки и тестов.
- Сейчас используются проверки, которые помогают определить проблемы и улучшить показатели.

Автор рекомендует использовать разметку задач и оценивать время, которое команда тратит
- На change бизнеса
- На keep the lights on (поддержание работы)
- На поддержание эффективности разработки и улучшение developer productivity

Developer Joy – How great teams get s%*t done - Sven Peters - NDC Porto 2023 - Part II

Начало обзора этого выступления есть в первом посте. А здесь надо еще расскаать про использование регулярных опросов разработчиков, чтобы узнать их мнение о различных аспектах работы. Результаты опроса помогают определить области, требующие улучшения и обсудить их с командой. В Atlassian команды используют 10% времени для исправления ошибок и улучшения производительности разработчиков. Некоторые команды проводят "week of developer joy", а другие включают планирование в спринт и работают над проблемами производительности. А также команды распространяют знания и делятся с коллегами полученными выводами - например, команда создала пост в блоге о своем решении проблемы и его использовании в других командах.

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

P.S.
На похожую тему я размышлял в постах про developer productivity: 1, 2 и 3.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

ЦЕХ 4 - Урок #1 "Увидеть свое имя на обложке может каждый"

На прошлой неделе прошел первый вводный урок курса для начинающих авторов, что планируют написать и издать книгу:) Этот урок напоминал самосбывающее пророчество, которое должно было вдохновить участников и вселить в них уверенность в своих силах. Екатерина Звонцова и Ренат Шагабутдинов одновременно рассказывали и про non-fiction и про художественную литературу. Были рассмотрены следующие темы

1) Как начать писать книгу - авторы блогов и статей могут начать собирать книгу из своих материалов уже опубликованных в блоге (я так и планирую сделать). Но даже если у вас нет блога, но есть соцсети, то можно поискать в своих постах материалы для старта, чтобы не сталкиваться с эффектом пустой страницы. Если мы говорим про художественную книгу, то начинать стоит когда в голову пришла идея сюжета или персонажей, которыми вы хотите поделиться с другими или поднять важную проблему. Но тут важно выбирать персонажей и тему, которая интересна как вам, так и читателю.
2) Зачем писать книгу - написание книги может помочь структурировать мысли, поделиться опытом, передать свою философию (примерно поэтому я пишу статьи и хочу написать книгу). Отдельно эксперты курса отмечают, что написание книги может быть способом стать экспертом в своей области и повысить свой статус. Но тут важно разбираться в теме, которую вы исследуете, чтобы лучше ее преподнести другим. А вот художественные книги могут помочь автору осмыслить свой опыт и преподнести его так, чтобы он обладал терапевтическим эффектом для читателей, которые тоже переживают сложный период
3) Написание книги позволяет научиться чему-то новому и творческому - через творчество автор может узнать что-то новое и интересное, а также это может быть способом общения с миром. Это может помочь найти своих единомышленников и сформировать сообщество вокруг себя.
4) Про успех - даже если успех приходит к автору, то не стоит ожидать мгновенных результатов. Важно продолжать работать над своими навыками и повышать свои шансы на успех. Часто здесь работает подход накопления авторитета - сначала автор работает на зачетку, которая затем работает на автора:) Факторами успеха могут быть: экспертиза, платформа, харизма, начитанность, структурированность текста, юмор, примеры, иллюстрации. Классно, если случается вирусный эффект: сарафанное радио, рекомендации книги другим. Иногда визуальное оформление и обложка книги тоже влияет на успех книги.
5) Самозванец и критик - Эксперты рассказывают про то, что с ростом знания темы растет осознание того, как много еще не известно. Поэтому даже у экспертов есть синдром самозванца (правда, эксперты умеют его преодолевать). Другая история основана на "проклятии знания", когда экспертам сложно передавать свои знания, так как для них все очевидно и не ясно зачем разжевывать материал (а всем остальным почти ничего не ясно).
6) Страхи и сомнения начинающих авторов - здесь эксперты говоят о том, что даже если вы не являетесь "небожителем", вы все равно можете добиться успеха, если будете развиваться и двигаться вперед. Причем если вы уже задумываетесь о проблемах и осознаете их, то вы уже на правильном пути.
7) Уникальность темы книги - есть мнение, что все уже написано до нас ... Но всегда можно найти свое и написать уникальную книгу на стыке двух тем, которые могут быть обычны и тривиальны. Кроме того, можно написать книгу под конкретных читателей, которые могут быть разными по уровню знаний и интересам. В общем, наличие уже написанных книг на выбранныю тему - это не приговор, а скорее хороший знак - люди интересуются этой темой:)

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

#Writing #SelfDevelopment #Management

ЦЕХ 4 - Урок #1 "Увидеть свое имя на обложке может каждый" (Часть 2)

Продолжая предыдущий пост, рассказываю про содержание первого урока по написанию книги
😍 Установка на работу над текстом - даже если текст не получается не совсем идеальным, то над ним надо работать системно и исправлять недостатки и постепенно улучшать.
9) Внутренняя опора и важность текста для автора - автору важно осозновать, что этот текст нужен ему самому, а не только является внешним проявлениям успеха. В этом случае у автора будет внутренняя опора и понимание того, зачем он занимается творчеством, а это может помочь преодолеть трудности и продолжить писать.
10) Публичность автора - публичность автора может помочь в продвижении книги, но это не обязательный критерий. Автору важно выбрать уровень публичности, который ему комфортен.
11) Процесс работы над книгой - тут важна системность и движение маленькими шагами, которые приближают к большой цели. Важно не думать постоянно про большую цель в виде конечной книги - это может демотивировать. А вот за достижение ежедневных результатов можно себя и похвалить:) Тут, кстати, хорошо работает концепция streaks, про которую рассказывал автор доклада "Infobesity" (подробнее здесь)
12) Планирование и систематизация информации - этот процесс может быть поначалу сложным, но можно воспользоваться подходами типа Zettelkasten (я как-то сделал обзор этой книги). Также можно использовать mindmaps для структурирования информации и поиска связей между различными уровнями книги.
13) Планирование и сюжетные точки книги - этот пункт важен при написании художественных книг и там надо ответить на четыре базовых вопроса для определения идеи книги: кто, где, что и кто мешает. Также важно понимать основные сюжетные точки: экспозиция, завязка, развитие действия, кульминация и развязка, для облегчения процесса написания. Эти знания помогут сориентироваться в процессе написания и будут полезны для всех авторов, независимо от их опыта.
14) Самотивация и эмоции при работе над книгой - для самомотивации можно представить, что книга уже напечатана и находится в руках, и поделиться позитивными эмоциями, которые это вызывает. Однако, когда книга уже будет напечатана, то важно помнить, что внешние факторы, такие как продажи и отзывы, не всегда отражают качество книги. Поэтому если продажи идут не так как вы представляли, то не стоит опускать руки. Важно спокойно относиться к критике и продолжать работать над своими навыками написания хорошего текста.

#Writing #SelfDevelopment #Management

Architecture Modernization: Aligning Software, Strategy, and Structure - Nick Tune

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

Architecture Modernization is about converting architecture from a competitive disadvantage to a competitive advantage.

И дальше его подход содержит три пункта
1) Architecting for flow - проектирование для улучшения потока создания ценности и взаимосвязи изменений
2) 5 Essential tools for architecture modernization - инструменты для модернизации архитектуры
3) Kickstarting and enabling architecture modernization - как начать модернизацию

В первой части автор говорит про stream-aligned команды из team topologies, которые формируют вокруг value-stream. Отдельно надо отметить, что иногда между системами команд бывают зависимости, которые влияют на flow. Поэтому все и мечтают создавать автономные команды (про это было много в докладе, о котором я рассказывал вчера):)

Дальше спикер говорит про fullstack модернизацию по всем уровням

- User interface - modernize the UI to enable a better UX improving user happiness and productivity
- Software - modernize tech and alignment to domain model for code that is easier to understand and evolve.
- Domain model (conceptual) - modernize the conceptual domain model, creating a better shared understanding and language improving collaboration & innovation
- Domain - modernize the domain by adding new and better capabilities which create new business and customer value.

Дальше речь идет про инструменты:
1) Активное слушание - оно помогает понять бизнес-цели и проблемы заинтересованных сторон
2) Impact mapping - в этом подходе создается связка: strategic business objectives - actor - impact - deliverables. Подробнее можно почитать в книге "Impact mapping", про которую я писал раньше
3) Wardley mapping - здесь компоненты архитектуры связаны с цепочкой создания ценности, а также стадиями жизненного цикла продукта. Интересная концепция, про которую я узнал впервые и которую можно использовать для определения текущего состояния и эволюции компонентов архитектуры.
4) Event storming - это интересный подход lkz проведения воркшопов для коллаборативного изучения сложного бизнес домена ... Подробнее можно прочитать в моем посте
5) Modernization strategy selector - график для обсуждения вариантов модернизации через раскладывание по осям platform modernization и product, domain, software modernization
В конце перечисления автор еще вспоминает CodeScene - инструмент для поведенческого анализа кода.

Дальше автор рассказывает, а с чего стоит начать модернизацию и показывает матрицу 2x2 (риски - эффект). В итоге, у нас есть
1) "низковисящие фрукты" (риск небольшой, а эффект значительный)
2) проекты, для тех, кто уклоняется от риска (риск и эффекты незначительные)
3) проекты, для тех, кто готов к большим ставкам (риски и эффекты большие)
4) "последняя паста в тюбике" (рисковые проекты с низким эффектом) - такими часто вообще не занимаются никогда:)

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

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment

Dune (Дюна)

Побывал на прошлой недели на второй части фильма, что снял Дени Вильнёв. Фильм мне понравился своими визуальными эффектами, где планета Арракис выглядит как настоящая, актеры отлично отыгрывают персонажей, в кадре есть динамика и развитие событий. Но если бы я не знал первоисточник в виде книг Фрэнка Герберта, то мне было бы сложно понимать все хитросплетения происходящих событий. Поэтому я рекомендую помимо просмотра фильма почитать и книги:
- Дюна - первая книга цикла, которая получила премию Хьюго в 1966 и в этом же году премию Небьюла. По этой книге сняты первые две части фильма Дени Вильнёва
- Мессия Дюны - предположительно эта книга будет основой сюжета для третьей части фильма (если он будет)
- Дети Дюны и остальные книги цикла - я эти книги в детстве прочесть уже не успел, но если Дени продолжит снимать Дюну, то придется ознакомиться с этим текстами

P.S.
Ну и рекомендую сходить на Дюну в кино, так как этот фильм стоит того, чтобы увидеть его на больших экранах:)

#SciFi

Code of leadership #11 - Интервью про системных аналитиков в Тинькофф

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

- Информация про системных аналитиков в Тинькофф доступна здесь
- Информация про приближающийся one day offer системных аналитиков в Тинькофф доступна здесь

Список рекомендованных Кириллом книг:
- Ричардс М. , Форд Н. "Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы"
- Форд Н. , Ричардс М. , Садаладж П., Дехгани Ж. "Современный подход к программной архитектуре: сложные компромиссы"
- Ousterhout, John. "A Philosophy of Software Design"
- Влад Хононов. Изучаем DDD

Интересно, что все эти книги мы разбирали в подкасте Code of Architecture
- Обзор книги "Fundamentals of Software Architecture"
- Code of Architecture — Recap of "Software Architecture: The Hard Parts"
- Книжный клуб CoA — "A Philosophy of Software Design"
- Изучаем DDD – предметно-ориентированное проектирование

Отдельно отмечу, что я уже рассказывал про варианты развития аналитиков в своем докладе раньше.

P.S.
Подкаст доступен в аудиоверсии на Я.Музыке.

#Career #SystemDesign #Software #SoftwareArchitecture #Architecture #Engineering #Analyst

Ex-technology companies

Интересный пост от Will Larson, который поднимает вопрос, а каким критериям должна удовлетворять компания, чтобы считаться технологической. И что бывает с компанией, когда она перестает удовлетворять этим критериям. Will Larson выделяет два критерия:
- Предельная стоимость обслуживания дополнительного пользователя стремится к нулю - тут отсылка к статье Ben Thompson’s “Software has zero marginal costs”. Если это так, то рост пользовательской базы позволяет большие косты в перспективе распределить по большой пользовательской базе и получить хорошую маржинальность. Если инвесторы верят в эту оценку предельной стоимости обслуживания, то они оценивают компанию в 2-3 раза выше, чем нетехнологическую:)
- Инженеры влият на стратегические решения компании - здесь автор отсылает к мнению Camille Fournier, которая написала крутую книгу "The Manager's Path", про которую я рассказывал в четырех частях: pre-manager, engineering managers, engineering directors и senior leaders. Отдельно на эту тему рекомендую почитать книгу "A Seat at the Table", про которую я рассказывал раньше
Я согласен с мнением Will и тоже считаю, что эти два критерия достаточно точно разделяют tech и non-tech компании.

Ну а дальше в статье автор рассказывает про то, как меняется характер работы в компаниях, которые перестают быть технологическими. Это может быть из-за разных, например
- если инвесторы перестают верить в оценку предельной стоимости обслуживания клиентов и делают переоценку стоимости компании вместо 10xот revenue до 2x от revenue
- если технологические лидеры теряют место за столом топов и к власти приходят условные финансисты, что просто срезают траты на RnD и технологическое развитие, что приводит к тому, что косты на поддержку и развитие IDP (internal developer platform) до неподъемным для команд, которые подверглись сокращениям
А дальше автор вспоминает свой опыт работы в Digg, где acquihire привело к сокращению инженерных команд и тому, что старая инфра и архитектура, рассчитанная на 50 инженеров перестала соответствовать тому, что нужно было для оставшегося десятка инженеров.

В итоге, автор предлагает такой способ определения того, а не стала ли перешла ли ваша компания в экс-технологическый этап своего развития

Ask yourself is whether R&D at your company can significantly change your company’s financial profile over the next three years

Если ответ да, то значит вы еще в игре и ваша компания все еще технологическая:) Даже если у компании сейчас сложный момент, то за счет технологий она может выйти из него.
Ну и если подвести итоги, то в технологических компаниях технологии - это драйвер роста, а в нетехнологических компаниях - это центр затрат:)

P.S.
Отдельно отмечу, что у нас был крутой новогодний выпуск, где мы обсуждали гибридный подход к RnD и гостями были
- Игорь Маслов, руководитель управления базовых технологий и обработки данных Тинькофф
- Станислав Моисеев, директор инженерных исследований в Тинькофф
А также я в прошлом году рассказывал доклад "Как RnD появляется в крупных IТ-компаниях" на Techlead Conf.

#Management #Leadership #Engineering #RnD

Яндекс.Дзен. Как создать свой блог и сделать его популярным

Вчера решил почитать книгу от Анны Денисовой про то, как вести блог на Дзене (книга была написана еще в те времена, когда он принадлежал Яндексу).
Не скажу, что я узнал что-то новое про создание блога, но не могу не отметить хорошую структуру книги
- Введение - обсуждение мотивации становления блоггером (и заодно темы монетизации)
- Обсуждение концепции блога - обсуждение целевой аудитории и темы, о которой автор сможет писать тексты
- Форматы Дзена, которые доступны для публикации - статьи, видео, истории, etc
- Создание контент плана по выпуску материалов - план того, что и когда вы опубликуете в своем блоге
- Написание статьи - здесь автор говорит про тему статьи и ее небанальность, структуру, яркость, call to action в статье и так далее
- Подготовка статьи к публикации - здесь обсуждается оформление статьи - создание заголовков, краткого описания, изображения для обложки, выставления тегов и т.д.
- Создание иллюстраций для статей - базовый рассказ про поиск фотографий, снять самому, а также адаптировать их в статье
- Съемка видео - похожие советы как те, что были для фото
- Статистика - как проанализировать метрики вашего блога через интерфейс редактора и используя данные Метрики
- Монетизация - рассказ о том, как начать зарабатывать на блоге
- Повышение популярности блога - здесь речь про программу поддежки авторов, продвижение статьи, коллаборации с другими авторами и т.д.
- Психология блогерства - автор разбирает стандартные проблемы: хейтеров, неудовлетворенность заработком, непредсказуемость показателей, выгорание и обманутые ожидания в том, что быть блогером легко
- Полезные материалы - здесь автор дает ссылки на полезные для блогеров сервисы, а также делится чеклистами: чеклист хорошей статьи, рекламной статьи, плана развития нового канала

В общем, мне показалась, что книга может быть полезна начинающим авторам, но если вы уже ведете блог, то вы не узнаете много нововго.

#Writing #SelfDevelopment

ЦЕХ 4 - Урок #2 "Целевая аудитория и ее потребности в создании книги. Эксперт — Ольга Архипова"

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

Ниже основные моменты, что я вынес с этого урока
1) Целевая аудитория - это люди с определенными характеристиками, которые могут быть заинтересованы в книге. При создании книги стоит думать про них, чтобы точнее откалибровать наши желания о том, что мы хотим рассказать и потребности аудитории, которые возможно захотят прочитать нашу книгу.
2) Критерии для определения аудитории - можно рассматривать разные факторы, например, стиль жизни, ценности, восприимчивость к цене, скорость чтения книг, доступность информации о продукте. Это влияет на параметры книги: оформление обложки, качества текста и бумаги, доступности ее в книжных магазинах и маркетплейсах
3) Сегментация аудитории - нам важно сегментировать аудиторию, чтобы понимать широту сегмента (потенциальный спрос на книгу), а также то, какие ожидания у этого сегмента. Причем мы можем смотреть на параметры, характерные для группы покупателей (возраст, пол, семья, статус, стиль жизни) и параметры, основанные на искомых выгодах. Для оценок параметров аудитории мы можем использовать разные источники: статистику по населению РФ, данные по книжному рынку, ...
4) Сегментация с использование эмоциональных, функциональных, истинных потребностей - более глубокий подход к сегментации, где мы идем от
— Эмоциональных потребностей: положительных (радость, счастье, вдохновение, мотивация) и отрицательных (обида, страх, вина, стыд, подавленность)
— Функциональных потребностей, например, изучение нового языка, чтение для саморазвития, прокачка навыков или даже книги как предмета интерьера
5) Книжная пирамида по уровням потребностей - ее можно разложить на три уровня: низ, середина и верх. Внизу пирамиды находятся книги с простыми названиями и простым содержанием, в середине - более специализированные книги, а вверху - узкоспециализированные книги для специалистов. Это пересекается с пирамидой Маслоу. Используя эту пирамиду, можно описать потребителей
— Низ пирамиды: потребители, которые мечтают научиться чему-то, но не готовы долго концентрироваться на контенте.
— Середина пирамиды: читатели, которые уже что-то приобрели и хотят развиваться в определенной области.
— Верх пирамиды: читатели, которые уже прокачались и готовы платить больше за уникальный контент.
6) Упаковка книги для каждого уровня - каждый уровень требует собственной обложки: для низа пирамиды нужны яркие, выделяющиеся обложки, простые названия, для середины - более сложные названия, метафоры, образы, а для верха - профессиональные названия, сложные названия, метафоры.
7) Пирамида для художественной литературы - в художественной литературе также есть пирамида потребностей, но она определяется жанром и построением сюжета. Но основная цель все-таки быть понятной для целевой аудитории, а также выделяться на фоне конкурентов. В художественной литературе читатель примеряет себя к описанным ситуациям, узнает себя в них, а дальше безопасно их переживает.
8) Глубинные потребности читателей - эксперт описывает как хороший консультант может постараться глубинную потребность покупателя, не удовлетворившись дежурным ответом. Интересно, что меня, например, консультанты в книжных обычно только раздражают:)
9) Зачем думать про ЦА и маркетинг до написания книги - для того, чтобы написать хорошую книгу хорошо бы понимать для кого мы ее пишем и насколько она подходит этой ЦА. Конечно можно сначала написать книгу, а потом думать кому она нужна, но это может привести к грустному ответу, что "никому":)
10) Маркетинг, воронка продаж, медиаплан - эксперт рассказывает базовую историю про маркетинг, которую можно почерпнуть изучив марткениг микс (4P): product, price, place (distribution) и promotion

#Writing #SelfDevelopment #Management

Обучение детей программированию

Недавно обсуждал тему обучения детей программированию и решил вспомнить как я к этому подходил со своим старшим сыном Пашей, который так и не стал программистом, а решил пойти в геймдизайн:) Собственно, я лет 10 назад ориентировался на такие проекты как Scratch и Lego Mindstorm
— Scratch - это проект MIT, который представляет собой визуальный язык программирования и web IDE для разработки. Это очень крутая история, которая позволяет малышами проявить свой креатив и буквально сразу делать интересные проекты:) Идейный вдохновитель проекта, Митчел Резник, написал отличную книгу "Спираль обучения" ("Lifelong kindergarten"), в которой он рассказывает про развитие подходов к креативности и встраивание их в цикл обучения. У меня есть краткое саммари этой книги. Мой сын пробовал собирать проекты в этом IDE, используя пару книг, что есть на Озоне, но ему это особо не заходило, поэтому он бросил (тут есть отчасти моя "заслуга", так как я с этим не сильно помогал)
— Lego Mindstorm - это крутой проект от Lego, где до появления всяких "малинок" (raspberry pi и иже с ними) ребенок мог попробовать робототехнику в привычном формате с кубиками лего, центральным блоком с процессором и кучей входов для подключения датчиков, моторов и остальной машинерии. В итоге, малыш мог собрать своего робота, научить его видеть, подключив сенсор с камерой, чувствовать, подключив датчик касания, добавить ему чувство равновесия за счет датчика с гироскопом и так далее. В эту штуку мой сын играл с удовольствием, но только до момента окончания сбора робота, а вот писать софт для него и программировать в IDE аля Scratch ему не нравилось и он подключал папу.

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

P.S.
На тему игр и геймдизайна у меня уже были раньше посты
— The Making of Prince of Persia
- Геймдзайн (Designing games. A guide to engineering experiences)
- Minecraft: Мобиология (Minecraft: Mobestiary)
- Кровь, пот и пиксели (Blood, sweat and pixels)
- Настольная игра "Нефариус"
- Настольная игра "Корпорация Гоблинов" (Goblins Inc)
- Прогейминг, Overwatch, киберспорт (Young guns: obsession, owerwatch, and the future of gaming)
- Мастера Геймдизайна (Game Designer Confessions: Insights from Finland's Top Game Designers)
- Мальчик, сделанный из кубиков (A Boy Made of Blocks)
- Настольня игра "Бумунту"
- Документальный фильм про AlphaGo
- Настольная игра "Ужасы Аркхэма"

P.P.S.
А кто и как сейчас обучает своих детей программированию, особенно учитывая, что Lego Mindstorm прекратили выпускать? Поделитесь своими подходами в комментариях.

#Software #Education #GameDesign #SelfDevelopment

Tools and practices to help you deal with legacy code - Dennis Doomen - NDC Porto 2023

Интересно выступление на тему работу с наследием прошлого или, проще говоря. легаси кодом. В этом выступлении автор приводит алгоритм своих действий в качестве консультанта, которого зовут для занятий археологий вокруг legacy систем. Алгоритм мне показался интересным, поэтому я решил расписать его кратко
- Деннис начинает с анализа прода, включая изучение запущенных процессов и их конфигурации.
- Дальше он изучает код и его структуру и ищет проблемы - обычно именно эти проблемы мешают клиенту и он призывает решить их Денниса
- Деннис сравнивает код с системой управления версиями и ищет закомментированные или измененные части кода
- Он изучает log файлы, а также отчеты о сбоях и уже найденные проблемы
- Дальше Денис занимается exploratory testing и пробует воспроизвести проблемы, о которых сообщали клиенты.
- При изучении кода автор обращает внимание на пространства имен, подходы к неймингу классов и функций, а также создает ментальные карты и визуализирует зависимости между частями проекта
- Автор отмечает, что сейчас появились AI инструменты, которые можно просить объяснить логику того или иного куска кода
- Для улучшения кодовой базы стоит удалять куски неиспользуемого кода - если они понядобятся, то мы сможем их восстановить из системы контроля версий
- Перед внесением изменения в код автор создает safety nets, создавая высокоуровневые тесты, которые позволяют отследить изменения в поведении программы. Тут автор рекомендует книгу "Working Effectively with Legacy Code" от Michael Feathers
- Дальше автор работает над автоматизацией сборки и развертывания программы, чтобы не делать это руками, а сделать нормальный CI/CD пайплайн. Тут автор рекомендует Ansible или Pulumi
- Отдельно автор говорит про стратегии ветвления и версионирования программы (semver)
- Также надо выстроить работу с исключениями, сделать нормальное логгирование с уровнями и использовать open telemetry для трейсинга
- Следующий шаг - это использование статического анализатора кода, в .net автор рекомендует Roslyn
- Дальше автор отформатировать код в единый стиль и применить это изменение одним коммитом, а дальше настроить линтеры и поддерживать этот стиль:)
- Автор топит за то, чтобы даже на старых платформах использовать новые возможности языка, используя аналог polyfills из js, но для .net платформы
- Дальше автор говорит про реструктуризацию кода и перенос связных частей в отдельные функциональные папки, отдельно он предлагает дублировать код для снижения coupling разных частей кода (это позволяет оставить меньше связей, хоть и в угоду дублированию)
- Важная часть посвящена применению шаблонов проектирования при рефакторинге старого кода - автор считает их полезными идиомами, которые позволяют снизить сложность старого кода за счет использования знакомых концепций
- Дальше автор вспоминает SOLID и отдельно упоминает про последнюю концепцию с DIP (dependency inversion principle), которая помогает нам организовать зависимости между частями нашего legacy приложения. Автор говорит о том, что зависимости надо оставлять от более абстрактных и стабильных компонентов и если требуется выделять зависимость в интерфейс и использовать инверсию. Тут же автор вспоминает про композицию и наследования и объясняет почему он предпочитает первое второму
- Ну и финал выступления посвящен вопросам архитектуры, где автор вспоминает про onion architecture, hexagonal architecture, clean architecture и говорит, что они решают определенные классы проблем:) То есть выбирать архитектуру надо от того, какие проблемы мы хотим решить

В итоге, у автора получился хороший рассказ о том, что надо сделать, чтобы ваше наследие (legacy app) засияло новыми красками:)

#Software #Architecture #SoftwareDevelopment

Предсказуемая иррациональность (Predictably Irrational. The Hidden Forces That Shape Our Decisions) (Part I)

В эти выходные я прочитал книгу Дэна Ариели (Dan Ariely), которая посвящена нашему процессу принятия решений. Эта книга предсказуемо оказалась превосходной, так как большую часть материала я уже видел, когда проходил 10 лет назад его курс "A Beginner's Guide to Irrational Behavior" на edx.org. Также у Дэна было крутое выступление на TED "Are we in control of our own decisions?" 15 лет назад, сразу после первого издания этой книги "Predictably Irrational".
Теперь я расскажу про содержание книги, где в каждой главе автор рассказывает про важный вопрос и описывает те эксперименты, что он проводил вместе с коллегами для исследования поведения людей
0. Как несчастный случай привел меня к исследованиям иррациональности, описанным в этой книге - Дэн рассказывает как в 18 лет он получил обширные ожоги тела и дальше несколько лет пролежал в больнице, пытаясь восстановить свой кожный покров. Там он начал задумываться о причинах того или иного поведения, а также заинтересовался подходами к лечению пациентов с сильной болью.
1. Правда об относительности - автор рассказывает о том, что мы умеем принимать решения сравнивая опции между собой. Здесь описываются эксперименты с выбором из вариантов А и Б, которые выбирают с примерно одинаковой частотой. Но если добавить к выбору ухудшенный вариант А, то обычный вариант А станет лидером, так как на фоне ухудшенного А он будет смотреться выигрышно. Например, так девушка может позвать с собой менее красивую подругу в бар, чтобы на ее фоне смотреться более выигрышно:)
2. Недостатки модели спроса и предложения - автор рассказывает про эффект прайминга, когда мы при принятии решений привязываемся к первоначальной информации (например, о цене) и дальше начинаем принимать решения относительно него. Похожая история есть с гусятами, которые привязываются к первому взрослому, которого увидели в своей жизни. Интересно, что в этой главе автор говорит про то, что стоило бы вести журнал принятых решений и иногда возвращаться к ним, чтобы оценивать насколько они еще актуальны. Это напрямую напоминает процесс RFC/ADR, где мы фиксируем принятые решения и можем возвращаться к ним в будущем
3. Чего стоят нулевые издержки - история про магическую притягательность "бесплатных" предложений. Подзаголовок этой главы "Почему, не платя ничего, мы платим слишком много" отлично отражает содержимое главы. Здесь автор рассказывает про боль потери (когда мы платим за что-то), а мы не любим испытывать эти эмоции. Используя эту концепцию, он объясняет почему прикольно платить за ресторан по очереди, если вы ходите в него со своими друзьями:)
4. Цена социальных норм - глава на тему социальных и экономических норм и того, что они не совместимы между собой. Например, если вы попросите знакомого помочь вам по мелочи, то он вероятно согласится из-за социальных норм и ваших хороших отношений. А если вы предложите ему за это 100 рублей, то он откажется и оскорбится (оценив стоимость своего времени и считая, что вы предложили слишком мало). Этому вопросу посвящена книга-комикс "Умные решения" ("Amazing decisions"), про которую я рассказывал
5. Сила бесплатного печенья - здесь автор рассказывает о том, что если вы принесете на работу печенье и будете предлагать его бесплатно, то люди будут скромно угощаться печеньем. А вот если вы назначите за него небольшую цену, то скромность сразу исчезнет. Вы сразу перейдете из плоскости социальных норм в мир рыночных отношений:)
6. Влияние возбуждения - рассказ о том, что в рациональном состоянии мы не можем точно предсказать как будем себя вести при переходе в эмоциональное состояние. Результаты эксперимента показали, что моральные нормы могут сильно сдвигаться в возбужденном состоянии

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

#Psychology #Economics #Brain #SelfDevelopment

Code of Leadership #12 - Интервью про платформу Spirit (Internal developer platform) в Тинькофф

В двенадцатом выпуске подкаста я общаюсь с Димой Гаевским, Technical CPO (Chief Product Owner) нашей внутренней платформы разработки Spirit. Дима рассказывает про свой путь в Тинькофф, немного про разработку и много про создание и развитие платформенных решений. ЗА 45 минут мы успели поговорить про
- Путь Димы в компании
- Платформу для разработчиков (internal developer platform)
- Декомпозицию ответственности
- Роль инженера
- Распределение времени и восприятие работы
- Продуктовые практики и обратная связь
- Роль технического продакт менеджера
- Принципы развития платформы разаработки (IDP)
- Рекомендации для инженеров и технических руководителей

P.S.
У Димы есть прикольная статья про IDP на Хабре по мотивам выступления на Highload++ 2022. Плюс подробнее про платформу можно почитать на нашем сайте. Ну и для тех, кто заинтересовался этой историей, у Димы есть вакансия technical product manager, про которую я писал уже раньше.

#ProductManagement #Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes