Книжный куб

Посещение Ульяновска и конференции Стачка Я люблю ездить на разные региональные конференции, так как это позволяет посмотреть на разные города России. Например, конференция Стачка, на которой я вчера выступал, проводиться в Ульяновске, куда я приехал в первый раз:) Интересно, что конференция проходит в здании УлГПУ (Ульяновском государственном педагогическом университете), а мое выступление вообще было в библиотеке, что очень хорошо укладывается в область моих интересов:) Также рядом с университетом есть набережная, откуда открывается отличный вид на Куйбышевское море водохранилище. Вчера мне провели тут крутую экскурсию и я готов поделиться фотографиями с этой прогулки. #Conference

Совершенствование потока разработки программного обеспечения (Improving software flow) Появилась запись моего выступления в Казани с этим докладом, где я рассказываю о том, как разрабатывать программное обеспечение эффективно. И разбираю вопрос с точки зрения пяти идеалов из книги The Unicorn Project. А также рассказываю о том, как мы это используем у себя внутри Тинькофф. Расшифровка доклада есть в моем блоге, а рекомендуемые материалы приведены ниже. -------------------- 4 основные книги, из которых родилась идея доклада - The Phoenix Project (2013 год) - книга написана в жанре производственного романа и похожа на книгу "Цель" ("Goal") или "Критическая цепь" ("Critical Chain") Голдратта. - The DevOps Handbook (2016 год) - книга с популяризацией devops подхода - Accelerate (2018 год) - книга, где приводятся крутые выводы о связи процессов и практик внутри организации и ее эффективности, а это именно те вопросы, которые интересуют менеджмент. - The Unicorn Project (2019 год) - эта книга написана Gene Kim как продолжение предыдущей книги Проект Феникс Связанные книги - Team Topologies - книга про Team-First подход при проектировании архитектуры программных систем, так и организации. - Learning Domain Driven Design - эта книга содержит много рекомендаций о том, как бороться со сложностью при проектировании софта. - A philosophy of sotfware design - книга посвященная борьбе со сложностью и тому, как практиковать стратегический подход к разработке. - Making Work Visible - простая книга про улучшение процессов разработки с использованием kanban подходов - SRE Book - крутая книга целиком посвященная тому, как делать надежные системы и строить процессы вокруг них - "Lean Software Development" - книга про lean практики в разработке Исследования - Google's Project Aristotle - исследование, которое ответило на вопрос "What makes a team effective at Google?" - A typology of organisational cultures - интересное исследование про типологию организационных культур (pathological, bureaucratic, generative) Мои выступления на связанные темы - Культура постмортемов - От монолита к микросервисам и обратно - Эволюция подходов к развитию мобильного банка Тинькофф - Эволюция web Tinkoff на ArchDays #Processes #Management #Architecture #Conference #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SoftwareArchitecture

Материалы к докладу "Проектируем надежные системы  -  стоит ли игра свеч" Сегодня я выступаю на конференции "Стачка" с одноименным докладом и поэтому по традиции делюсь списком материалов - "Site Reliability Engineering" - книга от ребят из Google, с которой началась серия SRE книг и они рассказывают про процесс в общем - "Building Secure and Reliable Systems" - книга от ребят из Google, где они рассказывают про принципы проектирования надежных систем (продолжает серию SRE книг) - "AWS Fault Isolation Boundaries" - интересный white paper от AWS на тему границ изоляции сбоев в AWS (здесь интересно написано про инфраструктурные абстракции: зоны, регионы, globl, а также про разделение control plane и data plane при проектировании сервисов и концепцию static stability) - "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - интересный white paper от ребят из Google, где показано как редизайнится система для повышения ее надежности, причем сам редизайн выполняется достаточно формально, чтобы по модели оценить позитивное влияние на надежность - "Deployment Archetypes for Cloud Applications" - интересный white paper от ребят из Google, в котором они рассказывают про разные модели deployment приложений, которые позволяют достигать разных уровней availability (зональный, региональный, мультирегиональный, глобальный, гибридный, мультиоблачный) - Глава про resilience из книги "Continuous Architecture in Practice" - глава крутой книги, в которой буквально на пальцах авторы объясняют чем старый high-availability подход отличается от нового подхода resilience к обеспечению надежности систем - "Philosophy of Software Design" - отличная книга про то, как бороться со сложностью систем - "503 Подкаст - System Design в разрезе надежности" - подкаст с Андреем Дмитриевым из JUG Ru Group, где я был гостем и мы обсуждали проектирование надежных систем - "Architecting for Scale: High Availability for Your Growing Applications" - интересная книга Lee Atchison, где он обсуждает проектирование для масштабирования и затрагивает вопросы обеспечения availability. Книга пережила второе издание и это пошло ей на пользу. - "Собеседование SRE: Troubleshooting и System Design" - моя статья про найм SRE инженеров в Tinkoff, где мы проверяем на практике работу инженеров в рамках инцидента #Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistirbutedSystems #SRE

Architecture Anti-patterns: Automatically Detectable Violations of Design Principles Эта статья посвящена интересной для меня теме architecture governance. В ней авторы рассказывают о своих подходах для автоматического нахождения архитектурных анти-паттернов в больших системах. Суть в том, что файлы, которые подвержены изменениям и ошибкам редко в таких системах живут поодиночке - обычно они архитектурно связаны и эти связи отображают архитектурные проблемы, которые приводят к распространению подверженности ошибкам. В этой статье авторы определяют набор антипаттернов, взяв за осноову фундаментальные принципы дизайна и Baldwin and Clark’s design rule theory. Дальше они валидируют на опыте набор архитектурных анти-паттернов, которые можно автоматически находить анализируя структурные взаимоотношения в проекте, а также историю изменений. Для этого авторы проанализировали 19 крупномасштабрных системы и показали 1. Files involved in these architecture anti-patterns are more error-prone and change-prone; 2. The more anti-patterns a file is involved in, the more error-prone and change-prone it is; and 3. While all of our defined architecture anti-patterns contribute to file’s error-proneness and change-proneness, Unstable Interface and Crossing contribute the most by far. В итоге, у авторов получилось 6 антипаттернов: 1. Unstable Interface - интерфейсы, от которых многие зависят, должны оставаться стабильными 2. Modularity Violation Groups - независимые модули должны и эволюционировать независимо 3. Unhealthy Inheritance Hierarchy - этот антипаттерн про нарушение Liskov Substitution principle 4. Crossing - a file that has both high fan-in and high fan-out, and changes often together with its dependents and the files it depends on, is often at the center of maintenance activities. 5. Clique - набор файлов, которые формируют сильно-связный граф, что приводит к tight coupling между файлами (расширение истории с циклическими зависимостями) 6. Package Cycle - циклы в графах зависимостей, который нарушают базовые принципы дизайна для формирования иерархических структур. Такие нарушения приводят к тому, что изменения в файле одного package часто вызывают неожиданные изменения файлов в других пакетах из-за циклических зависимостей между ними. Интересно, что я заинтересовался этим white-paper из-за статьи "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google", про которую я рассказывал пару дней назад. Суть в том, что там авторы анализировали кодовую базу Monarch, описанным в этой статье способом, и нашли много анти-паттернов в кодовой базе компонентав Leaves, на которых было слишком много ответственности и которые было сложно поддерживать. Дальше в прошлой статье они заредизайнили этот компонент для повышения availability и maintainability. #Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistirbutedSystems

Обзор white paper "Deployment Archetypes for Cloud Applications" Данная статья 2021 года от Anna Berenberg и Brad Calder из Google на 50 страниц посвящена созданию надежных приложений за счет умного использования fault domains для обеспечения нужного для приложения availability, которое может быть разным для разных типов приложений (business-critical applications, line-of-business applications, internal applications). По названию кажется, что эта статья относится исключительно к приложениям, что разворачиваются в облаках. Но на самом деле это не так — вы сможете почерпнуть много интересного из нее, даже если вы разворачиваете приложение в своих собственных датацентрах:) По ссылке представлен мой краткий обзор этого white paper, который в оригинале состоит почти из 50 страниц. Поэтому если вас что-то заинтересует в обзоре, то я рекомендую прочитать эту часть в оригинале — там очень много контента на тему хороших подходов к проектированию систем. #DistirbutedSystems #ExternalReview #SoftwareDevelopment #SoftwareArchitecture #Architecture #SystemDesign #SystemEngineering #Cloud

The Engineering executive’s role in hiring от Will Larson У Will Larson есть интересная рассылка, в которой он поднимает важные темы. И вот в конце августа он написал пост про то, как условные CTO и VP of Engineering могут участвовать в найме. Статья получилась большой, потому что это неотредактированная версия главы из новой книги Вила "The Engineering Executive’s Primer" (на сайте O'Reilly есть ранний доступ к этой книге, которую можно читать в процессе написания). Но если возвращаться к статье, то в ней были рассмотрены следующие темы - Как выстроить в общем процесс найма, включая описание позиций, цикла найма и т.д. - Какова роль executives в мониторинге и дебаге процесса найма - Как помогать финализировать найм ключевых кандидатов в вашей организации - Как оценивать уровень кандидатов - Как управлять headcount и что это ключевая часть управления наймом - Как тренировать нанимающих менеджеров - Как калибровать наем как извне, так и внутри, включая внутренних кандидатов - Как оценивать и развивать инженерный бренд компании (что влияет на найм) - Когда и как вводить комитет по найму - Как помнить о том, что выстроенная система служит вам, а не наоборот В общем, все как обычно - вопросы у Will отличные, а хороший слог и наличие четкой структуры позволяет легко воспринимать его рекомендации и встраивать в свою работу:) #Management #Leadership #Engineering #Software #SoftwareDevelopment

Обзор white-paper "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" Одна из моих областей интересов — это проектирования сложных систем и построение архитектурных процессов. Несколько месяцев назад я нашел эту статью от ребят из Google, которая вышла в 2023 году. В этой статье авторы (Qin Jia, Yuanfang Cai, Onur Çakmak) рассказывают про структурированный процесс редизайна крупной системы (Monarch) с использованием сценариев атрибутов качества (quality attribute scenario), а также с использованием моделирования системы при помощи UML. Я прочитал эту статью на выходных и готов поделиться кратким обзором. #Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistirbutedSystems #ExternalReview

Проектируем надежные системы - стоит ли игра свеч Выступаю 21 сентября на конференции Сбера SmartDev с докладом про проектирование надежных систем. В своем выступлении я попробую задать и ответить на следующие вопросы - Надо ли нам думать о надежности нашей системы и от чего это зависит? - Как оценить надежность существующей системы? - Почему надежность сложно добавить в существующую систему? - Какие существуют принципы для проектирования надежных систем? - Как выстроить процессы для достижения надежности? P.S. Регистрируйтесь на конференцию и приходите оффлайн или смотрите в онлайне, благо она бесплатная:) #Architect #Architecture #Software #SoftwareDevelopment #SoftwareArchitecture #Conference

Алексей Савватеев | Теория игр вокруг нас Отличное выступление от Алексея Савватеева про теорию игр. Алексей всегда отлично рассказывает, а тут он привел много примеров реальных ситуаций, которые рассмотрел с точки зрения теории игр. Модельки получились действительно интересными, а формат и подача материала очень хороши. Мне особенно понравилось как разбирались модели: - Теория игр в Талмуде - Люксембург и Евросоюз - Синдзо Абэ и Северная Корея - Парадокс Брайеса - Два парадокса Трампа В общем, эти лекции можно воспринимать как вторую часть знаменитой фразы "Хлеба и зрелищ" - тем более лектор в рамках одной из игр с слушателями даже разыгрывает 2 шоколадки, которые неплохо подподают под первую половину данной фразы:) P.S. На тему теории игр еще можно почитать: - "Теория игр в комиксах" - "Теория игр. Искусство стратегического мышления в бизнесе и жизни" #Thinking #Math #SelfDevelopment #PopularScience

Resilience как архитектурная характеристика (из книги Continuous Architecture in Practice) Я уже упоминал несколько раз книгу "Continuous Architecture in Practice" как достойный изучения труд по архитектуре (посты: 1 и 2). А сегодня я решил поделиться кратким саммари того, как авторы подходят к устойчивости и надежности систем. Для начала авторы определяются с терминологией - A fault is an accidental condition that, if encountered, may cause the system or a system component to fail to perform as required. - A failure is when a system or system component deviates from its required behavior. So, a fault is something that has gone wrong and that may cause a failure to occur. - Availability is a measurable quality attribute of a system, defined as the ratio of the time when the system is available to the overall time when it could have been available. - Reliability builds on availability and adds the constraint of correct operation, not just availability. A widely used definition of the reliability of software is “the probability of failure-free software operation for a specified period of time in a specified environment.” Дальше авторы рассказывают про старый подход к обеспечению надежности, который обычно назывался high-availability и был основан на создании кластеров приложений, кластеров баз данных, использования cross-site репликации данных. Суть подхода была в том, чтобы в случае проблем с одной из нод в кластере, рабочая нагрузка могла переехать на другую ноду. А если падал кластер целиком, то можно было перенести нагрузку в другой кластер, который всегда стоял наготове (hot standby), в котором уже были все (или большинство) данных, благодаря репликации данных. И все было бы хорошо с этим подходом, удобным для разработчиков приложений, но - эти механизмы повышения доступности запутанны и сложны в использовании - зачастую они достаточно дорогие (даже в плане работающего вхолостую hot standby) - failover процессы могут занимать много времени и требовать много работы - во время восстановления система может быть полностью недоступна В общем, эти high-availability подходы были расчитаны на монолитные on-premise системы и плохо подходят для распределенных микросервисных систем, которые могут быть развернуты как on-premise, так и в облаках. Дальше авторы переходят к resilience как другому подходу для обеспечения reliability. В этом подходе каждая часть системы сама отвечает за свой вклад в обеспечение общесистемной availability за счет адаптации своего поведения к происходящим faults, например, распознавая сбои и используя, повторные запросы, автоматический перезапуск процессов, ограничивая распространение ошибки, правильно работая с latency запросов. В итоге, инженерам стоит знать и использовать такие механизмы обеспечения надежности, а не надеяться на технологии обеспечения high-availability из прошлого. Если использовать их правильно, то итоговая система будет более устойчива к ошибкам и сбоям и сможет более гибко приспособиться к проблемам во время эксплуатации систем. Интересно еще рассмотреть эти подходы в контексте стандартных показателей - Mean time between failures (MTBF) - среднее время наработки на отказ - Mean time to recover (MTTR) - среднее время восстановления В подходе с high-availability предполагалось, что время между сбоями у нас большое и когда сбой все-таки случается, то мы просто задействуем механизмы high-availability. И когда-то это было неплохим подходом. Но в текущих условиях у нас сбои частей систем могут происходить достаточно часто и тут на сцену выходит MTTR и умение этих частей системы ограничивать blast radius проблемы и не влиять на общую reliability всей системы. #SRE #Software #SoftwareDevelopment #Architecture

Ряд наград в мобильном приложении Тинькофф Мои коллеги сделали очередную крутую игрушку в мобильном приложении Тинькофф, которая называется «Ряд наград» и является игрой в жанре «три в ряд». Суть в том, что есть фигурки разных форм и расцветок и их нужно менять местами, чтобы собрать минимум три одинаковых элемента в ряд по горизонтали или по вертикали. За это игрок получает очки, большое количество которых увеличивает шанс выиграть призы, навроде дополнительного кэшбека, виртуальной акции, скидок у партнеров или денежных призов. P.S. Это игра от создателей Монополии, 5 букв и других игровых проектов в нашей экосистеме. Ребята - молодцы и растут в плане сложности проектов и игровых механик, которые они уже научились использовать в таких играх. Я помню с чего все начиналось и что мы умеем сейчас - это небо и земля. А дальше будет еще круче:)

Энциклопедия менеджера. Алгоритмы эффективной работы 3rd edition (Fast Thinking Manager's Manual) Недавно я купил стопку новых книг и там была книга издательства Альпина Паблишер с названием "Энциклопедия менеджера". Когда я ее открыл, то испытал чувство дежавю - я уже читал этот контент когда-то давно. Я начал вспоминать и понял, что новая книга была пятым изданием, а я в далеком 2007 году покупал третье издание этой книги, так как я хотел тогда понять как работают менеджеры, какие задачи они решают и вообще как строиться командная работа. В то время книга показалась мне скучной и муторной, а сами примеры не ложились на мой опыт - тогда я только начинал свой путь и был начинающим разработчиком. Прошло много лет и теперь впечатления совсем другие - я планировал пролистать книгу для того, чтобы освежить воспоминания и внезапно оказалось, что я начинаю ее перечитывать. В ней приведены слишком жизненные ситуации, которые отзываются у меня и в которых я зачастую действую похожим образом как рекомендуют авторы, но я пришел к этому сам а не следуя этим рекомендациям:) Плюс мне очень нравится структура этой книги и ее подход. Приведенные в ней алгоритмы работы сгруппированны по темам - Алгоритмы для руководителя среднего звена: собеседования, аттестации, проблемные люди, дисциплина, прием нового сотрудника, поощрение персонала - Алгоритмы для руководителей высшего звена: совещания, кризис, проект, принятие решений, конструктивная критика - Алгоритмы для исполнителя: поиск фактов, бюджет, презентация, предложение, управление временем - Алгоритмы для человека: аврал на работе, быстрое включение в работу Каждый из алгоритмов расписан для трех вариантов, которые зависят от доступного времени, начиная с 1 дня на подготовку, проходя через 1 час и заканчивая 15 минутами. В общем и целом, эту книгу действительно можно использовать как энциклопедию. Я многие из этих тем познавал сам, изучая другие книги, посещая конференции, собирая шишки на практике и могу сказать, что качество советов в этой книге отличное. Рекомендую! P.S. В этой книге нет специфики относительно разработки программного обеспечения, но кажется, что это и не требуется:) #Management #Leadership #Career #SelfDevelopment

Комиксы "Слишком короткая ложка" и "Взаимосвязь всех королей" по мотивам произведений Дугласа Адамса "Холистическое детективное агенство Дирка Джентли" Когда я покупл эти комиксы, то клюнул на то, что что комикс сделан по мотивам произведений Дугласа Адамса, который написал крутой фантастический роман "Автостопом по галактике", в котором было много юмора и иронии:) Про холистическое агенство я ничего не знал, но думал, что это будет весело. В итоге, могу сказать, что комикс нарисован интересно, а вот истории отдают каким-то абсурдом и некоторой мешаниной смыслов, где из внешне бессвязного потока событий потом собирается канва истории. Мне конечно такое читать не особо по нраву - я пытаюсь отследить логику, но кажется, что основная суть историй рассмотреть их с холистической позиции, где весь мир — это единое целое, а выделяемые нами отдельные явления и объекты имеют смысл только как часть общности:))) #Comics #SciFi

Practical ML Conf 2023 Внезапно сегодня утром наткнулся в Youtube на трансляци конференции по ML от Yandex. Вот ссылки на - Трансляцию первого зала - Трансляцию второго зала Вот ссылка на канал конференции P.S. Расписание конфы приложил в изображениях. Думаю, что вечером посмотрю что-то интересное из этой трансляции:) #Conference #ML #DataScience #Software

Practical ML Conf 2023 Внезапно сегодня утром наткнулся в Youtube на трансляци конференции по ML от Yandex. Вот ссылки на - Трансляцию первого зала - Трансляцию второго зала Вот ссылка на канал конференции P.S. Расписание конфы приложил в изображениях.

В итоге, по мнению автора применение этих пяти принципов поможет сделать системы надежными и отказоустойчивыми. #Chaos #Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software #SoftwareDevelopment

Practical Magic: The Resilience Potion & Security Chaos Engineering • Kelly Shortridge • GOTO 2023 Интересное выступление от Kelly Shortridge, Senior Principal at Fastly, про Security Chaos Engineering, про которую она написала одноименную книгу. В самом докладе автор рассказывает про 5 составляющих устойчивость (resilience) системы: 1. Define the system’s critical functions Зная что относится к критическому функционалу, легко понять что в него не входит, а это позволяет более осознанно действовать как при разработке, так и во время инцидентов. Например, ясно где стоит использовать скучные, но предсказуемые технологии:) Новые и модные технологии стоит использовать там, где это выступает для бизнес-проблем в качестве market differentiator. Здесь же идет речь про важность стандартизации: языков, бибилиотек и tooling. Автор обращает внимание на вопрос memory safety, а потом переходит к важности понимания и работы со своими зависимостями. Также работа с данными требует особого обращения - надо ограничивать доступ к чувствительной информации. 2. Define the system’s safe boundaries Здесь автор выдает такую фразу "A lot of getting security “right” is just solid engineering. Security is a facet of quality", которая позволяет аргументировать внедрение хороших инженерных практик не только с точки зрения оптимизации темпа разработки или улучшения качества, но и с точки зрения рисков (как любят строить аргументы security специалисты). В этом же разделе автор говорит о том, что надо предвидеть масштабирование системы и думать о том, как она будет себя чувствовать при изменившихся условиях. Нам надо предвидеть потребность в реакции на инциденты наших ops/SRE команд. Дальше здесь опять идет речь про стандартизацию, но на этот раз паттернов и инструментов. Автор предлагает не создавать самим middleware, но предоставить командам список проверенных библиотек и сервис провайдеров, которые им стоит использовать. Плюс команды опять же должны знать про свои зависимости и понимать какие там могут быть ошибки. Если думать про уязвимости, то их надо классифицировать по тому, насколько атаку легко автоматизировать и масштабировать, а также насколько атака далека от целей атакующего. И с учетом этого можно приоритизировать устранение уязвимостей. 3. Observe system interactions across spacetime Для построения безопасных и устойчивых систем нам нужна observability как с точки зрения топологии систем, так и с точки зрения изменений во времени. Дальше идет речь про ментальные модели, которые мы строим для понимания системы, а также про тестирование как систем, так и наших ментальных моделей. Автор топит за integration tests и ругает unit tests, но это кажется последствия профессиональной деформации. Дальше заходит речь про chaos engineering (например, есть такая книга), а потом про то, как это переходит в security chaos engineering. Автор рассказывает про стандартный цикл: постановку гипотезы, проведение экспериментов, анализ результатов и постановку задач на улучшение. 4. Feedback loops and a learning culture Здесь автор говорит про важность обратных связей и обучения для улучшения ситуации. И тут на сцену выходит distributing tracing, который нам просто необходим:) Про тему с распределенным трейсингом можно прочитать отдельную книгу "Distributed Tracing in Practice" 5. Flexibility and willingness to change В общем и целом, без желания меняться и менять систему не построить устойчивую систему. Это про адаптацию и про рефакторинг, про изменение кода наших систем и про простоту внесения изменений. Дальше автор рассказывает про статическую типизацию кода как помощь при рефакторинге:) Дальше автор переходит к модульности и появляются отсылки к coupling и тому, что модули формируют локальные границы для изоляции друг от друга. А isolation - это ключевое свойство, которое поддерживает system resilience. Дальше автор рассказывает про использование sandbox для исполнения опасного кода. Напоследок автор рассказывает как менять систему, используя паттерн "Strangler Fig", про которую рассказывал неплохо Мартин Фаулер почти 20 лет назад.

Как RnD (Research and Development) появляется в крупных ИТ-компаниях На TeamLead Conf++ 2023 я расскажу доработанный доклад про RnD, который я уже рассказывал на нашем дне открытых дверей в Ереване, но записи которого не велось. В докладе я попробую ответить на вопросы: — Зачем крупным ИТ-компаниям заниматься RnD — В какой момент RnD может появляться и как может выглядеть — Какие задачи могут стоять перед RnD-направлением — Как может происходить внедрение инноваций и как сделать этот процесс эффективным P.S. Для доклада я возьму другие Bigtech компании, которых нет в статье приведенной выше, а также попробую посмотреть как это происходит в российских компаниях, включая Тинькофф. #RnD #SoftwareDevelopment #Software #Conference

Материалы к докладу на конференции Flow "Как развиваться, если ты уже Senior System Analyst" Расшифровка доклада уже доступна в моем блоге. Но так как у меня очень обширный доклад и я упоминаю много моментов, про которые рассказывал отдельные доклады, то я прикладываю ссылки на эти материалы - Доклад "'Канал. Продукт. Платформа' или эволюция подходов к развитию мобильного банка Тинькофф"  - Краткий обзор "Team topologies" в трех частях   - - Teams as means of Delivery - - Team Topologies that work for flow - - Evolving team interactions for innovation and rapid delivery - Статья "Про performance review в командах разработки" - Обзор white paper "DevEx: What Actually Drives Productivity"  - Доклад "Современные подходы к разработке программного обеспечения"  - Доклад "SOLID'ный тимлид, или основы менеджмента для технарей"  - Доклад "Как нанимать технических руководителей"  - Доклад "Как и куда развиваться, если ты уже Senior Software Engineer"  - Доклад "Варианты роста инженера, если он уже Senior"  - Доклады про system design interview  - - в общем про system design в Тинькофф  - - больше про то, как мы оцениваем прохождение собеседования  - - как подготовиться к собеседованию  - -пример на C++ Russia 2022 про проектирование ленты в сервисе видео - - пример на ArchDays 2022 про проектирование букинга номеров в отелях  - - пример на C++ Russia 2023 про проектирование умных парковок #Career #SystemDesign #Software #SoftwareArchitecture #Architecture #Engineering