Как выглядит роль SDE в tech компаниях

Сегодня выступаю на нашем мероприятии для студентов из МФТИ, где я учился много лет назад.
У меня есть полчаса и я планировал обсудить кучу тем:
- Современные процессы разработки и инженерные практики в российских tech компаниях - расскажу про то, как все начиналось, потом появилась история с devops, потом shift-left everything и X+Ops:)
- Как выглядит карьерный путь SDE (software development engineer) с развилкой в менеджмент и путь individual contributor высоких грейдов
- Как выглядит матрица компетенций для SDE в Tinkoff
- Как выглядит процесс роста сотрудников внутри (Tinkoff рост)
- И другие полезные мысли про саморазвитие и рост внутри компании:
-- Как использование Cynefin фреймворка
-- Как работать над сложной проблемой (и создавать артефакты RFC/ADR)
-- Как приоритизировать задачи используя матрицу Эйзенхауэра
-- Как работать со своей мотивацией
-- Как планировать работу используя backcasting (это примерно тоже самое, что working backwards от Amazon)
-- Как работает мантра "You build it, you run it" и почему она помогает инженерам расти над собой быстрее

Интересно, что многое из сегодняшнего доклада мы обсуждали с Алексеем Тарасовым в рамках выпуска Code of Leadership пару недель назад.

P.S. Материалы к выступлению

Материалы по процессам разработки
- Современные подходы к разработке программного обеспечения
- Совершенствование потока разработки программного обеспечения
- Проектируем надежные системы — стоит ли игра свеч
- Про управление проектами и продуктами
- The Pipeline-Driven Organization • Roy Osherove • GOTO 2022
- Code of Architecture — “Distributed Systems, 4th Ed” #2 (Architecture)
- Архитектура в масштабе на ArchDays 2020
- Devops культура: мифы и реальность
- Про MLOps
- The State of Application Security 2023 • Sebastian Brandes • GOTO 2023
- Как RnD появляется в крупных ИТ-компаниях

Материалы по проектированию и system design
- Статья про System Design Interview в общем
- Статья про то, как мы оцениваем System Design Interview
- Статья о том, как подготовиться и пройти System Design Interview
- Публичное System Design Interview на C++ Russia 2022
- Публичное System Design Interview на конференции ArchDays 2022
- Статья со списком книг о проектировании программного обеспечения
- Курс Essential Architecture #Code
- Курс Essential Architecture #Data

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

The 12 Factor App for Data • James Bowkett • GOTO 2023

Интересное выступление James Bowkett на тему хороших подходов для работы с данными. В названии он делает отсылку к 12 факторам, которые в свое время сформулировали ребята из Heroku и которые стали предвестником подходов cloud native приложений. James предлагает 12 факторов, которые помогут сделать более качественным пайплайн работы с данными, которые часто называют сейчас big data и используют для обучения ML моделей:) Мне принципы Джеймса понравились, а особенно понравилось то, как он их структурировал

-> Architecture & Design - факторы, относящиеся к проектированию решений
1. Data structures as code - универсальный совет не полагаться на UI, а конфигурировать настройки для управления данными через код. Это стандартный совет в духе IaC (infrastructure as a code), GitOps и так далее.
2. Append-only data structures - использование таких структур данных добавляет историчность и позволяет time travel.
3. Optimise for access and retrieval - автор рекомендует не делать кладбище данных (data graveyard), а думать про то, как денормализовать данные так, чтобы их было удобно использовать
4. Separate data from logic - автор предостерегает от использования протекающих абстракций (leaky abstraction), навроде магических значений, которые требуют специальной обработки на стороне потребителя. Это приводит к запутанности в данных, а также куче дополнительной лапши в коде у потребителей
5. Strongly type your data columns - автор призывает думать про типы данных и использовать их. Это позволяет получать более качественные данные в хранилище + сами движки хранения эффективнее работают если нам не нужно непрерывно кастовать данные между типами (что, кстати, тоже является протекающей абстракцией)
-> Quality & Validation - факторы, относящиеся к качеству данных и валидации
6. Architect for regression testability - наше решение должно быть спроектировано с учетом потребности в регрессионном тестировании отгружаемых данных, что является пререквизитом для CD (continuous delivery)
7. Track changes in your test data - автор рекомендуют хранить лог изменений, который применялись к тестовым данным, а также применять их консистентно между средами
-> Audit & Explainability
8. Mind your metadata: Data-Cataloguing - автор рассказывает про каталогизирование данных, что позволяет управлять метаданными. Мельком он упоминает OpenMetadata и Apache Atlas
9. Mind your metadata: Code Traceability - автор рекомендует организовать трассировку от данных к коду, системам, людям, которые их сгенерировали. Это позволяет понять происхождение данных, что может быть полезно при траблшутинге и не только
-> Consumption
10. Defined APIs for accessing data - автор рекомендует специфицировать API, отделить внутреннюю модель данных от внешней и никогда-никогда не открывать доступ к вашему внутреннему хранилищу (избегайте интергаций через шаренную базу данных)
11. Defined SLAs (& SLOs) for data - у API должен быть определен уровень обслуживания и ожидания для потребителей
12. Treat data as a product - данные надо воспринимать как продукт. А дальше стоит думать про потребителей продукта, их потребности, сценарии использования, ... В итоге данные начинают работать и организация становится data-driven.

#Data #DataOps #Databases #Software #Engineering #Management #Processes #Devops

Software development engineers в tech компаниях

Вчера я выступал на конференции "IT PurpleConf" с докладом для студентов про современные ожидания от software development engineers в технологических компаниях. Само выступление в виде трансляции будет еще не скоро, поэтому я ближе к ночи записал выпуск подкаста и выложил на свой youtube канал TellMeAboutTech:) Подробнее про темы выступления во вчерашнем посте и там же есть список рекомендованных материалов.

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

Code of Leadership 9 - An Elegant Puzzle - System of Engineering Management (часть 1)

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

В этом выпуске только первая половина обсуждения, так как весь выпуск получился длинной больше трех часов:) А если кратко, то за час мы успели поговорить про книгу в общем и обсудить полностью вторую главу и часть третьей главы книги:
2. Organizations - здесь идет речь про определение размера команд, как оставаться на пути к высокоэффективным командам, как не оптимизировать сверху вниз (часто это работает плохо), как быть продуктивным в быстрорастущих компаниях, как планировать успех
3. Tools - здесь автор рассказывает про системное мышление и упоминает Медоуз с ее "Азбукой системного мышления" (про которую я писал ранее), как быть исполняющим обязанности продакт менеджера, как формлировать vision и strategy, как драйвить технические миграции.

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

Why Is My App SLOw? Defining Reliability in Platform Engineering • Jez Humble • YOW! 2023

Крутое выступление от Jez Humble про то, как определять, что проблемы есть у платформы, а не у потребителей, которые ей пользуются. Jez сейчас работает SRE в serverless платформе Google, у которой большое количество клиентов с разным профилем нагрузки, разными показателями latency и так далее. В такой конфигурации есть проблема в отделении проблем клиентских нагрузок от проблем самой платформы. Но ребята в Google справились с этим, используя знания математической статистики. Если формулировать точнее, то цель была такая

A metric that represents the customer experience
- Combinable across projects / cells / regions
- Can be used to detect anomalies affecting multiple customers (likely platform
issues)
- Computationally cheap (high QPS)
- Principle-based

Дальше автор говорит про три столпа reliability:
- Availability - здесь основа в том, чтобы посчитать количество (долю) неуспешных запросов. Ситуация осложняется тем, что есть некая субъективность в ошибках (куча 400х и 500х ошибок, которые задаются самими владельцами пользовательских нагрузок), возможны ошибки из-за нарушенных deadlines, могут просто с ошибками плохо сформированные запросы от клиентов, retries могут усиливать количество ошибок
- Performance - здесь автор говорит про установку P99 latency SLO и создании проберов. Но есть проблемы с зависимостями между нагрузками и тем, что проберы могут быть слишком узкими
- Correctness - здесь есть много тестов и анализ канареечных развертываний, но проблема с тем, что покрытие ограничено

Дальше автор говорит, что можно попробовать построить функцию распределения для пользовательских нагрузок (например, log-normal), а дальше можно представить, что пользовательские нагрузки можно считать стационарными. И следом использовать метод двух сигм и сформулировать гипотезу

Hypothesis:
Self-Similar Workloads Should Have Consistent Performance
Technique Overview:
- Partition workloads into Cohorts ← Approximate Intent via Workload Features
- Build Performance Baselines ← Estimate Distributional Form (e.g. Normal)
- Estimate Likelihood of Delivered Performance ← Test For Stationary
Result:
- Set of Events with Predicted Likelihoods
- Time-series of summary statistics describing concentration of extreme outliers

А дальше стратегия использования в том, чтобы
- Рассчитать z-scores среди нагрузок по кагортам, где z-scores = (observed-workloads - baseline-mean) / baseline-std
- Отслеживать долю нагрузок, у которых z-score ≥ 2 в выбранном временном окне
- Считать, что 2-5% процентов нагрузок с 2𝜎 отклонениями нормой
- Тригерриться, когда этот показатель будет выше 10%

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

P.S.
Мне нравятся материалы Джеза, которые бывают как в печатном виде, так и в виде докладов. Раньше я уже рассказывал про
- Книгу "Accelerate" 2018 года, где Jez выступал в качестве соавтора (подробнее в постах 1, 2, 3)
- Книгу "Continuous Delivery" 2010 года, которая была важной вехой в развитии CI/CD (подробнее в посте)
- Этот же доклад, но на конференции goto в 2023 году
- Доклад Expert Talk: The Current State of Software Engineering"
- Доклад "How to Improve Developer Productivity"

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering #Math #ContinuousDelivery

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