Книжный куб

The Most Powerful Software Development Process Is The Easiest • Dave Farley • GOTO 2024 Это короткое видео Дэйва Фарли посвящено дизайну идеального процесса разработки софта. Интересно, что сам Дейв - тертый калач, который в давние времена написал книгу Continuous Delivery (я про нее рассказывал), а недавно - "Modern Software Engineering: Doing What Works to Build Better Software Faster", которая стоит у меня на полке и ждет своего часа. В этом видео Дэйв предлагает отринуть текущие практики и попробовать придумать процесс разработки софта from the first principle. В конце он предлагает модель идеального процесса, как видится ему. Интересно, что этот процесс позволяет размышлять не просто про идеал, а про вашу конкретную ситуацию и понять что не так с вашим процессом или вспоминая Льва Толстого понять в чем ваше несчастье:)

Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по своему

Ну а теперь кратко про мысли Дэйва - Фиксирует цели разработки софта как решение проблем других при помощи софта. Для этого надо: -- Понять проблему - отсюда появляются requirements -- Решить проблему - тут мы пока пишем код, но некоторые говорят, что скоро будет писать только промпты -- Проверить, что она решена - отсюда появляются тесты - Так как мир вокруг изменчив, то нам надо уметь меняться - меняются требования и нам надо уметь делать изменения - отсюда появляется желание двигаться вперед маленькими шагами - Нам надо понимать, что мы двигаемся в нужную сторону, поэтому нам надо верифицировать результаты и разрабатывать софт инкрементально - Одновременно нам нужно, чтобы наша система работала с первой версии и на протяжении всех инкрементальных изменений - она же решает задачи пользователей, как мы определились в самом начале (а для этого она должна быть up & running) Дальше автор показывает процесс: - Смутное желание от бизнеса - User story, где важно выразить потребности пользователя, а не конкретное решение - Тут же важно привести примеры (из которых можно сделать test cases) - А дальше уже идет design & implement часть, которую автор описывает подробнее -- Про commit stage, упоминая continuous integration - на этой фазе проверяется техническая корректность изменений -- Про acceptance stage - на этой стадии идут проверки, а можно ли релизить это изменение: acceptance test, security, performance, etc Ну и заканчивает автор на высокой ноте, говоря, что такой процесс используется во многих tech компаниях по всему миру и дает хорошие результаты. Собственно это финальное утверждение коррелирует с кликбейтной обложкой, которая хорошо привлекает внимание, но почти не упоминается по всему видео:) P.S. В общем, в этом видео нет ничего нового, но оно краткое, понятное и дает хорошую базовую модель процессов разработки. #Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE

Живая раскраска Смешарики. Развиваем интеллект В этой книге от Devar авторы взяли мотивы фильма "Трон" 1982 года выпуска и перенесли их в мир Смешариков. В самом начале книги Кар-Карыч забыл пароль от свеого компьютера, но ему на помощь приходит Ежик. Ежик вводит пароль, а дальше его засасывает в компьютерную игру с кучей задачек в дополненной реальности. Детям предстоит помочь Ежику разгадать загадки, победить в логических играх и не только. Антураж меняется на каждой страничке - Смешарики то превращаются в пиратов, то в космонатов, то футболистов, то в ведьм и колдунов. Я купил эту игру достаточно давно, но теперь моей трехлетний Кирюша с большим удовольствием решает эти задачки и играет в игрушки. Но вот раскрашивать Смешариков он не стал, поэтому все персонажи преимущественно черно-белые. #ForKids #ForParents

Алгоритмы: построение и анализ (Introduction to Algorithms) Я купил этот кирпич за авторством Кормена, Лейзерсона и Ривеста еще в 2002 году, когда думал, что смогу стать мастером в алгоритмах. Это было еще первое издание книги с белой обложкой и тогда соавторов было еще трое. Мне тогда нравилось изучать эту книгу, но на первых курсах университета у меня еще не было личного компьютера, поэтому приходилось писать псевдокод на листочке и дебажить в голове. Такая схема работы не слишком помогала в изучении computer science, но основы вроде бы я тогда уловил (заодно понял, что в этой области я звезд с неба не хватаю:) иначе бы и в голове мог все это отрешивать без компа). А когда я на третьем курсе уже пошел работать, то времени и желания ботать дальше алгоритмы уже не было - я был занят изучением самих языков и инструментов, что помогали мне решать практические задачи из области веб разработки. Прошло много лет и теперь можно вернуться к книге, а алгозадачи решать не в голове, а на leetcode:) Структура книги достаточно логичная и состоит из следующих частей 1) Математические основы анализа алгоритмов - скорость роста функций (нотация O(n)), рекурентные соотношения, множества, комбинаторика и вероятность 2) Сортировка и порядковые статистики - сортировка с помощью кучи, quick sort, медианы и порядковые статистики 3) Структуры данных - стеки, очереди, связанные списки, хеш-таблицы, деревья 4) Методы построения и анализа алгоритмов - динамическое программирование, жадные алгоритмы 5) Более сложные структуры данных - b-tree, биномиальные кучи, фиобаначчиевы кучи, системы непересекающихся множеств 6) Алгоритмы на графах - поиск в ширину и глубину, минимальные покрывающие деревья, кратчайшие пути, максимальный поток 7) Дополнительные главы - матрицы, быстрое преобразование Фурье, NP-полнота и многое другое В общем, фундаментальная книга с крутыми темами и устрашающими размерами:) Кстати, а стоит заказывать четвертое издание книги, если у меня уже есть первое? #Software #Algorithm #Engineering #SelfDevelopment

GraphQL: The Documentary Полтора года назад я посмотрел эту документалку в рамках изучения whitepaper "Continuous Deployment of Mobile Software at Fb (Showcase)", на которую я написал краткое саммари в своем блоге. Если кратко суммировать, то где-то до 2012 компания, что создала GraphQL шла в сторону веба в мобилке, но стало ясно, что HTML5 в мобиле тогда не работал. Дальше они решили переобуться на нативную разработку и стало ясно, что старые APIшки не очень помогают в разработке нативных приложений. Дальше вместо проектирования API ребята изобрели свой способ через выставление query language прямо в потребителей и назвали это GraphQL. Несмотря на мое отношение к GraphQL рекомендую глянуть эту документалку и понять откуда растут ноги у этого подхода. Кстати, я уже рассказывал про другие документалки - How A Small Team of Developers Created React at Facebook | React.js: The Documentary - Ruby on Rails: The Documentary - Inside Envoy: The Proxy for the Future [OFFICIAL FILM] - eBPF Documentary: eBPF’s Creation Story – Unlocking The Kernel - AlphaGo - The Movie - Kubernetes: The Documentary #Software #Documentary #Engineering #Architecture #Management #SoftwareDevelopment

Тренды геймификации - эфир South HUB Меня достаточно часто зовут пообщаться и что-то пообсуждать. И я особенно люблю, когда я могу прийти не сам, а посоветовать кого-то более релевантного из моих коллег. И с этим эфиром на South Hub про геймификацию так и получилось - я порекомендовал позвать моего коллегу, Вадима Гончарова, который руководит разработкой игр и спецпроектов. Кстати, Вадим недавно на YaTalks рассказывал про то, как ребята делали игру "Ряд наград". Кстати, отдел Вадима теперь входит в управление разработки соцплатформ, про чью вакансию SRE лида я писал недавно. В эфире будут участвовать - Кирилл Буртный - СТО Х5 Tech, модератор дискуссии и январский соведущий канала South Hub. - Вадим Гончаров, руководитель разработки спецпроектов и игр в Тинькофф. - Антон Лямин, руководитель продукта опыта покупателей Авито. - Олег Афанасьев, CPO RuStore | VK. Обсуждать эти замечательные люди будут следующие вопросы - Совместимы ли игры и большие корпорации? - Что такое игровые механики, где сейчас их применяют и для чего? - Какие выгоды они приносят при работе с клиентами и сотрудниками? - Стоит ли вкладывать в геймификацию и к каким эффектам она приводит? - Какое будущее у геймификации: чего хочет рынок? #Software #GameDesign #Engineering

Code of Leadership - Episode ? - Антихрупкость в IT от Саши Бындю Я подумал, что в рамках моего подкаста было бы интересно не просто звать гостей и обсуждать их любимые книги. Круто иногда звать и самих авторов книг и обсуждать их творчество вместе с ними. Именно такую серию мы запишем с Сашей Бындю на следующей неделе по книге "Антихрупкость в IT". Договориться получилось достаточно легко - Мы с Сашей уже были знакомы где-то с 2019 года, когда он выступал на ArchDays 2019 года с докладом про Inner source (я в ПК этой конференции с самого начала) - Саша с большим интересом делится своим подходом к антихрупкости (он рассказывал про это на Codefest 2023) - Я недавно прочитал его книгу и уже рассказл про нее раньше - Когда я предложил Саше прийти в гости, то он легко согласился, а также написал небольшой ответ на мой обзор - Когда мы обсуждали план на выпуск, то поняли, что интересно будет поговорить про "карты гипотез", продуктовый и проектный подход, работу в модели заказчик/исполнитель или внутри организации, архитектурные вопросы и так далее В общем, думаю, что выпуск будет интересным и мы сможем круто погрузиться в мысли Саши, что он изложил в своих книгах. #Management #Software #Architecture #Processes #Project #ProductManagement #Engineering #Processes #Consulting

Leetcode - прогресс за первый месяц Я уже рассказывал как купил себе на ДР Premium подписку на LeetCode и парочку курсов оттуда ("Data Structures and Algorithms" и "System Design for Interviews and Beyond"). А теперь пришло время отчитаться за этот месяц: - Оказалось, что руки забыли примерно одинаково как писать на всех языках, поэтому я решил вспоминать Python для алгоритмических задач - После того, как я вспомнил синтаксис python и чуток набил руку, то easy задачки я cnfk решаnm обычно за 5-10 минут, а вот задачки уровня medium идут у меня с переменным успехом (и пока они скорее побеждают) - У нас в компании есть чатик любителей leetcode, которые решают Daily Challenge вместе и обсуждают задачки - я туда тоже записался, но отрешла только около половины ежедневных задачек - Зато SQL у меня как будто не забывался - тут в среднем easy задачки идут за пару минут, medium обычно минут 5 и даже hard задачки рещаются относительно просто (правда, сегодня ночью решал порядка часа последнюю hard задачку из набора "Advanced SQL 50") В общем, leetcode пока мне нравится - я системно им занимаюсь каждый день утром как проснусь и вечером перед сном и кажется, что руки и голова потихоньку вспоминает про алгоритмы:) Теперь я могу не только про них рассказывать, но и даже что-то написать:) Ну и для иллюстрации добавлю скриншот с визуализацией из своего личного кабинета, по которому я оцениваю свой прогресс. P.S. Купленные курсы я пока не прошел (и даже особо не начинал), но планирую в феврале их заботать. Особенно интересно будет изучить system design курс. #SelfDevelopment #Algorithm #Software #SoftwareDevelopment

Профсообщества в больших компаниях Появилась запись встречи канала "безвотэтоговсего" про профессиональные сообщества в Росбанке, где я дискутировал на прошлой неделе. Во встрече помимо меня участвовали следующие замечательные люди: - Сергей Щербинин, автор канала "безвотэтоговсего" и организатор встречи - Паша Соломин, лидер разработки и сопровождения СБОЛ - Саша Денисов, Директор департамента ит поддержки пользователей и клиентов цифровых сервисов Росбанка - Макс Морозов, СЕО Астон В дискуссии мы обсуждали много вопросов и вот несколько из них - Как и зачем корпорации строят профсообщества и как они измеряют их эффективность? - Как выстраивать лидеронезависимые сообщества? - Как вовлекать в них людей, пробуждая интерес, а не выставляя ненужные KPI? Если суммировать мою точку зрения на основе опыта Тинькофф, то у нас проффсообщества логично называются профессиями и выстроены примерно так - У профессий есть свои лидеры, что исполняют эту роль, совмещая с участием в продуктах/проектах - Професии являются точкой синхронизации людей, объединенных вокруг чего-то общего: профессии (продакт менеджер, системный аналитик, qa-инженер, разработчик), языка разработки в случае разработчиков(golang, kotlin/java/.net, etc), функции (архитектура, процессы разработки) и так далее - У каждой профессии есть ее лидеры, которые ее развивают как во всей организации, так и внутри крупных подразделений - Лидеры профессий помогают определять ожидания от специалистов, которые входят в определенную профессию - это так называемые матрицы компетенций - Лидеры профессий участвуют в рассмотрении заявок на повышение, что идут через наш процесс Т-Рост, про который я рассказывал в своей статье - Лидеры профессий помогают улучшать найм сотрудников в рамках своей профессии (это наши стримы найма, например я когда-то курировал и рассказывал про system design и troubleshooting) - В рамках профессии вырабатываются стандарты и часто реализовывается общий инструментарий, который помогает всем в рамках профессии быть эффективным - Также лидеры профессий часто ведут публичную деятельность по освещению своей профессии как внутри, так и снаружи компании (aka devrel) Для меня концепция профессии звучит классно и позитивно, но возникает вопрос а почему не выделить это в отдельную должность? Ответ в том, что при выделении сотрудников на fulltime мы получаем сломанную ситуацию, когда крутой представитель профессии постепенно теряет - Экспертизу в ней, так как перестает работать руками - Связь с землей и уходит в абстракции, так как перестает работать руками В итоге, лидер профессии вынужден сидеть на двух стульях. Но тогда возникает вопрос, а зачем ему это делать? Ответ в том, что это улучшает карму сотрудника и повышает вероятность успешного повышения в рамках процесса Т-Рост, причем для высоких грейдов это становится необходимым, но недостаточным критерием:) #Management #Leadership #Engineering #Staff #Software #Devrel

Java Weekend Offer @ Tinkoff Мы в Тинькофф периодически проводим мероприятия, на которых устроиться на работу к нам можно за выходные. Очередное такое мероприятие пройдет в эти выходные (3-4 февраля) и 17-18 февраля. В рамках таких мероприятий обычно несколько команд приносят свои вакансии и преимущественно проводят интервью. В этот раз там есть ребята из моего юнита, что развивают Маркетинговую платформу. Эта платформа представляет из себя набор продуктов, с помощью которых мы связываемся с клиентами по множеству маркетинговых каналов. Каждый клиент банка — наш пользователь. Платформа работает по сценариям, которые создают контент-менеджеры. Она совершает более 100 млн действий ежедневно: рассылает пользователям пуш-уведомления и СМС, начисляет бонусы, запускает многоходовые маркетинговые акции и геймификацию. Для того, чтобы дойти до фит-интервью с командами (и выбрать вакансию маркетинговой платформы) надо пройти 3 секции интервью - Языковая секция, где будет обсуждаться платформа, фреймворки, с которыми вы работали, и теоретические вопросы, а также будет ревью кода - Алгоритмы и структуры данных, где будет пара алгоритмических задач, чтобы оценить навык написания кода (эти навыки можно тренировать на leetcode, который и я использую, чтобы поддерживать себя в форме) - System Design (для уровня senior), где надо будет спроектировать распределенную систему (вот мой пост про это интервью) В общем, если вам интересно прийти работать к нам, то регистрируйтесь на лендинге и с вами свяжутся. #SoftwareDevelopment #Software #Vacancy #Engineering

Programmer’s Apprentice Season 2: Future Directions in AI-assisted Coding • Erik Meijer • YOW! 2023 Интересное выступление про будущее разработки, в котором Erik Meijer, Director of Engineering at Facebook, делает утверждение, что мы - последнее поколение, что будет писать код руками:) И это не печалит автора доклада, скорее он рад и вдохновлен этой возможностью. Для начала автор вспоминает про то, как развивались языки программирования и про 5th generation, а потом как он ушел в создание языков программирования, а в районе 2017 года на фоне развития neural networks перешел в AI (вовремя переобулся). Дальше он говорит про - Non-monothonic logic (как ранний подход к AI) - Virtuous cycle между железом и программным обеспечением (отсылка к закону Мура) - Vicious cycle между бизнесом и программным обеспечением, где сложность бизнеса приводит к усложнению софта (что может съедать весь прирост от virtuous cycle). Для этого обычно разрабатываются software engineering tools. Но автор предлагает заменить software + software engineering tools на AI:) - Дальше автор рассказывает про whitepaper 2021 года "AI in Software Engineering at Facebook", где он выступал в качестве соавтора. Где авторы говорили про: code search using natural language, но это не очень понравилось пользователям. Дальше автор говорит про code recommendations, automated bug fixes. Для 2021 года это была крутая статья, но в 2022 году с приходом к власти LLMs она мгновенно устарела и автор показывает как эти сценарии легко выполняются с chatGPT - Дальше автор переходит к описанию того, как можно автоматизировать самих себя: -- AI-powerd typing (copilot) -- AI-powered search (chatGPT) -- AI-powered "workflows" (autoGPT) - И дальше Eric показывает как это может выглядеть для написания программ в виде взаимодействия агентов: testrun agent, bugfix agent, refactor agent. Плюс дальше идет prompt engineering - Дальше автор иронизирует над фреймворком React для фронта, а дальше рассказывает про новый React, который приведен в whitepaper "ReAct: Synergizing Reasoning and Acting in Language Models" и дальше автор вспоминает свою whitepaper из 20 века "Client-side Web Scripting with HaskellScript" - Ну и под конец автор рассказывает про видение LLM как scripting client - Финальным слайдом идет утверждение, что llm-based software is very powerful, but error-prone, brittle, insecure, hard to write, impossible to debug, expensive, privacy sensitive - И это все стоит поправить для того, чтобы перейти в новый светлый мир (где код писать будут LLMs), а для этого надо еще будет поработать инженерам:) #Management #Software #SoftwareDevelopment #LLM #AI #ML #Engineering #SystemEngineering #Architecture

Разверните ваш корабль (Turn the Ship Around!) Прочитал за пару дней эту интересную книгу, посвященную лидерству. Вся книга представляет собой историю капитанства Дэвида Марке, который рассказывает про свой подход, с помощью которого он превратил подводную лодку Santa Fe из худшей в лучшую всего за несколько лет. Дэвид описывает свой подход как переход от модели "leader - followers" к модели "leader - leaders". Для этого он выделяет три ключевые темы - Control - принятие решений и контроль за их реализацией Дэвид предлагает передавать на тот уровень, где эффективнее всего это можно сделать. Чем-то это напоминает OKR (objectives and key results), в котором сверху приходят цели, а на местах люди уже придумывают как их достигнуть и какие ключевые результаты удастся получить. В итоге, у Дэвида в модели лидерства капитан не является человеком, который рассказывает что сделать и принимает за всех решения. У него офицеры и старшины могут принимать решения в своей зоне ответственности и нести за них ответственность (понятно, что несмотря на это за все происходящее на подводной лодке все равно accountable капитан) - Competency - передача принятия решений и контроля без наличия нужных компетенций - это выстрел себе в ногу. Поэтому другой основой подхода Дэвида является повышение уровня компетенций команды. Его подход к инцидентам и работе с ними напоминает подходы SRE (site reliability engineers) и конкретно postmortems. Интересно, что Дэвид переключает команду с режима избегания ошибок на достижение операционного совершенства (operational excellence). Это фокусирует людей на непрерывном улучшении и обучении в процессе работы, вместо попыток просто "не облажаться" - Clarity - в модели "leader - leaders" очень важно, чтобы люди, принимающие решения на местах, понимали общую цель организации. Часто в бизнесе при этом говорят про vision, mission, strategy и так далее. В книге Дэвид описывает как это выглядело для сотрудников на подводной лодке:) Из интересного отмечу, что подход к лидерству Дэвида хорошо сработал в рамках военно-морского флота и многие его наработки стали через несколько лет стандартом де-факто (а где-то и де-юре). Плюс многие офицеры с лодки Santa Fe дальше успешно служили на флоте и получали повышения, так как впитали эту модель лидерства и несли ее дальше. P.S. При чтении книги можно собрать очень хороший список вопросов для размышлений, которые автор приводит в конце каждой главы. Это позволит вам оценить насколько хорошо дела идут на вашей подводной лодке:) #Management #Leadership #SelfDevelopment #Psychology #ForParents #SystemThinking #ProjectManagement

The Joy of Building Large Scale Systems • Suhail Patel • YOW! 2023 Это очень интересное выступление Suhail Patel, Senior Staff Engineer at Monzo. Оно посвящено тому, как поменялись latency numbers (смотри "Latency Numbers Every Programmer Should Know") и производительность в общем за последние годы. Важно, что эти изменения напрямую влияют на проектирование и эксплуатацию масштабных и нагруженных систем. Автор очень подробно идет по куче тем и - Рассказывает про работу b-tree+ в базах данных (интересно, что он не говорит про LSM и SSTables) - Показывает как поменялась скорость дисков: HDD (200 mbps), SDD (550 mbps), NVMe (3000 mbps) - Упоминает про изменения в CPU (да закон Мура уже не про рост мощности одного ядра, а про увеличение количества ядер) + появление ARM процессоров, что выдают больше мощности на стоимость по сравнению с x86-64 - Говорит про рост пропускной способности сети (c 1Gbps до десятков Gbps) и появление кастомных чипов типа TPU от Google (tensor processor unit) - Вспоминает давнишние предсказания о том, что несмотря на увеличение мощности компьютеров software всегда найдет куда утилизировать эти мощности (обычно в дополнительные уровни абстракций поверх уровня железа) - Разбирает подход с работой вида thread per core (сравнение shared everything arch vs shared nothing arch на уровне процессора, его ядер и доступа к памяти), тут же рассказ про выделение одного ядра на работу с сетью и как это помогает с tail latency, про Seastar, что используется в Scylla (конкурент Cassandra, но только на C++, а не Java), про io_uring, который заехал и в libuv - Рекламирует Rust как инструмент для системного программирования и показывает как его легко использовать с Python (пример с парсингом дат в промышленном масштабе) - Рассказывает про новые трюки с garbace collection, начиная с Java 17, дальше про eBPF (я рассказывал про интересную документалку об этом проекте) - Говорит про простое ускорение работы с парсингом JSON, оптимизацию загрузки весов с llama и подобные вещи при помощи понимания низкоуровневых концепций И заканчивает на высокой ноте, призывая лучше разбираться с тем, как работет железо под нашим софтом

Many of the systems (apps, services, databases, caches, queues) that we build/rely on are grounded on quite poor assumptions for the hardware of today Software can keep pace, but there’s some work needed to yield huge results, power new kinds of systems and reduce compute costs

#Software #Architecture #DistributedSystems #SystemEngineering #SystemDesign #Engineering #Devops #SRE

Груффало (The Gruffalo) Эта детская книга Джулии Дональдсон отлично подходит для детишек от 3 до 7 лет. В основе сюжета книги лежит китайская сказка о девочке и тигре: из-за того, что по следам девочки шёл тигр, она думала, что все звери боятся её, хотя на самом деле они боялись тигра. Но в этой истории главные персонажи - это мышонок и Груффало, которого изначально вроде как выдумал Мышонок, чтобы его не съели животные в лесу. Он по очереди встречает Лису, Сову и Змею и все они хотят видеть Мышонка у себя в гостях в качестве обеда. Однако Мышонок отказывается из-за назначенной встречи с Груффало, который по его описанию страшный зверь, который любит лакомиться лисами, совами и змеями. После такой отповеди собеседники Мышонка скрываются в лесу ... а потом Мышонок в чаще встречается с самим настоящим Груффало и уже его забалтывает ... а вот как именно рекомендую посмотреть в самой сказке, которая начинается так

Гулял мышонок по лесу, и вдруг лиса бежит, А у лисы, как водится, хороший аппетит. - Пойдём со мною, маленький, в нору ко мне пойдём, Мы сможем там отлично позавтракать вдвоём. - Простите, тётушка Лиса, - мышонок пропищал, - Я завтракаю с Груффало: я твёрдо обещал. - Что там ещё за груффало? Мышонок, ты о ком? - О, это очень крупный зверь, я с ним давно знаком: Есть у него клыки, и когти тоже есть, И преогромнейшая пасть, а в ней зубов не счесть. - И где же вы встречаетесь? - Да вон у той горушки. Он, кстати, очень любит лис. С приправой из петрушки. - С приправой, говоришь? Ну, мне пора домой. Прощай, мышонок! – и лиса нырнула в лес густой. - Ха, глупая лиса! Не знает ничего! Нет никакого груффало, я выдумал его.

P.S. Мне эта история напомнила похожий подход из жизни, что используется в убеждениях и называется апелляция к авторитету (argumentum ad verecundiam). Часто это выглядт так, что участник обсуждения говорит, что данную точку зрения поддерживает условный Груффало, а значит точка зрения правильная:) Но, обычно это слабая аргументация, даже если сам Груффало сильный:)) #ForKids #ForParents #Tales

Michael Gervais | The First Rule of Mastery | Talks at Google В этом интервью Michael Gervais рассказывает про свою книгу "The First Rule of Mastery", в подзаголовке которой приводится основная мысль "stop worrying about what people think of you". Michael Gervais имеет PhD по психологии и работает со спортсменами-рекордсменами и призерами олимпиад, музыкантами, CEO крупных компаний. В своей книге он дает руководство по преодолению наших страхов перед мнением других людей (fear of people’s opinions) или сокращенно FOPO. Эти страхи могут ограничивать наш потенциал и мы встречаемся с ними практически повсюду. Когда мы позволяем FOPO взять на себя управление, мы действуем очень осторожно, потому что боимся того, что встретим критику. Когда нам бросают вызов, мы отказываемся от своей точки зрения. Мы обмениваем подлинность на одобрение. Мы гонимся за мечтами других, а не за своими. В своей книге Майкл Жерве показывает нам, что ключ к продуктивной жизни — это перенаправить наше внимание с мира снаружи на мир внутри нас. Он раскрывает навыки и методы, которые нам нужны, чтобы преодолеть FOPO — те же навыки, которые он преподавал лучшим спортсменам в мире, в том числе MVP в спорте, всемирно известным артистам и музыкантам, а также лидерам и командам из списка Fortune 100. Как это принято в современной литературе по психологии и бизнесу, основные идеи излагаются через истории из мира спорта и бизнеса. Ну а в этом выступлении Майкл рассказывает основные идеи из этой книги. #Management #Leadership #SelfDevelopment #Psychology #PopularScience

Сделано, чтобы прилипать. Почему одни идеи выживают, а другие умирают (Made to Stick. Why Some Ideas Survive and Others Die) В этой книге авторы захватывающе рассказывают о том, как сделать ваши идеи "прилипчивыми". Это позволит вашим важным идеям пробивать себе дорогу. Авторы для начала рассказывают про свой акроним SUCCESs: - Простота (simplicity) - для того, чтобы обнажить суть идеи, надо уметь отсеивать лишнее. Для этого надо уметь определять цели и приоритеты - идеи должны быть одновременно кратки и содержательны. Например, такими являются пословицы, которые мы с легкостью запоминаем и используем при случае. - Неожиданность (unexpected) - для привлечения внимания важно удивить аудиторию кажущейся нелогичностью. Это близко к тезису Суворова "удивил - победил":) Но удивление не длится долго, поэтому важно кроме удивления возбудить интерес и любопытство аудитории. - Конкретность (concrete) - абстрактные идеи запонимаются плохо, поэтому авторы рекомендуют добавлять конкретные образы, которые цепляют аудиторию. - Достоверность (credentialed) - прилипчивые идеи должны сами по себе вызывать доверие и для этого можно использовать внешние авторитеты, статистику, визуализацию, тестирумые рекомендации (аля попробуй сам):) - Эмоциональность (emotional) - здесь авторы предлагают использовать эмоции для подкрепления своих людей. Плюс люди испытывают эмоции к людям, а не к абстракциям, поэтому в миксе с конкретностью этот пункт позволяет благотворительным организациям успешно заниматься фандрайзингом - Истории (story) - эта часть посвящена использованию историй, которые хорошо иллюстрируют идеи и в комбинации с другими факторами помогает не просто донести идею, но и провернуть что-то типа мысленной "репетиции", где аудитория проигрывает эту историю у себя в голове Российский издатель (МИФ) приводит следующий список причин для прочтения книги

— После прочтения этой книги — увлекательной и провокационной — вы станете иначе доносить свои идеи до мира — Чек-лист, который поможет превратить обычную идею — в «прилипчивую» — В книге есть Лаборатория идей, где можно отточить теорию на практике: представить, как улучшить чужие истории, и подумать, какие бы фишки добавить — Бестселлер: почти тысяча отзывов на Амазоне и высокий рейтинг — 6 принципов, миллион примеров, полезные кейсы и 256 страниц, которые вдохновят на креативные мыслительные подвиги

#Writing #PublicSpeaking #Leadership #SelfDevelopment #ProductManagement

Вакансия лида SRE команды в соцплатформу В концпе прошлого года я уже тизерил изменения внутри моего юнита "Клиентские интерфейсы, маркетинг и вовлечение". А сегодня я хотел рассказать про вакансию лида в одно из новообразованных управлений в рамках этих изменений. Это управление, в котором мы объединили все наши социальные сервисы и большую часть UGC (user generated content) в одно большое управлени, туда вошли: - Пульс - одна из крупнейших соцсетей для инвесторов; - Лента новостей и профиль в мобильном приложении Тинькофф; - Т—Ж (Тинькофф Журнал) - один из самых крупных медиапроектов про деньги и жизнь; - Игры в приложениях Тинькофф - например, «5 букв» или «Ряд наград»; - Видеоплатформа для сервисов Тинькофф. Радует, что этим богатсвом сервисов пользуются несколько десятков миллионов человек и мы хотим, чтобы они получали сервис максимального качества. Для это мы хотим внедрить и масштабировать единые SRE-практики в рамках всего управления, которые помогут нам оперативнее реагировать на происходящие сбои и минимизировать их количество. Для этого Алексей Тарсов (@lexasoft123), технический директор этого управления, ищет к себе в команду лида SRE, который будет поможет с реализацией этой цели. Формальные критерии есть в описании вакансии, но если кратко, то успешный кандидат - Был лидом как минимум команды - Имеет навыки работы с Linux и контейнерами, включая знания bash, а также понимает как работает сетевой стек - Знает как работают CI/CD системы и имеет практический опыт с одной из них (желательно GitLab) - Знает про принципы проектирования распределенных систем и умеет их готовить с использованием K8s - Не чурается кода и может написать что-то на Python/Go (желательно хотя бы на уровне jun+/middle) - Умеет готовить инфраструктуру не руками, а при помощи IaC подходов - Умеет хорошо коммуницировать со смежными командами и находить общий язык с другими ролями: SDE, QA, Arch, менеджерами - Разделяет принципы и философию обеспечения надежности сервисов (примерно как я описывал в докладе "Проектируем надежные системы") - Плюсом будет опыт работы с video: ffmpeg и как работает передача видео в вебе В общем, если вам нравится вакансия и вы считаете, что потянете, то пишите Леше (@lexasoft123) и он уже расскажет вам детали. #Management #Vacancy #SRE

Аудиоподкаст "Code of Leadership" Вчера я завел аудио версию подкаста и выложил первый эпизод на podster.fm, чуть позже он появится и на Яндекс Музыке. Так что теперь подкаст можно будет просто слушать, а не напрягаться и разглядывать иллюстрации из книг:) Кстати, за следующие пару недель планирую записать еще два эпизода: - по книге Turn the Ship Around, про которую я уже упоминал раньше - по книге "Как пасти котов", про которую я уже тоже рассказывал А вообще, у меня уже список гостей приближается к полугодовой загрузке при стримах раз в неделю:) Плюс я все материалы к первому эпизоду собрал в статье в своем блоге. #Management #Leadership #Podcast #Engineering #Software #SoftwareDevelopment

AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344) Продолжая вчерашнюю тему про модели консистентности, рекомендую посмотреть интересное выступление от ребят из AWS про значимый апгрейд их базы данных Aurora, которую мы как-то обсуждали в бонусном выпуске "Code of Architecture" и по которой есть whitepaper от 2017 года. Сейчас ребята добавили возможности масштабирования к этой базе данных. Причем тут фокус был на масштабировании write нагрузки, так как с read нагрузкой у этой базы уже было все хорошо. Если кратко описывать изменения, то смысл примерно такой 1) Добавляется семантика шардирования внутри самого Aurora - для этого у пользователей появляется возможности - Пометить таблицы как шардированные и указать ключ шардирования - если транзакции попадают на один шард, то это максимально быстро, если нет, то используются распределенные транзакции двухфазный коммит. Для шардирования используется hash-range partitioning. - Пометить часть таблиц как reference - такие таблички используются как справочники и они разложены на каждом шарде (их стоит использовать, если write нагрузки на эти таблички небольшие) 2) Шардированная база поддерживается семантику вида read commited и repetable read 3) Эта семантика работает внутри кластера Aurora, поэтому общие штуки типа дампа или point-in-time recovery работают как ожидается от кластера без шардов 4) Под капотом все это работает за счет добавление концепции shard group внутри aurora cluster, где есть роутеры для распределенных транзакций (здесь координируются распределенные транзакции и собирается общий результат) и шардов для доступа к данным (здесь выполняются локальные части запросов, работает локальный планировщик, используются индексы и так далее). Здесь тоже появляется дополнительный параметр compute redundancy, который позволяет compute частям шардов лучше переживать отказы 5) Для реализации repetable read ребята используют концепцию bounded clocks, которая похожа на концепт TrueTime из Spanner. Смысл этой концепции в том, чтобы использовать метки времени с разных устройств для упорядочивания транзакций. Проблема в том, что часы на разных машинка время может чуток отклоняться, поэтому приложению нужно несколько параметров: current time (approximate), earliest possible time, latest possible time. А дальше приложение должно подождать немного для того, чтобы точно не выставить транзакции метку времени из прошлого (иначе это может нарушить порядок транзакций в кластере). Эти параметры приложение получает из сервиса EC2 TimeSync с точностью порядка микросекунд. В самой презентации рассказывается как это работает для локальных и распределенных транзакций, а также для выполнения запросов с агрегатами. 6) В конце доклада авторы рассказывают про то, как взаимодействуют роутеры и шарды, а также как померить эффективность запросов, какие запросы получают максимальные бенефиты от параллелизации выполнения запросов на разных шардах (создание индексов, вакуум, агрегаты) 7) Пока эта limitless версия Aurora доступна через заявку на превью В общем, это выступление достаточно интересно. Отдельно отмечу, что для получения пользы от этих нововведений надо уметь правильно дизайнить модель данных и понимать как эффективнее разложить данные для того, чтобы максимально часто попадать в конкретные шарды и меньше попадать на распределенные транзакции. #Software #Architecture #DistributedSystems #SystemDesign #Engineering #Databases