Книжный куб

Новогодний отпуск

Мой отпуск уже заканчивается, завтра на  работу, а сегодня еще 9 часов лета. Если подводить итоги, то отпуск в новогодние каникулы обычно бывает хорош и позволяет успеть многое:
- Можно хорошо провести время с семьей и отдохнуть
- Посмотреть красивые места - в этот раз это была Шри Ланка
- Порефлексировать о  прошедшем годе и его итогах
- Подумать о будущем - раньше я бы сказал о планировании, но сейчас предпочитаю не строить планы, а думать о приоритетах
- Почитать интересные книги - я прочел тройку книг и несколько whitepapers

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

P.S.
И раз отпуск заканчивается, то дальше я смогу постить еще больше интересного в канале:)

What Do Developers Want From AI? (Рубрика #DevEx)

Летом 2024 года вышла интересная статья про то, что эволюция AI - это поворотный момент, но с технологическими революциями, что меняют формат работы людей, человечество сталкивается не в первый раз. Поэтому авторы статьи решают провести параллели с развитием автомобильной промышленности и сфокусироваться на потребностях и целях наших разработчиков. Это статья из серии "Hunam centric approach to developer productivity" от ребят из Google, про которую я рассказывал раньше. А теперь основные моменты статьи

1) Последние достижения в AI привели к появлению большого количества инструментов разработки для поддержки искусственного интелекта (например, DuetAI, CoPilot и ChatGPT для задач программирования). После этого было проведено много исследований влияния этих инструментов на продуктивность разработчиков, где задавались вопросы навроде
- Повышают ли улучшения ИИ скорость написания кода?
- Улучшают ли они качество написанного кода?
- Помогают ли они разработчикам находить более креативные решения?
2) Но вот обсуждений того, а как разработчики хотят взаимодействовать с AI в своих инструментах, было гораздо меньше. Авторы исследования со своим фокусом на человекоориентированный подход к пониманию продуктивности разработчиков решили это испраивать и провести исследование для ответа на вопрос, а где разработчики хотят видеть ИИ в своих рабочих процессах, и какими, по их мнению, будут его эффекты?
3) Здесь авторы начинают проводить параллели с автомобилями для понимания потребностей. Они говорят, что понимание того, что люди хотят и в чем нуждаются от технологий, является основой исследований пользовательского опыта. Однако этот подход иногда подвергается сомнению, особенно когда речь идет о крупных технических инновациях - в этих случаях вспоминают знаменитую фразу, приписываемуюГенри Форду: "Если бы я спросил людей, чего они хотят, они бы сказали 'более быстрых лошадей'".
4) Для исследования предпочтений разработчиков авторы провели многочисленные интервью и пользовательские сследования с разработчиками, имеющими различный опыт работы с инструментами разработки с поддержкой ИИ. Разработчики выражали свое желание, чтобы такие инструменты экономили их время и энергию, помогая им более эффективно выполнять свою работу, то есть они хотят, чтобы ИИ поддерживал более простые задачи и уменьшал рутину, позволяя им сосредоточиться на решении сложных проблем и творческих аспектах их работы.
5) Для того, чтобы понять какие области мешают разработчикам быть продуктивными в Google исследователи проводят опросы и анализируют логи. Это позволяет сфокусировать усилия на самых важных факторах, тройка которых в Google сейчас такая
- Технический долг
- Плохая или отсутствующая документация
- Сложности в изучении новых платформ и технологий
6) Авторы классифицировали эволюцию улучшений AI по трем типам (проведя параллели с автомобильной промышленностью)
- Улучшение существующих человеческих возможностей. Для машин это усилитель руля, антиблокировочная система для тормозов. Для AI в разработке это code completion.
- Расширение человеческих возможностей (добавление новых). Для машин это камера заднего вида, контроль слепых зон. Для AI в разработке это code review suggestions, chatbots
- Делегирование человеческих возможностей (фичи, что убирают human in the loop). Для машин это удержание полосы движения, автоматическое торможение, улучшенный круиз-контроль. Для AI в разработке это автоматический откат проблемных релизов, автоматическое удаление dead code, генерация тестов
7) Для успешного внедрения изменений с AI необходимо
- Понимание сопротивления и скептицизма разработчиков
- Создание правильной инфраструктуры для внедрения
- Обеспечение безопасного и справедливого доступа во всех отраслях
- Сохранение фокуса на целях разработчиков, а не только на технологических возможностях

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

Обложки и немного иллюстраций к книгам "The Culture Map" и "Карта культурных различий"

The Culture Map (Карта культурных различий) (Рубрика #Management)

Прочитал на каникулах этот бестселлер десятилетней давности от Erin Meyer и он мне понравился. В нем Эрин, профессор INSEAD, интересно изложила свою гипотезу о карте различий разных культур, которую можно воспринимать через восемь отдельных непрерывных шкал, включающих в себя
1. Communication (коммуникация): low-context vs. high-context
2. Evaluation (оценивание): direct vs. indirect negative feedback
3. Persuading (убеждениe): principles-first vs. applications-first
4. Leading (лидерство): egalitarian vs. hierarchical
5. Decision-making (принятие решений): consensual vs. top-down
6. Trust (доверие): task-based vs. relationship-based
7. Disagreement (несогласие): confrontational vs. avoidance
8. Scheduling (планирование времени): structured vs. flexible24

Школа мысли Эрин в том, что у каждой из этих шкал есть два экстремальных значения, а дальше каждая из стран позиционируется на шкале так, чтобы отображать медиану приемлемого поведения. Но важна не сама точка, а скорее относительное положение стран между собой, так как все познается в сравнении. Для этого автор щедро приводит очень большое количество примеров, разбирая каждую ось
1. Communication (коммуникация)
- Низкоконтекстная - (США): Американский менеджер прямо скажет "Крайний срок проекта - следующая пятница, 17:00"
- Высококонтекстная (Япония): Японский менеджер может сказать "Нам стоит подумать о завершении в ближайшее время", ожидая, что команда поймет подразумеваемую срочность.
2. Evaluation (оценивание
- Прямая (Нидерланды): "Эта презентация полностью неверна и требует переделки".
- Непрямая (США): "Вы сделали несколько интересных замечаний, но, возможно, стоит рассмотреть альтернативные подходы".
3. Persuading (убеждениe)
- От принципов (Германия): Немецкий менеджер сначала объяснит теоретическую базу и методологию, прежде чем представить выводы.
- От практики (США): Американский презентующий начнет с вывода или рекомендации, затем при необходимости предоставит подтверждающие данные.
4. Leading (лидерство)
- Эгалитарное (Дания): Сотрудники свободно не соглашаются с начальником на встречах и могут пропускать иерархические уровни при общении.
- Иерархическое (Китай): Сотрудники должны следовать proper каналам и получать одобрение непосредственного руководителя перед обращением к высшему руководству.
5. Decision-making (принятие решений)
Консенсусное (Япония): Каждый отдел должен рассмотреть и одобрить предложение, прежде чем оно пойдет вверх по цепочке командования.
Сверху вниз (Бразилия): Босс принимает решения самостоятельно, а члены команды должны выполнять их без вопросов.
6. Trust (доверие)
На основе задач (США): Доверие строится через стабильное достижение результатов и соблюдение сроков.
На основе отношений (Китай): Доверие развивается через совместные обеды, личные разговоры и построение социальных связей вне работы.
7. Disagreement (несогласие):
Конфронтационное (Франция): Члены команды открыто дебатируют и оспаривают идеи друг друга во время встреч.
Избегающее (Япония): Проблемы обсуждаются приватно в малых группах для поддержания гармонии и избегания публичной конфронтации.
8. Scheduling (планирование времени)
Структурированное (Германия): Работа следует фиксированным графикам с четкими дедлайнами и точными временными рамками.
Гибкое (Индия): Графики адаптируемы, с подвижными дедлайнами и регулируемым рабочим временем в зависимости от обстоятельств.

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

P.S.
Есть хороший обзор книги от Руслана Фазлыева, CEO Ecwid.

#Management #Leadership #Culture #PopularScience

Обложка книги "Fundamentals of Enterprise Architecture" и немного иллюстраций. Забавно сравнить отличия финальной версии обложки и early preview.

Code of Leadership #27 - Интервью с Виктором Фирсовым про эволюцию развития веба Т-Банка за 12 лет (Рубрика #Management)

В этом выпуске подкаста ко мне пришел Виктор Фирсов для того, чтобы обсудить как эволюционировали веб-интерфейсы Т-Банка и как он всеми силами помогал этому. Сейчас Виктор является техническом руководителем 100+ инженеров, что отвечают за публичный веб и личные кабинеты физических лиц. А начинал Витя с позиции инженера и занимался формами для привлечения клиентов. Эпизод доступен в Youtube, Podster, Yandex Music.

На общение мы потратили чуть больше часа и успели обсудить следующие темы
- Где Витя родился, учился и как попал в IT
- Как он переехал из Нижнего Новгорода в Москву, приняв офер Т-Банка 12 лет назад
- Как прошла технологическая трансформация при переходе со старого решения на react
- Как команда росла и пришлось делать организационные изменения
- Как выглядели вызовы в 2022-2023 годах и как их удалось с успехом преодолеть
- Как выглядел проект ребрендинга в общем и что надо было сделать технической команде
- Как вообще подходить к позиции технического руководителя и чем она отличается от инженерной
- Какие советы можно дать вкатывающимся в IT, а также продолжающим свое профессиональное развитие

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

P.S.
Я с Витей работаю 8 лет, с самого своего первого дня работы в компании и могу сказать, что он прошел большой путь от хорошего инженера до крутого технического руководителя. До последнего года он был моим прямым reportee и я как мог помогал этому случиться. В последний год он мой skip level reportee, но это ему не мешает показывать классные результаты.

#Management #Leadership #Software #Processes #Retrospective #ChangeManagement

The elearning designer's handbook (E-learning. Пошаговое руководство по разработке электронного обучения) (Рубрика #Education)

Эта книга Тима Слейда попалась мне на глаза случайно и хотя она рассказывает про создание онлайн курсов, но мне это показалось отчасти близким к написанию книги:) По-итогу, я прочел книгу за пару часов в силу ее небольших размеров и общей очевидности идей. Если рассказывать про книгу кратко, то она состоит из предисловия, вступления, пяти основных шагов и финального напутствия о том, что надо продолжать двигаться дальше.
1) Предисловие - здесь автор рассказывает про свой путь к педагогическому дизайнеру электронного обучения (я даже не знал, что это так называется до того, как прочел книгу). Тим изначально был subject matter expert много лет, а потом его попросили сделать курс для обучения других и ... так его карьера сделала поворот к созданию курсов
2) Вступление - здесь автор на пальцах показывает, что создание курса похоже на строительство дома. Он объясняет, что нужно понимание кто такие бизнес-заказчики, кто такие subject matter experts и зачем нужен план (чтобы дом достроился и был сдан, а не остался брошенным недостроем)
3) Шаг первый - создание плана проекта. По-факту, если вы знаете про проектное управление и руководили проектами, то тут вы не узнаете почти ничего нового. Автор рассказывает про то, что надо определиться со scope проекта, участниками, их зоной ответственнсти (лучше по матрице RACI, но он про это не говорит). Важно построить график проекта и отметить ключевые точки и контролировать их прохождение и так далее
4) Шаг второй - составление раскадровки курса. В этой части автор говорит о том, что лучше не делать курс целиком, а пользоваться методом прогрессивного JPEG, когда содержимое курса сначала набрасывается в черновом верхнеуровневом варианте, а дальше показывается стейкхолдерам. Это позволяет на начальном этапе провалидировать концепцию курса и получить ценную обратную связь. Этот этап позволяет задать канву курса и зафиксировать примерно материалы, что войдут в него.
5) Шаг третий - разработка курса. На этом шаге надо пойти и сделать сами материалы. Когда есть понятная канва и структура, то это должно быть не таким сложным делом. Главное сломать страх чистового листа и начинать работать над деталями курса по частям.
6) Шаг четвертый - проверка и контроль качества курса. Здесь автор рассказывает про базовые вопросы тестирования самого продукта, потом выкатку на бета-тестеров, а также проверку удобства получившегося продукта с точки зрения user experience через интервью с бета-тестерами
7) Шаг пятый - запуск курса. Автор говорит о том, что иногда курсы могут публиковаться в LMS системах, а иногда это просто html странички в интернете. В любом случае автору курса надо понимать на какой платформе он публикует курс, как он сможет его дорабатывать, а также где сможет посмотреть аналитику по прохождению курса учениками.

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

P.S.
Кстати, у автора есть свой сайт TimSlade.com

#Education #Writing

Стажировки в Т-Банк - Тинькофф Старт (Рубрика #HR)

Открылась очередная зимняя программа стажировок в Т-Банк. Набор идет по куче направлений, в software engineering это направления вида java, scala, go, python, iOS, Android, .net, а также SRE, ML, frontend:) Стажировки у нас оплачиваются и во время них вы будете работать над реальными задачами, у вас будет ментор, который поможет вам адаптироваться, а по итогам лучшие стажеры будут приглашены в штат компании. Стажироваться можно в рамках гибкого графика - от 20 часов в неделю, удаленно или в офисе, в России или в соседних странах (Беларусь, Казахстан).

Для попадания на стажировку надо будет
- Подать заявку и зарегестрироваться в личном кабинете нашей edu платформы
- Заполнить анкету об опыте и мотивации, а также пройти экзамен
- Пройти интервью с командами
Если все пройдет успешно, то дальше останется только проявить себя во время стажировки, чтобы по ее окончании получить штатуную позицию.

#Career #Software #Engineering

Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers - Part II (Рубрика #Management)

Во второй части статьи, которую я начал рассматривать в прошлом посте, авторы обсуждают метрику friction.

1) Они решили опять начать отстраивать friction от восприятия инженеров, а не от данных из инструментов типа билдов, автотестов и иже с ним. В итоге, авторы построили метрику, используя
- Некоторое число компонентов, что включают ключевые активности инженеров
- Агрегировали эти компоненты по инженерам и вычислили среднее для каждого инженера
- Дальше для каждого из инженеров сравнили получившееся среднее с некоторым пороговым значением, рассчитанным в разрезе восприятия инженеров, а не просто условный 90 перцентиль
- Если пороговое значение было пробито, то считалось, что инженер испытывал friction в этот день
2) Раньше в Google уже были метрики friction, но они создавались для целей того, чтобы продемонстрировать помощь инфры или инструментов в деле снижения friction или для понимания того, а что мешает инженерам работать продуктивнее. Этим метрики отталкивались от количества или процента "плохих событий" относительно их большого количества, например, flaky tests в Google. Эти метрики имели смысл в сценариях инфра команд, но не очень матчились на опыт конкретных разработчиков.
3) Но оказалось, что если считать friction исходя из опыта разработчиков, то получаются все те же причины: test latency, flaky tests, issues with code changes being blocked due to CI failures. Это показывает, что старые метрики совпадали с новыми, но новый подход дал больше уверенности, что это отражает мнение самих разработчиков о том, что мешает им в работе.
4) Интересно, что разработчики отмечали, что до некоторой степени эти проблемы не являются причиной friction, а являются частью работы. Но при превышении некоторого порогового значения, например, flaky tests это становится проблемой и они классифицируют это как friction.
5) В итоге, метрикой friction стало
- Данные из логов о latencies для локальных билдов и тестов, latencies для change lists, проблемы с нестабильными тестами, проблемы с заблокированными submission attempts. Тут тоже пришлось поиграть с пороговыми значениями
- Данные из ежеквартальных опросов о том, испытывали ли они friction и насколько они удовлетворены со сложностью кода и скоростью разработки

В итоге, подход ребят позволяет создать базу для ответов на вопросы вида
- Можно ли улучшить focus и flow при уменьшении общекорпоративных встреч?
- Можно ли улучшить focus и flow делая дни или целые недели без встреч?
- Можно ли при помощи уменьшения длительности и слотов под сфокусированную работу добиться лучшего focus и flow?
- Как можно при помощи метрики friction определить какие процессы улучшать первыми?
- И так далее

Но сами исследователи пока в начале пути. Надеюсь, что они поделятся с нами результатами следующих шагов в очередных whitepapers.

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

39 лет (Рубрика #Retrospective)

Сегодня мне исполнилось 39 лет:) Кажется, что это достаточно много, но мне до сих пор кажется, что я только начинаю знакомиться с окружающим миром:) И в этом мне помогает моя семья:
- Жена в прошедшем году изучала психоаналитическое бизнес-консультирование и местами мне казалось, что и я тоже. Она успешно закончила первый курс магистратуры и начала делать дипломную работу про профессиональную идентификацию продакт менеджеров:)
- Старший сын стал первокурсником, поступив на геймдизайн. Я начал читать больше книг по геймдизайну, чтобы быть способным поддерживать непринужденную беседу
- Средний сын заинтересовался футболом, хокеем и баскетболом. Теперь я хожу с ним на стадион и смотрю матчи футбольного и хоккейного ЦСКА, а на баскетбольный ЦСКА мы пойдем через 2 недели:)
- Младший сын научился считать и складывать в четыре года - он вообще быстро учится, поэтому я ему рассказываю научно-популярные истории о мире вокруг нас.
- Еще у нас в семье есть собака и кошка, причем кошка появилась относительно недавно. Теперь я понимаю фразу "живут как кошка с собакой" гораздо лучше:)

Если говорить про работу, то впечатления смешанные
- Моя команда радовала меня своими успехами - ребята действительно хорошо поработали и достигли крутых результатов, я писал об этом в посте про свой юбилей "0b1000 в Т-Банке"
- На уровне всей компании часть моих инициатив зашла не так хорошо, как хотелось бы мне. Мне кажется, что иногда мое особое мнение об идеальном результате мешает достигать just enough результатов:)

Если говорить про творческую часть, то за прошедший год я
- Прочитал порядка 100 книг
- Написал кучу постов на разные ITшные темы (здесь и на Medium)
- Снял порядка 60 часов видео с крутыми гостями
- Прошел курс МИФа для начинающих писателей
- Определился с четырьмя темами книг и нашел для каждой из них соавтора - осталось их только дописать:)

В общем, до 40 надо много успеть сделать, поэтому я не планирую снижать обороты.

#SelfDevelopment

Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers - Part I (Рубрика #Management)

Недавно я с большим интересом прочел статью от ребят из Google на тему состояния потока, фокусной работы и friction, что мешает работать эффективно. Эта статья из колонки про "Developer Productivity" в журнале IEEE. В этой статье авторы описываются свой подход примерно так:
1) Авторы хотели сфокусироваться на восприятии инженеров двух концепций: flow и friction
2) Для этого они собрали данные напрямую от разработчиков, включая проведение интервью, опросов, ведения разработчиками дневников
3) Дальше они взяли эти данные и попробовали связать восприятие инженеров с данными из логов - другие исследователи обычно сразу начинали с этого этапа
4) У исследователей получилось создать эвристики для трансформации сигналов из логов в метрики, что значимо связаны с flow, focus и friction
5) Дальше авторы отвалидировали эти метрики относительно само-отчетов инженеров и данных из логов - это позоволило верефицировать, что метрики все еще связаны с тем опытом инженеров, что был интересен исследователям.

Ну а теперь немного подробностей:
1) Обычные исследования flow предполагали, что context switches между инструментами рушит этот flow. Авторы же пошли от целей инженеров и показали, что flow сохраняется, если контекст задачи сохраняется. Подробнее про статью "Measuring Developer Goals" я рассказывал раньше
2) Из diary studies и follow-up interviews стало ясно, что flow многограннее, чем думали авторы
- Инженеры испытывают состояние потока, только если они позитивно настроены относительно работы, что они выполняют
- Это может быть не только код, но и другие активности (написание дизайн доков, изучение документации, написание писем/сообщений, ...)
- Когда состояние потока достигнуто, то инженеры могут оставаться в нем даже при небольших отвлекающих факторах
3) Дальше авторы рассказывают, что они не смогли выделить как определить из логов состояние потока, но можно выделить состояние сфокусированной работы. Для этого надо посмотреть занимаются ли инженеры связными задачами (фокус) или несвязными (расфокус).
4) Концептуальная модель выглядела примерно так: сфокусированная работа нужна для достижения flow, но ее не достаточно. Одновременно из логов можно вытащить focus time, когда инженеры работали над связными задачами, но не факт, что это точно отображается на сфокусированную работу. Для анализа связности задач ребята использовали word2vec по данным из логов
5) Дальше шла валидация того, что инженеры заполняли в опросах или в diary data с тем, что насчитали авторы насчет flow и focus из логов. В итоге, метрики авторов показали хорошую связь между восприятием и этими метриками

Рассказ про метрику friction в продолжении этого обзора.

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

SolarBalls (Шаранутый космос) (Рубрика #ForKids)

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

1) Теория Большого взрыва
Вселенная началась с сингулярного состояния — бесконечно плотной и горячей точки, которая около 13,8 миллиарда лет назад начала расширяться. Это событие не было "взрывом" в привычном смысле, а представляло собой расширение пространства. В мультсериале этот процесс объясняется через разговоры между персонажами-планетами, которые обсуждают "появление всего". Например, они шутят о том, как всё началось с "маленького пузырька", который раздувался (аллюзия на инфляционную модель. Также упоминается реликтовое излучение — "эхо" Большого взрыва, которое подтверждает эту теорию. Оно представлено как "фоновая музыка", оставшаяся от ранней Вселенной. Интересно, что за его открытие когда-то даже дали Ноебелвскую премию.
2) Образование звёзд и планет
Звёзды формируются из облаков газа и пыли под действием гравитации. В мультсериале это показано как "танец" частиц, которые притягиваются друг к другу, пока не зажигается звезда. Планеты образуются из протопланетного диска вокруг молодых звёзд. В одной из серий персонажи обсуждают, как "космическая пыль и газ начали сплющиваться", создавая планеты. Это сопровождается шутками о том, что они "родились из космического беспорядка". Звёзды также играют ключевую роль в создании элементов. Например, лёгкие элементы (водород и гелий) появились после Большого взрыва, а более тяжёлые синтезировались в недрах звёзд или при их взрывах (сверхновых).
3) Появление жизни
Жизнь на Земле рассматривается как уникальное явление благодаря её местоположению в зоне обитаемости ("золотой середине"), где температура позволяет существовать жидкой воде. В одной из серий персонажи обсуждают возможность появления жизни на других планетах. Например, Венера мечтает о том, чтобы поддерживать жизнь, но другие планеты объясняют ей, что её экстремальные условия (высокая температура и давление) делают это невозможным. Также поднимается вопрос панспермии — гипотезы о том, что жизнь могла быть занесена на Землю с астероидов или комет.

Прикольно, что в мульике наука смешивается с юмором, например:
- Планеты спорят о своих орбитах и размерах, что иллюстрирует стабильность Солнечной системы.
- Звёзды шутят о своей яркости и важности для жизни.
- и так далее

В общем, я очень рекомендую этот сериал к просмотру:)

#PopularScience #Physics #ForKids #Humor

A Tool for Process Merging in Business-Driven Development (Рубрика #Architecture)

Пока искал материалы для книги по архитектуре наткнулся на артефакты из прошлого в виде подхода "Business-driven development", который 20 лет назад промотировал IBM:) Сейчас оригинальная статья на сайте IBM про business-driven development не доступна, но вот статья про инструменты все еще с нами. По-факту, BDD — это методология разработки IT-решений, которая напрямую связывает бизнес-потребности с IT-реализациями, в которой выделялись этапы вида
1) Моделирование: Определение целей бизнеса и построение моделей бизнес-процессов.
2) Разработка: Преобразование моделей в IT-реализации. В те времена реализация предполагала использование языка BPEL (Business Process Execution Language), который позволял устроить оркестрацию бизнес-процессов поверх сервисов из SOA (service-oriented architecture). Сейчас SOA ушла в прошлое и мы часто видим использование BPMN (Business Process Model and Notation) движков типа Camunda примерно для такой же окрестрации, но теперь микросервисов:)
3) Внедрение: Интеграция решений в инфраструктуру и мониторинг их эффективности.

В этой моделе были две проблемы:
- Разрыв между бизнес-моделями и iT-реальностью - модели бизнес-процессов, что дизайнились для достижения бизнес-целей, могли не транслироваться напрямую в масштабируемую, надежную и производительную хореографию IT сервисов
- Могли быть проблемы с существующей инфраструктурой - такой подход сверху-вниз мог не укладываться в существующие ограничения, софт, железо, сети и так далее

Авторы предлагали делать 2 модели реальности:
- Аналитическую модель, что концентрируется на том, что делают процессы и используется бизнес-аналитиками
- Дизайн модель, что отвечает за IT-реализацию, включая потоки данных, логику решений и специфику имплементации

В общем, это была попытка от бизнес-процессов прыгнуть к реализации поверх сервисов через генерацию BPEL кода, но последняя версия BPEL вышла в 2007 году, то есть подход оказался нерабочим, так как остались незакрытыми вопросы, подсвеченные открытыми внутри самой статьи
- Поддержание согласованности между бизнес-моделями и кодом (round-tripping)
- Определение оптимальной детализации сервисов
- Обеспечение качества моделей (выявление ошибок проектирования)
- Улучшение визуализации больших моделей и поиск в их коллекциях

Хотя авторы предсказывали, что дальше модель станет кодом, где графические и текстовые элементы будут объединены в единую систему, а переходы между уровнями абстракции поддерживаются методами обеспечения качества.

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

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

#Management #Architecture #ArchBook #Retrospective #History #Processes #Software

Обложки для книг "Taming Silicon Valley: How We Can Ensure That AI Works for Us" и "Большой обман больших языковых моделей"

Taming Silicon Valley: How We Can Ensure That AI Works for Us (Большой обман больших языковых моделей)

Прочитал на днях эту книгу Гэри Маркуса, изданную в MIT Press в сентябре 2024 года, то есть буквально на днях:) Книга представляет собой критическое исследование социальных и этических вызовов, связанных с искусственным интеллектом (ИИ), и его развитием под контролем крупных технологических компаний. Сам Гэри - это американский психолог, когнитивист, писатель и предприниматель, известный своими исследованиями на пересечении когнитивной психологии, нейронауки и искусственного интеллекта (ИИ). Он является профессором-эмеритом кафедры психологии и нейронауки Нью-Йоркского университета и основателем компании Geometric Intelligence, которая была приобретена Uber в 2016 году.

Ключевые идеи книги примерно такие
1) У AI есть две медали - с одной стороны он может привести к революции в естественных науках, технологиях, медицине и так далее. А с другой стороны он несет с собой значительные риски, например, распространение дезинформации, киберпреступности, подрыв демократии, а также экзистенциальная угроза всему человечеству
2) Критика крупных технологических компаний. В книге утверждается, что основные технологические компании ставят прибыль выше этических соображений, выпуская системы ИИ преждевременно в гонке за рыночным доминированием. Это приводит к созданию ненадежных технологий с внутренними недостатками, которые усугубляют общественные риски. Маркус критикует культуру Кремниевой долины, ориентированную на быструю прибыль, часто игнорирующую долгосрочные последствия ради краткосрочной выгоды. Интересно, что эта критика даже вынесена в название книги
3) Пробелы в регулировании. Маркус рассказывает о том, как крупные технологические компании эффективно «захватили» политиков через лоббизм, маркетинг и обещания саморегулирования, что привело к слабым или отсутствующим механизмам управления ИИ. Он подчеркивает необходимость создания надежного регулирования для решения таких вопросов, как конфиденциальность данных, дезинформация и вытеснение рабочих мест.
4) Гэри предлагает следующий план действий
- Установление сильных прав на данные.
- Введение многоуровневого надзора за системами ИИ.
- Проведение значимых налоговых реформ для крупных технологических компаний.
- Продвижение прозрачности и ответственности в разработке ИИ.
- Приведение ИИ в соответствие с правами человека и этическими принципами.
Также он выступает за общественное давление для стимулирования регуляторных действий, утверждая, что граждане должны требовать ответственности как от правительств, так и от корпораций.
5) Моральный упадок Кремниевой долины. Маркус исследует «моральное падение» Кремниевой долины, прослеживая её переход от целей инноваций к эксплуататорским практикам, направленным на извлечение ценности за счет общественного благополучия.
Укрепление позиций граждан:
6) Книга является призывом к действию для обычных граждан: лучше понимать технологии ИИ и выступать за их этичное использование.

На самом деле Маркус написал эту книгу с чувством срочности из-за быстрого внедрения технологий генеративного ИИ и их последствий для демократии и общества перед важными политическими событиями, такими как выборы. И в целом книга "Укрощение Кремниевой долины" служит одновременно критикой современных практик в области ИИ и манифестом о необходимости создания этической структуры для того, чтобы ИИ приносил пользу человечеству вместо эксплуатации общества.

#Management #Strategy #Leadership #Vision #Bigtech #AI #ML

Code of Leadership & Research Insights Made Simple (Рубрика #Management)

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

Code of Leadership
- Видео: Youtube, Vk Video
- Аудио: Podster, Ya Music
Описание отдельных эпизодов
01) "Team topologies" со Станиславом Халупом
02) "Antifragility in IT" с Александром Бындю
03) "Herding Cats" с Женей Кузовлевым
04) "Turn the ship around" с Екатериной Шестимеровой
05) "Project Phoenix" с Иваном Михеевым
06) Интервью про Staff+ инженеры, архитектура и SDLC с Алексеем Тарасовым
07) "Your brain at Work" с Эрнесто Инаркиевым
08) Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)
09) "An Elegant Puzzle - System of Engineering Management (часть 1)" с Eugene Sergueev
10) "An Elegant Puzzle - System of Engineering Management (часть 2)" с Eugene Sergueev
11) Интервью с Кириллом Крайневым про системных аналитиков в Тинькофф
12) Интервью с Димой Гаевским про платформу Spirit (Internal developer platform) в Тинькофф
13) "Accelerate" с Игорем Курочкиным
14) Interview with Artem Ivanov about Risk Tech
15) Interview with Roman Lebed about Information security
16) "The Five Dysfunctions of a Team" с Андреем Соколовым
17) Interview with Anton Kosterin about Architecture Governance
18) Interview with Pavel Akhmetchanov about Processes and Tools
19) Interview with Evgeny Sokolov about Modern Education
20) Interview with Alexey Grishin about Software Architecture
21) "A Philosophy of Software Design" с Гришей Скобелевым
22) Интервью с Дмитрием Аношиным про data engineering
23) Interview with Andrew Marchenko
24) Interview with Konstantin Evteev
25) Interview with Anastasia Kabishcheva about group dynamics and BART Model
26) Interview with Salikh Fakhrutdinov about SRE Growth and SRE Team

Reserach Insights Made Simple
- Видео: Youtube, Vk Video
- Аудио: Podster, Ya Music
Описание отдельных эпизодов
01) Обсуждение paper "API Governance at Scale" от Google
02) Обсуждение paper "Defining, measuring and managing technical debt"
03) Обсуждение paper "Security by Design at Google"
04) Обсуждение "AI-Enhanced API Design" от Google
05) Обсуждение "DORA Metrics, SPACE, DevEx, Human Approach to Dev Productivity"
06) Interview with Nikolay Golov about data platforms
07) Interview with Pavel Lakosnikov about Architecture Governance

#Architecture #Processes #Management #Leadership #Software #Statistics #Project #Productivity #ProductManagement

Поучаствовал в поздравлении с Новым Годом, что организовывал Гриша Скобелев и сообщество { между скобок }. Порекомендовал новую книгу Влада Хононова про balancing coupling in software design:)

Поздравляем с наступающим Новым Годом 2025! 🍾🎄🎉

Всем счастья, мира и чтобы все что вы задумали в новом году сбылось.

Полезные ссылки
- Разбор книги "От монолита к микросервисам"
- Разбор книги "Postgres Internal"
- Разбор книги "Learning DDD"
- Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems
- https://t.me/book_cube
- https://lisp-lang.org
- https://www.haskell.org
- Логика неудачи. Книга о стратегическом мышлении в сложных ситуациях
- Мониторинг PostgreSQL https://postgrespro.ru/education/books/monitoring
- Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО | Стэньер Джеймс
- https://t.me/antonovjs
- https://t.me/olezhek28go

Видео уже на YouTube

Amazon Aurora DSQL (Рубрика #Data)

Вернер Вогель, CTO Amazon, в своем keynote на re:Invent 2024 полчаса рассказывал про новые возможности базы Aurora, которая появилась порядка 10 лет назад, а теперь перещла в класс newSQL и стала по фичам напоминать Google Spanner, который как раз появился больше 10 лет назад. Вот какие фичи выделял Вернер
1) Serverless Architecture - для автоматического масштабирования под нужные нагрузки
2) High Availability - для одного региона 99.99% availability, для мультирегионального master-master сетапа 99.999%
3) PostgreSQL Compatibility - полная подддержка PostgreSQL
4) Performance - обещают 4х скорость по сравнению с другими похожими решениями, видимо, из мира newSQL. Я бы глянул на бенчмарки, чтобы понять с кем они сравнивались:)
5) Active-Active Multi-Region Operations - собственно, мультирегиональный вариант, который может принимать записи и реплицировать их в реальном времени (интересно глянуть насколько это быстро работает в мультирегиональном исполнении)
6) Zero Infrastructure Management - пользователям не надо думать об инфре (кроме как сколько это счастье будет стоить)
7) Innovative Transaction Processing - здесь Вернер пафосно рассказыва про аналог гуглового TrueTime, что был еще 10+ лет назад в Google Spanner. Теперь у Amazon есть свои спутники и атомные часы для микросекундной точности и все это называется Amazon Time Sync Service. Это и позволяет сделать распределенные транзакции с хорошими гарантиями консистентности:)

P.S.
Про Aurora я уже часто упоминал раньше
- Бонусный выпуск Code of Architecture по white paper "Amazon Aurora: Design Considerations for High Troughput cloud-Native Relational Databases"
- AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344)

#Databases #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #Cloud #Management #Leadership

Data завтрак в T-Space 13 января (Рубрика #Data)

Мы в Т-Банке начнем новый год митапом про данные, который пройдете 13 января в формате завтрака. На мероприятии будет 2 доклада
1) Дмитрий Аношин, основатель консалтинговой компании Rock Your Data (Северная Америка), специализирующейся на облачной аналитике, представит обзор аналитических решений, инструментов и подходов к формированию команд. Вы узнаете о построении эффективных аналитических команд, преодолении сложностей и разработке архитектур аналитических систем. Дима ведет отличный канал "Инжиниринг Данных" (@rockyourdata), на который я подписан уже давно. Кстати, Дима привез мне в подарок бумажную версию книги Влада Хононова "Balancing Coupling in Software Design", так что к концу новогодних каникул можно ожидать ее обзор.
2) Валерий Поляков, CDO в Т-Банке, поделится опытом трансформации платформы данных в Т-Банке: от централизованных вендорских решений до сложной экосистемы open-source компонентов. С 2011 года он работает с данными в разных ролях: от построения отчетности и хранилищ данных до разработки аналитических продуктов. В Т-Банке Валерий работал с 2012 по 2019 год, а затем вновь присоединился к команде в 2022 году.

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

#Database #Datamesh #Data #Processes #Conference

AWS re:Invent 2024 - Dr. Werner Vogels Keynote (Рубрика #Architecture)

Несколько недель назад Dr. Werner Vogels, CTO Amazon, выступил на AWS re:Invent с рассказом о концепции simplexity, к которой он пришел за 20 лет работы в Amazon. Само это слово представляет комбинацию двух слов: complexity и simplicity. По-факту, весь цимес в том, чтобы продукты выглядели просто для клиентов, а вся сложность была за сценой. Ну и дальше Вернер рассказывает про шесть принципов и показывает на примерах из AWS как они применяются на практике. Вот эти шесть принципов:

1) Make flexibility a requirement
Единственная постоянная вещь в наашем мире - это изменения, поэтому дизайнить системы надо так, чтобы они были готовы к эволюции технологий, рабочих нагрузок, а также требований пользователей. По-факту, это очень близко с концепциями Continuous Architecture или Evolutionary Architecture. Кстати, обе книги мы разбирали в клубе "Code of Architecture": 1 и 2 соответственно
2) Break complexity into pieces
Это стандартный подход "разделяй и властвуй". Вернер предлагает делить крупные и комплексные системы на части поменьше, которые легче понимать, поддерживать, масштабировать и которыми в принципе проще управлять. Но важно их объединять в loosely coupled стиле. А сами компоненты должны быть с high cohesion внутри. Рекомендую на эту тему почитать книгу Джона Остерхута "A philosophy of software design", которую мы тоже уже разбирали
3) Align organization to architecture
Здесь Вернер Вогель описывает применение обратного маневра Конвея. По-факту, нам надо подстраивать оргструктуру под желаемую архитектуру, что позволяет командам принять на себя ответственность и владение доменами, а также позволит им работать автономно. Я рассказывал про это уже раньше в своем докладе "Как формировать структуру команд под запросы бизнеса"
4) Use a cell-based architecture design
Эта концепция про использование так называемых cells для построения отдельных изолировоанных блоков, которые могут автономно принимать часть нагрузки. Важно, что они достаточно малы, чтобы радиус поражения (blast radius) был не слишком высок, но одновременно не слишком малы, чтобы обслужить максимального размера запрос и получать экономию на масштабе.
5) Design predictable systems
Вернер предлагает дизайнить предсказуемые системы, что уменьшает влияние неопределенности и позволяет обеспечить консистентность при эксплатации систем.
6) Automate everything that doesn’t require high degrees of judgment
Цель в том, чтобы дефолтом стала автоматизация процессов и исключение human in the loop, а люди привлекались только в моменты, когда требуется принятие решений

По большей части Вернер демонстировал эти принципы на примере AWS S3 (Simple Storage Service), а также на примере Amazon Aurora DSQL

#Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #Cloud #Management #Leadership

ЦЕХ 4 - Урок #27 "Книга издана. Что теперь?. Эксперт — Дмитрий Утробин" (Рубрика #Writing)

Финальным уроком курса для авторов книг от издательства МИФ был урок про то, а что делать, когда книга уже издана. Урок вел Дмитрий Утробин, партнер и содиректор МИФа. Вот что я вынес для себя из финального урока

1) В России высокая конкуренция на книжном рынке - каждый год выходит примерно 100к книг. Читателям сложно ориентироваться в этом разнообразии и автор и издательство заинтересованы в том, чтобы помочь книге найти аудиторию
2) У книг долгая оборачиваемость - от создания рукописи до книги на полке проходит около года. А это значит, что книга - это долгий инвестиционный проект для издательства
3) На книжном рынке низкая прозрачность - традиционные игроки редко деляться своей статистикой
4) Для того, чтобы выделиться на рынке можно использовать упоквку книги, дизайн обложки, активный маркетинг и правильную дистрибуцию
5) Бумажные книги составляют примерно 80% выручки издательства, а сама цепочка продаж включает издательство, дистрибьютора (наценка 20–25%) и магазин (наценка 80–140%). Для продаж бумажных книг важно представление их на полках магазинов и поддержание оптимального товарного запаса.
6) Электронные и аудиокниги составляют 10–20% выручки. Их стоимость постепенно выросла до 50–70% от цены бумажных версий.
7) Аудиокниги активно развиваются с темпами роста 40–70% в год благодаря удобству приложений для прослушивания.
😍 Федеральные сети («Читай-город», «Буквоед») доминируют, но независимые книжные магазины становятся культурными центрами и лидерами мнений.
9) Маркетплейсы («Озон», «Вайлдберриз») растут быстрыми темпами, но требуют особого подхода к продвижению.
10) Интересен опыт МИФа, где собственный интернет-магазин обеспечивает 35% оборота компании, что позволяет быстро получать обратную связь и адаптировать маркетинговые стратегии. Вообще, выгодно иметь прямую точку взаимодействия с покупателями/клиентами:)
11) Проведение культурных мероприятий с участием авторов помогает укрепить связь с читателями.
12) Автору важно участвовать в продвижении своей книги, так как он лучше всех может рассказать о своём произведении.

На этом курс для меня закончен, а написание книжек все еще in progress:)

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

P.S.
Сейчас открыта запись на курс ЦЕХ #5, который стартанет в марте 2025 года. Если вы планировали написать свою книгу, то этот курс вам может в этом помочь:)

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Несведущий маэстро (The ignorant maestro: How great leaders inspire unpredictable brilliance) - Part II (Рубрика #Management)

Внезапно я решил продолжить рассказ про книгу "Несведущий маэстро" ("The ignorant maestro"), про которую писал уже год назад. Это обусловлено лекцией Сергея Бурлака, музыканта, бизнес-тренера и автора канала "МузДиета" (@musicdiet). Я был на этой лекции в четверг вечером и Сергей рассказывал о стилях лидерства, показывал видео великих дирижеров и даже сам исполнял музыку. Основой выступления была третья часть книги "Несведущий маэстро", в которой приводилось следующи 6 стилей лидерства

1. Доминирование и контроль: Риккардо Мути
Риккардо Мути представляет модель лидера, который берет на себя полную ответственность и требует абсолютного контроля. Он настаивает на единственно правильной интерпретации и не допускает отклонений от своих указаний. Такой стиль обеспечивает точность исполнения, но подавляет инициативу и творчество подчиненных. Это приводит к необходимости постоянного контроля со стороны лидера, что может истощать как его самого, так и коллектив. Характерно, что когда Риккардо решили убрать из "Ла Скала" из-за конфликта, то никто из его сотрудников не вступился за него.
2. Крёстный отец: Артуро Тосканини
Артуро Тосканини воплощает стиль строгого, но заботливого лидера. Он относился к своему коллективу как к семье, требуя дисциплины и безупречности, но одновременно проявляя глубокое уважение и поддержку. Его эмоциональность мотивировала музыкантов выкладываться на полную, а его требования воспринимались как стремление к общему совершенству, а не как тирания.
3. Согласно инструкции: Рихард Штраус
Рихард Штраус демонстрирует стиль лидера с четкими инструкциями. Он избегал излишней эмоциональности и личных интерпретаций, предпочитая следование заранее разработанному плану. Такой подход обеспечивает стабильность и безопасность, но ограничивает творческую свободу и инициативу коллектива.
4. Гуру: Герберт фон Караян
Герберт фон Караян характеризуется как лидер без явных инструкций. Он ожидал от музыкантов интуитивного понимания его видения и самостоятельной синхронизации действий. Это развивало в коллективе взаимное слушание и ответственность за общий результат, но могло вызывать стресс из-за отсутствия четких ориентиров.
5. Танец лидера: Карлос Клайбер
Карлос Клайбер представлял собой лидера в потоке — он вел коллектив за собой через совместное творчество, предоставляя каждому участнику свободу для интерпретации. Его стиль напоминал танец, где каждый был автономным, но взаимозависимым. Это требовало высокого уровня доверия и ответственности от всех участников процесса. Интересно, что тут у Сергея Бурлака был другой пример с женщиной дирижером, но смысл был примерно в том же, только стиль назывался в стиле "Каждый голос будет услышан"
6. В поисках смысла: Леонард Бернстайн
Леонард Бернстайн воплощал стиль чуткого лидера, который видел в каждом члене команды личность со своими уникальными качествами. Он строил диалог на эмоциональном, интеллектуальном и моральном уровнях, вдохновляя людей искать смысл в своей работе. Такой подход стимулировал развитие индивидуальности, но требовал значительных усилий для поддержания взаимопонимания.

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

P.S.
Более подробный обзор этих стилей лидерства можно прочитать в статье на Lifehacker, там же есть видеозаписи выступлений дирижеров с их оркестрами.

#Management #Processes #Leadership #Self

Щелкунчик в Большом Театре (Рубрика #Culture)

Вчера был на балете Щелкунчик Петра Ильича Чайковского в Большом Театре вместе с женой. Мне понравилась музыка, декорации и само действие - было ощущение, что проваливаешься в детскую сказку, где Щелкунчик выходит на бой против Мышиного Короля. Правда, мне показалось, что было мало накала и драмы - условно, Мышиный Король пал смертью храбрых в первой четверти второго акта, а все оставшееся время шли праздненства в честь Щелкунчика и его избранницы:) В Лебедином Озере, на котором я был год назад в Большом тоже перед Новым годом напряжение держалось сильно дольше:) Но это я так ворчу, а вообще история была очень красивой и праздничной. Рекомендую к просмотру:)

#Culture #Theater

Satya Nadella | BG2 w/ Bill Gurley & Brad Gerstner (Рубрика #AI)

Интересное интервью CEO Microsoft, что Сатья Наделла дал двум венчерным инвесторам Bill Gurley и Brad Gerstner. В самом интервью много интересного, но основными были следующие темы:
1) Назначение генеральным директором Microsoft
Наделла делится своим опытом, включая стратегическую записку, направленную в комитет по выбору CEO, и трансформацию компании под его руководством с 2014 года, что привело к значительному увеличению доходов, прибыли и рыночной стоимости. Кстати, про это можно почитать книгу Сатья Наделлы "Hit Refresh", про которую я рассказывал раньше
2) Искусственный интеллект и OpenAI
Сатья и ведущие обсуждают инвестиции Microsoft в OpenAI, гонку вооружений в области ИИ и будущее ИИ-агентов. Наделла подчеркивает трансформирующий потенциал ИИ как для потребительских, так и для корпоративных приложений. Про это подробнее ниже
3) Будущее SaaS и ИИ-агентов
Наделла прогнозирует, что ИИ революционизирует SaaS (программное обеспечение как услуга), разрушая традиционные категории приложений и позволяя ИИ-агентам управлять бизнес-логикой через несколько баз данных.
4) Советы для генеральных директоров
Он делится своими мыслями о лидерстве, акцентируя внимание на понимании структуры рынка и использовании партнерств для достижения успеха.
В ходе беседы также рассматриваются стратегия капитальных расходов Microsoft, безопасность ИИ и дальнейшие шаги в развитии OpenAI.

А теперь подробнее про фразу "SaaS is dead", которая суммаризирует мнение Сатьи о дальнейшем развитии enterprise приложений как сервисы. Это мнение раскладывается на следующие тезисы
1) AI Replacing Static Business Logic
Наделла утверждает, что многие SaaS-приложения по сути являются базами данных CRUD (создание, чтение, обновление, удаление) с заранее определенной бизнес-логикой. Он прогнозирует, что ИИ-агенты возьмут на себя управление этими статическими процессами, динамически обрабатывая бизнес-логику через несколько баз данных, что сделает традиционную архитектуру SaaS менее актуальной
2) Shift to AI-First Architectures
В нашем будущем, бизнес-приложения уйдут от статических моделей, с ориентацией на приложения к системам, что ориентированы на агентов. Эти агенты буду выполнять роль интеллектуального слоя, который будет хранить состояние и выполнять оркестрацию запросов к внешним приложениям, чтобы выполнять задачи автономно без заренее прописанных вручную workflow
3) Collapsing Back-End Systems
По мере успешной работы агентных систем потребность в стандартных бизнес-приложениях с кучей коннекторов и интеграцией между ними уменьшится. Теперь агенты смогут сами интегрировать эту функциональность. По-факту, мне все это напоминает чем-то напоминает переходы, что были раньше
- Когда-то был толстый клиент и тонкое приложение, что, по-факту, только хранило данные
- Потом мы пошли в сторону тонких клиентов и большого количества логики на бекенде
- Потом бекендов стало много и им надо было уметь дружить с собой
- А в новом агентном мире бекенды смогут стать простыми, а вся сложность координации вернется на клиента (на агентнскую систему, что выполняет запросы от имени клиента)
4) Transformation of Tools and Processes
Такие инструменты, как Excel, могут превратиться в платформы, где ИИ-агенты выполняют сложные задачи — от планирования до анализа и исполнения. Например, интеграция Python в Excel уже демонстрирует такие изменения
5) Opportunities for Innovation
Хотя этот переход может нарушить существующие модели SaaS, он также открывает возможности для создания адаптивных решений с приоритетом ИИ. Компании, которые примут этот переход, будут лучше подготовлены к новой парадигме

В итоге, Сатья скорее говорит не про смерть SaaS, а про перерождение в более динамичную и интеллектуальную систему под управлением ИИ. Это знаменует значительную эволюцию в проектировании и использовании программного обеспечения. По-моему мнению, это очень интересно влияет на архитектуру и дизайн софта, но об этом как-нибудь в следующий раз.

#Management #Strategy #Leadership #Vision #Bigtech

Обложки книг "Культурный код" и "The Culture Code: An Ingenious Way to Understand Why People Around the World Live and Buy as They Do"

Культурный код (The Culture Code: An Ingenious Way to Understand Why People Around the World Live and Buy as They Do) (Рубрика #Management)

Книга Клотера Рапая "Культурный код: Как мы живём, что покупаем и почему" раскрывает концепцию культурного кода, который представляет собой бессознательный смысл, придаваемый объектам или явлениям в рамках конкретной культуры. Автор книги, Клотер Рапай - французский психоаналитик, маркетолог и бизнес-консультант, который известнен как раз этой теорией «культурных кодов». Он родился во Франции в 1941 году, но позже эмигрировал в США, где построил свою карьеру. Рапай является основателем и CEO компании Archetype Discoveries Worldwide, которая занимается исследованием культурных архетипов и их применением в маркетинге. В этой книге он описывает свою концепцию в научно-популярном стиле и раскрывает основные идеи

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

Вот несколько примеров из книги, когда Клоттер описывает конкретные коды, которые он получал в рамках своих исследований по заказам брендов

1) Коды любви, обольщения и секса
1.1) Любовь
- В США любовь ассоциируется с обманутыми ожиданиями.
- Во Франции любовь связана с удовольствием.
- В Италии — с весельем.
- В Японии любовь воспринимается как временная болезнь.
1.2) Обольщение. В американской культуре обольщение связано с манипулированием. Например, компания L'Oréal адаптировала свою рекламу в США, делая акцент на уверенности женщины в себе, а не на соблазнительности.
1.3) Секс. Код секса в США — насилие, что объясняет более терпимое отношение американцев к насилию по сравнению с сексуальностью.

2) Коды красоты и лишнего веса
2.1) Красота. В американской культуре красота ассоциируется со спасением мужчины, так как считается, что женщина может сделать мужчину лучше.
2.2) Лишний вес. Код лишнего веса — бегство от проблем и неудач.
3) Коды молодости и здоровья
3.1) Здоровье
- В США здоровье связано с движением, поэтому продукты, связанные с мобильностью, популярны среди американцев.
- В Китае здоровье ассоциируется с гармонией с природой.
-В Японии здоровье воспринимается как долг перед семьей и обществом.
3.2) Молодость. Молодость в американской культуре символизирует энергию и стремление к новым достижениям.

В итоге, сам автор книги использует культурные коды для создания успешных рекламных кампаний, поскольку они позволяют брендам адаптировать свои сообщения к особенностям восприятия целевой аудитории в разных культурах. Это позволяет
1) Учитывать национальные особенности и ассоциации
2) Адаптировать сообщения для разных культур
3) Использовать локальные образы и традиции
4) Стремиться к созданию эмоционального резонанса
5) Избегать провалов благодаря чувствительности к культуре и ее кодам

#Culture #PopularScience #Management

ЦСКА - СКА (Рубрика #Sport)

Выбрался на хоккейный матч с сыном и друзьями, опоздал на папу минут к началу и пропустил обе стартовые шайбы. Так матч для меня начался с 2:0, а через 10 минут я дождался еще одной шайбы, которую уже увидел.

#ForKids #Sport

Research Insights Made Simple #7 - Interview with Pavel Lakosnikov about Architecture Governance (Рубрика #Architecture)

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

За время подкаста мы обсудили темы:
- Как Павел начал свою карьеру в IT
- Как дизайн игр связан с архитектурой
- Как от надежности приложений перейти к их архитектуре
- Как мерить надежность и архитектуру, какие метрики бывают
- Зачем нужны процессы и стандарты
- Как происходит эволюция процессов разработки
- В чем роль платформ при создании сложных систем
- Какие советы можно дать инженерам, что хотят прокачивать свои навыки

P.S.
Выпуск доступен в виде подкаста в podster.fm, а чуть позже будет и на Yandex Music.

#Architecture #Software #Evolution #Management #Governance #Management #Leadership

От продуктов к JBTD или как поток изменений влияет на структуру компании (Рубрика #Management)

В прошлом году на YaTalks 2023 я уже рассказывал про то, как формировать структуру команд под запросы бизнеса. В конце этого лета я рассказывал о том, как выглядит схема управления Т-Банком сейчас. А в этой статье я хотел бы рассказать о том, а как она трансформировалась со временем и куда мы движемся сейчас. В своем описании я буду использовать концепцию матричного управления, но баланс матрицы будет постоянно меняться:)
В новой статье есть рассказ про три структуры
1) Функциональная организация - этот этап я назвал "горизонтальным"
2) Продуктовая организация - этот этап я назыал "вертикальным"
3) Организация, ориентированная на сценарии (JBTD) или сегменты - этот этап я назвал "диагональным"

#Management #Architecture #Software #Engineering

Муми-тролль и Рождество (#ForKids)

Мы были вчера с младшим сыном на постановке "Муми-тролль и Рождество" в театре "Доммик Фанни-Белл" и нам очень понравилось. В рождественскую пору к актерам Фанни-Белл иногда приезжают гости и в этот раз это был театр «Karlsson Haus» из Санкт-Петербурга, который привез с собой этот спектакль по мотивам произведений Туве Янссон.

Основная суть спектакля в том, что обычно Муми-тролли как медведи зимой впадают в спячку и пропускают зимние праздники. Но в этот раз они заснули, а потом проснулись и пораньше и застали подготовку все долины Муми-троллей к приходу Рождества, чтобы это ни значило. У них возникли вопросы
- А кто это такой?
- Почему его надо радовать подарками?
- Зачем нужна елка и во что ее надо одевать?
- Опасен ли этот неведомый зверь, если все обитатели долины так бояться не успеть подготовиться к его приходу?

В итоге, муми-тролли решают снизить риски и проявить конформизм - они начинают готовиться к рождеству на всякий случай. А потом они узнают, что это лучший праздник на свете, а еще в гости приходит Санта-Клаус (Дед Мороз, Йоулупукки, ...) и дарит всем подарки.

P.S.
Мы любим постановки в теаре "Домк Фанни-Белл" и наши дети тоже их любят. Постановки отлично подходят для дошкольников и поэтому мы уже по второму разу смотрим многие спектакли - первый раз был со средним сыном, а теперь настала очередь младшего:)

#ForKids #ForParents #Culture #Theater

Продолжение Woke, Inc. или подробнее про DOGE (Department of Government Efficiency) (Рубрика #Management)

В предыдущем посте я рассказывал про книгу Вивека Рамасвами "Woke, Inc.". А в этом посте хотел чуть подробнее поговорить про DOGE, консультативной комиссии, цель которой в сокращении бюрократии, снижении неэффективных расходов и упрощении работы федерального правительства. Руководить этой комиссией будут 2 человека
- Илон Маск - генеральный директор Tesla и SpaceX, известный своей поддержкой дерегуляции.
- Вивек Рамасвами - предприниматель и бывший кандидат в президенты, сторонник политики минимального вмешательства государства.

Основные цели комиссии следующие
- Сокращение федеральных расходов за счёт устранения дублирующих регуляций и агентств.
- Уменьшение численности федерального персонала, с предложением сократить его на 75%.
- Консолидацию федеральных агентств с более чем 400 до менее чем 100.
- Консультирование по вопросам дерегуляции для повышения эффективности и снижения затрат. Руководители комиссии говорят оценивают эффект в 2$ трлн долларов из федрезерва США.
- Реформа Diversity, Equity, and Inclusion (DEI): одной из ключевых целей является полное устранение расходов на инициативы в области разнообразия, равенства и инклюзии (DEI). Это включает ликвидацию соответствующих подразделений в таких ведомствах, как Министерство здравоохранения и Министерство обороны.
- Прозрачность работы DOGE: Все действия министерства будут освещаться онлайн для обеспечения максимальной прозрачности. Это позволит гражданам следить за ходом реформ в режиме реального времени.

DOGE будет работать до 4 июля 2026 года, что совпадает с 250-летием Соединённых Штатов. Трамп описал эту дату завершения как символическую для миссии быстрого достижения эффективности. Не так уж долго придется подождать, чтобы оценить насколько удастся задуманное этими джентельменами:)

Правда, есть ряд проблемок на пути к реализации задуманного
- DOGE не обладает прямыми регуляторными или исполнительными полномочиями, поэтому его роль ограничивается предоставлением рекомендаций.
- Предложения по сокращению программ социального обеспечения или дискреционных расходов могут столкнуться с серьёзным политическим сопротивлением.
- Юридические вызовы могут возникнуть при попытках обойти одобрение Конгресса для реализации некоторых мер дерегуляции.

Рамасвами сравнивает масштабность этих реформ с Манхэттенским проектом времен Второй мировой войны, подчеркивая их потенциальное влияние на всю страну. Он считает, что главной проблемой США является раздутая бюрократия, которая мешает эффективному управлению государством. Таким образом, DOGE под руководством Рамасвами и Маска нацелен на радикальное преобразование структуры управления США с упором на сокращение расходов, упрощение процессов и повышение прозрачности работы правительства.

#Management #Leadership #Thinking

Обложки книг "Woke, Inc. За фасадом корпоративной риторики о социальной справедливости" и "Woke, Inc.: Inside Corporate America's Social Justice Scam"

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

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

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

#Architecture #DistributedSystems #SystemDesign #Engineering #Software

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

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

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

#ForKids #ForParents #Humor

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

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

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

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

#PopularScience #Physics #History

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

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

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

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

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

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

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

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

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

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

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

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

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

#Whitepaper #Architecture #Management #Science

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#SelfDevelopment

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

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

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

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

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

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

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

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

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

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

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

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

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

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

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

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

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

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

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

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

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

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

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

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

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

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

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

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

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

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

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

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

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

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

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

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

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

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

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

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

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

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

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Обложки для книг "Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity" и "Радикальная прямота"

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity (Радикальная прямота) (Рубрика #Management)

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

Часть I - Новая философия менеджмента
1. Выстраивание радикально откровенных отношений. В этой главе описывается основная идея книги - важность сочетания личной заботы о сотрудниках с прямым вызовом. Автор объясняет, как это помогает улучшать рабочие отношения и повышать производительность команды.
2. Получать, отдавать и помогать. Эта глава посвящена методам установления доверительных отношений в команде, что является основой для успешного применения радикальной откровенности. Для этого автор описывает модель, которая визуализируется как двухмерный график. На графике вертикальная ось представляет "Личную заботу", а горизонтальная ось - "Прямой вызов". Цель состоит в том, чтобы работать в квадранте, где оба элемента высоки, создавая среду открытой и конструктивной обратной связи. Это и есть квадрант радикальной откровенности, а также есть разрушительное сочувствие, оскорбительная агрессивность и манипулятивная неискренность.
3. Что мотивирует каждого члена вашей команды. Здесь автор приводит свою модель суперзвезд и надежных сотрудников: фактически есть "суперзвезды", которые находятся на крутой траектории роста, и "надежные сотрудникы", которые предпочитают стабильность и устойчивую производительность. Признание этих различий помогает эффективно управлять ростом команды.
4. Добиться успеха вместе. В этой главе автор рассказывает про свою модель работы с людьми в команде "Выслушать" - "Объяснить" - "Обсудить" - "Решить" - "Убедить" - "Выполнить" - "Усвоить" и дальше опять "Выслушать". На протяжении всей главы автор рассказывает как должен работать этот цикл в компании.

Часть 2 - Инструменты и техники
5. Взаимоотношения. Эта глава посвящена построению и поддержанию эффективных отношений в команде. Автор подчеркивает важность доверия и открытого общения между коллегами. Она предлагает стратегии для улучшения взаимодействия, чтобы создать более сплоченную и продуктивную рабочую среду.
6. Наставничество. В этой главе рассматривается роль наставничества в развитии сотрудников. Автор объясняет, как руководители могут эффективно наставлять своих подчиненных, помогая им расти и развиваться в профессиональном плане. Она делится методами, которые позволяют вдохновлять и мотивировать сотрудников через личный пример и поддержку.
7. Команда. Глава фокусируется на создании эффективных команд. Автор обсуждает, как собрать команду, которая будет работать слаженно и продуктивно, а также как управлять различиями в характерах и навыках сотрудников. Автор подчеркивает важность разнообразия и инклюзивности для достижения лучших результатов.
8. Результаты. Заключительная глава посвящена достижению результатов через применение принципов радикальной откровенности. Автор делится инструментами и техниками, которые помогают руководителям не только устанавливать высокие стандарты, но и достигать их вместе с командой. Она акцентирует внимание на том, как измерять успех и корректировать подходы для постоянного улучшения.

Интересные факты о книге
- Ким Скотт активно использует свой опыт работы руководителем в bigtech компаниях, таких как Google и Apple.
- Она подчеркивает необходимость адаптации радикальной откровенности к различным культурным контекстам, чему она научилась в процессе работы с разнообразными командами по всему миру
- Книга не только теоретическая - она включает практические инструменты, такие как сценарии для сложных разговоров и основы для эффективных встреч.

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

Вакансия партнера по работе с данными (Рубрика #Vacancy)

В Т-Банке мы привыкли принимать решения на основе данных, а данных от 46+ млн клиентов и целой экосистемы продуктов у нас очень много. Для того, чтобы использовать более эффективно мы переносим ответственность за данные с централизованной дата платформы в сами домены. Мы считаем, что это позволит эффективнее работать с данными в каждом из направлений, за счет синка с продактами, аналитиками, разработчиками приложений. По-факту, в моей домен входят
- Клиентские интерфейсы: платформенные команды веба, мобилы и API
- Маркетинговые технологии: внешняя реклама, маркетинговая платформа
- Соц-медиа платформы: социальные сети, медиаплатформа, медиапроекты (ТЖ, Бизнес-секреты), игры
- Цифровые экосистемы: аутентификация/авторизация, биометрия, главная страница приложения, финздоровье
- Продуктовая аналитика и a/b платформа

В итоге, я ищу к себе человека, который поможет мне составить стратегию по работе с данными внутри этих доменов так, чтобы мы как компания получили дополнительный value. А дальше этот партнер по данным будет помогать реализовывать эту стратегию силами команд разработки внутри моего домена, используя инструменты дата платформы, которая сейчас уходит от стандартного DWH подхода в сторону data lake и lake house. Например, в этому году мы уже перенесли ответственность за отгрузку данных на сторону команд разработки, а также реализовали в новых инструментах (streaming data platform) возможность задавать контракты данных. Если выкинуть за скобки старые интеграции через базу (которых большинство), то мы уже живем в мире, где поток данных в data platform - это контракт примерно такой же, как публичный REST API. И на проблемы с этим контрактом реагируют продуктовые SRE команды. Собственно, у data platform есть еще много планов по тому, как нам двигаться в сторону data mesh технологически, а мне нужен помощник, что будет помогать мне двигать мои продуктовые команды в эту сторону светлого будущего.

Если приземляться на грешную землю, то успешному кандидату придется
- Выстраивать стратегию работы с данными, управления ими и эксплуатации в контексте домена
- Отвечать за people management: участвовать в процессах найма, развития и оценки, проводить one-to-one-встречи
- Выявлять проблемы и прогнозировать их
- Оптимизировать взаимодействие команд направления и платформы данных
- Собирать фидбэк от пользователей и заносить его в платформу
- Регулярно проводить аудит процессов или автоматизировать его
- Прогнозировать затраты ресурсов — например, в случае открытия нового продукта в своем направлении
- Участвовать в проектировании архитектуры данных домена и обеспечивать ее связность с данными организации

Само собеседование будет состоять из трех этапов:
- System design interview - тут нужно будет показать умения в дизайне несложных систем. Я много рассказывал про этот вид интервью
- Data architecture и технологии - здесь нужно будет тоже решить задачку о том, как спроектировать data архитектуру решения для построения аналитики по одному из доменов, а также про распределение ответственности между ролями
- Engineering management - этот тип интервью мы даем для руководителей, кто уже управлял несколькими командами. Я про него тоже рассказывал.

Если вам понравилась вакансия, то пишите в личку @apolomodov

P.S.
Для того, чтобы лучше понять мои ожидания от кандидата рекомендую
1) Послушать эпизод подкаста "Все считается" про проект "Данные под рукой"
2) Почитать whitepaper "What Goes Around Comes Around... And Around..." про развитие баз данных за последние 20 лет (есть мой обзор из трех частей: модели данных и языки запросов, системная архитектура, общие выводы и комментарии на будущее) Я рассчитываю, что мой партнер по данным понимает куда двигаются технологии и почему, а также как это выглядит у нас в компании
3) Полистать книгу Zhamak Dehghani "Data Mesh: Delivering Data-Driven Value at Scale", чтобы знать куда мы идем и быть готовым драйвить эти изменения в моем домене (я уже рассказывал про эту книгу)

#Management #Data #Leadership #Vacancy #Career

Observability in an Asynchronous World • James Eastham • GOTO 2024 - Part I (Рубрика #Architecture)

Интересное выступление от James Eastham, Serverless Developer Advocate из Datadog, на тему событийно-ориентированной архитектуры и тому, как в ней обеспечивать observability. В самом докладе нет ничего про Datadog, но есть сквозной пример пиццерии, архитектуру которой автор делает в EDA стиле и показывает как обеспечить ей наблюдаемость. Тезисы примерно такие

1) В распределенных системах сложно понять, что пошло не так при какой-то проблеме
2) В случае синхронный взаимодействий - это +/- понятно как делать, но в асинхронном мире наблюдаемость еще больше усложняется
3) В какой-то момент по мере роста масштаба систем мы пришли к большому количеству отдельных сервисов
4) При их построении принято стремиться к low coupling и high cohesion, условно связи между сервисами нужно делать несильными, а вот внутри сервиса логика должна быть сильно завязана друг на друга
5) Одним из вариантов решения проблемы связей между сервисами был переход на event-driven architecture. Тут автор показывает свою архитектуру для пицерии, где есть order processing service, kitchen service, delivery service, которые взаимодействую посредством событий
6) Дальше автор разбирает что такое событие (это непреложный факт, который нельзя изменить). Важно, что автора интересуют именно бизнес-события, которые приводят систему в движение. На эту тему рекомендую изучить технику event storming, про которую я рассказывал раньше
7) События - это разновидность сообщения, но событие уже произошло в прошлом. Также есть сообщение типа "команда", которое предписывает что-то сдлеать в будущем.
😍 События бывают трех видов: нотификации, события с передачей состояния (event-carried state transfer) и доменные события (это из event sourcing). Рекомендую почитать мой разбор главы про EDA и event sourcing из книги "Learning DDD" Влада Хононова
9) Собственно взаимодействие сервисов осуществляется через publish/subscribe шаблон, производители публикуют события с определенной схемой, а потребители могут их использовать (или не использовать)
10) Такое взаимодействие позволяет сделать асинхронную систему, что позволяет отвязать производителей от потребителей событий. Ответственность за контроль и потребление событий на консьюмерах

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

#SRE #Architecture #DistributedSystems #Software

Иллюстрация результатов опроса для исследования про успешность IT проектов. В этой диаграмме 7 считается полным успехом, 5 и 6 - это выше mid-level, а ниже 5 считается неудачей.

Code of Leadership #23 - Interview with Andrew Marchenko (Рубрика #Architecture)

В этом эпизоде ко мне пришел крутой гость, Андрей Марченко, мой бывший коллега, который сделал много хорошего для веба Tinkoff.ru. Андрей является software engineer высокого грейда с большим опытом разработки платформенных решений для внутренних разработчиков. Много лет он работал над тем, чтобы сделать разработчикам жизнь проще, а продукты качественнее на разных позиций от разработчика, до руководителя 16+ инженеров. В последнее время он перешел в продуктовую разработку в одной из FAANG компании на позиции инженера. Сейчас он с интересом изучает как все устроено внутри, находит отличия от Российского IT, а также ищет путь для быстрого роста и повышений внутри компании.

Мы поговорили про следующие темы
- Начало карьеры Андрея в общем
- Как Андрей оказался в Тинькофф
- Как выглядел рост Андрея в Т
- Важность взаимодействия с людьми
- Переход в платформенную команду
- Про Statist и продуктовую аналитику
- Инфраструктурные проекты Андрея
- Коммуникации и убеждение
- Высокоуровневые инженеры
- Опыт работы в Тинькофф и переезд зарубеж
- Работа в Booking и изучение баз данных
- Ведение блога и улучшение английского
- Переход в FAANG компанию и текущие проекты
- Проблемы роста в американской компании
- Планы на будущее и как пришел к желанию переехать
- Потеря влияния в новой компании (карма и доверие)
- Решение сложных задач как залог роста
- Изучение дизайна крупных и высоконагруженных систем FAANG компаний изнутри
- Личный опыт и советы Андрея о том, как стать таким же крутым
- Проблемы Андрея с учебой из-за дислексии и их преодоление
- Важность работы и упорства

Дополнительные ссылки
- Блог Андрея со статьями, которые он иногда пишет на тему инфрастуктуры/архитектуры
- Телеграм канал Андрея
- Выступление Андрея про tramvai - "Tramvai, модульный фреймворк для React-приложений от Tinkoff"
- Выступление Андрея "Пять лет эволюции React-приложения"

#Architecure #Software #SystemDesign #Management #Staff #Engineering #PlatformEngineering

Database Internals Meetup #5 (офлайн + онлайн): 5 докладов на конференции ISPRAS Open

Последние пару дней у меня в канале посвящены базам данных, поэтому позволю себе порекомендовать посетить пятый митап российского сообщества разработчиков СУБД и распределенных систем, на котором будут доклады от основателей и ведущих разработчиков YDB, Picodata, Tarantool, openGauss и CedrusData. Мероприятие пройдет 11 декабря офлайн и оно будет частью конференции ISPRAS Open в Москве. Регистрация бесплатна и доступна здесь.

Программа митапа будет плотной и насыщенной:
- 13:00 - 14:00 - Эволюция архитектуры СУБД на примере YDB, Андрей Фомичев, Яндекс, основатель и руководитель YDB
- 14:00 - 15:00 - Blue/green deploy для хранимых процедур в кластерной СУБД на примере Picodata, Константин Осипов, Picodata, основатель Picodata
- 15:00 - 16:00 - Оптимизация подсказками: ускоряем запросы, не изменяя планировщик. Сергей Зинченко, OpenGauss, Инженер
- 16:30 - 17:30 - Columnar In-Memory в Tarantool: зачем нужно строить еще одну колоночную СУБД, да еще и в памяти? Николай Карлов, VK, Head of Innovations, tarantool.io
- 17:30 - 18:30 - Переписывание запросов на основе материализованных представлений в аналитической системе CedrusData. Владимир Озеров, Александр Блажков, генеральный директор и разработчик CedrusData

#Database #Architecture #Management #DistributedSystems #Software #Engineering

Архитектура в Т-Банке: вчера, сегодня, завтра — выступление на ArchDays 2024 (Рубрика #Architecture)

В этой статье я рассказываю про наши подходы к проектированию и построению архитектуры систем. Я в "Т" уже 8 лет и видел как эти процессы эволюционировали во времени, а также знаю к чему мы пришли. Я выделил следующие четыре стадии и объяснил как и почему они сменяли друг друга во времени
1. COTS (commercial of the shelf)
2. Свой собственный софт
3. Platform Engineering
4. Большие мегапроекты и governance

Напоследок я рассказал про подходы корпораций и технологических компаний к должностям/ролям архитекторов, а также поделился своим видением того, как нам дальше стоит развиваться. Эта статья является расшифровкой моего доклада на ежегодной конференции "ArchDays 2024", которая прошла в этом году уже в шестой раз.

#Architecture #Software #Evolution #Management

What Goes Around Comes Around... And Around... Part II (Рубрика #Data)

В продолжение рассказа про эту статью 2024 стоит поговорить про разные подходы к системной архитектуре, которые развивались в последние два десятилетия. Эти архитектуры отражают изменения в software (менялись типы приложений и их требования), а также изменения в hardware, а точнее изменения в параметрах аппаратного обеспечения (мощность CPU, скорость оперативной памяти, разные типы дисков, скорость сети и так далее).

1. Колоночные системы (columnar systems)
Эти системы стали стандартом де-факто в мире аналитических баз данных. Суть в том, что там запросы часто обращаются только к небольшому числу атрибутов таблиц. Колоночное хранение данных позволяет читать только нужные данные, а также лучше сжимать их благодаря однородности значений. Кроме того, можно добиться ускорения выполнения запросов за счет векторизованной обработки данных. Примерами таких баз данных являются Vertica, Amazon Redshift, Google BigQuery, Clickhouse, DuckDB.

2. Облачные базы данных (cloud databases)
Эти базы данных предоставляются в облаках, в которые было модно перевозить свою инфраструктуру. Такие базы обеспечивали масштабируемость и эластичность, что позволяло клиентам динамически изменять ресурсы. Восход этих баз данных связан с тем, что за последние 20 лет скорость сети увеличивалась гораздо быстрее, чем скорость диска, поэтому использование NAS (network attached storage) стало привлекательной альтернативой для стандартного устройства хранения. Собственно, основные вендоры в качества NAS используют объектные хранилища (например, AWS S3). Такая архитектура приводит к тому, что у нас разделяется compute и storage и мы имеем такие преимущества
- Можно обеспечить эластичность на уровне отдельных запросов
- Вычислительные ноды можно отправить на другие задачи, если DBMS не полностью утилизируется
- Можно переместить вычисления прямо на ноды хранения данных - подход называется "pushing the query to the data" и он показывает себя лучше, чем стандартный "pulling the data to the query".
Интересно, что два первых подхода называются serverless computing и в мир DBMS их принесла Snowflake. А среди популярных облачных баз данных есть
- Google Spanner - рекомендую интересный whitepaper
- Amazon Aurora - рекомендую интересный whitepaper, который мы даже как-то разбирали в выпуске подкаста "Code of Leadership", а также рекомендую глянуть рассказ с AWS Re:Invent 2023 о том, как они завезли туда шардирование

3. Озера данных (Data Lakes) и Lakehouses
Облачные платформы разожгли интерес к тому, чтобы отказаться от монолитов в аналитике и перейти к data lakes, где данные как есть загружались в объектные хранилища (S3 like). То есть тут был отход от стандартных ранее ETL (extract-transform-load) к ELT (extract-load-transform). После загрузки, прямо поверх данных выполнялись вычисления при помощи движков lakehouse, минуя стандартные DBMS (типа Greenplum). Собственно lakehouse - это комбинация из data warehouse и data lake:) Данные в data lake хранятся в бинарном виде: Parquet, ORC (optimized row columnar), а для обмена данных in-memory можно использовать формат Apache Arrow. В каждом облаке есть managed data lake сервисы, а также есть отдельные варианты в виде Databricks, Dremio, PrestoDB, Trino.

4. NewSQL-системы
В 2010х годах появился этот класс систем, чтобы совместить ACID транзакции из RDBMS и масштабируемость NoSQL решений. Одним из первых представителей стал уже упоминавшийся Google Spanner. По-факту, тут было 2 типа систем in-memory и стандартные disk-oriented. Часть стартапов ставили на больший спрос на in-memory подходы, но ставка не сыграла. На смену этим подходам пришли распределенные и транзакционные SQL RDBMS навроде TiDB, CockroachDB и думаю, что можно туда добавить YDB с их Calvin-транзакциями. Эти системы подходят для приложений, требующих как высокой производительности, так и строгой консистентности данных.

В продолжении окончание разбора статьи.

#Architecture #Software #DistributedSystems

What Goes Around Comes Around... And Around... Part I (Рубрика #Data)

Интересная обзорная статья 2024 года от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Оба автора являются корефееями в области баз данных: Michael создал Postgres и еще кучу других баз, а Andrew - исследователь в области баз данных, профессор и преподаватель, лекции которого доступны на Youtube.

Сама статья продолжает статью 2005 года "What Goes Around Comes Around", которую написали Michael Stonebraker и Joseph M. Hellerstein. Они проанализировали историю развития баз данных за 35 лет и предсказали что модные тогда объектные и xml базы данных не смогут обойти по реляционную модель.

С тех пор прошло порядка 20 лет и пришло время сделать новый обзор мира баз данных. Для этого авторы решили посмотреть на это с двух сторон:
- Модели данных и языки запросов
- Архитектура баз данных

Начнем с разбора существующих data models и query languages:

1. MapReduce-системы
Изначально они были разработаны в Google для обработки больших объемов данных (веб-краулер). MapReduce не использует фиксированную модель данных или язык запросов, они выполняют пользовательские операции map и reduce. Открытой версией MapReduce стал Hadoop, который сейчас не очень популярен из-за низкой производительности и заменяется более современными платформами аля Apache Spark или просто СУБД.

2. Key-Value хранилища
У них максимально простая модель данных: пары "ключ-значение". Они используются для задач кэширования (Memcached, Redis) или хранения сессий. Возможности в модели ограничены - нет индексов или операций join, что усложняет применение для сложных приложений. Многие KV-хранилища (например, DynamoDB, Aerospike) эволюционировали в более функциональные системы с поддержкой частичной структуры (JSON). Среди популярных встроенных k/v решений популярны LevelDB и RocksDB.

3. Документные базы данных
Они хранят данные в виде документов (например, в формате JSON). Изначально получили популярность благодаря простоте интеграции с веб-приложениями (например, MongoDB), предлагая подход schema on read. Интресно, что к 2020-м годам большинство документных СУБД добавили SQL-подобные интерфейсы и поддержку ACID-транзакций, а иногда и schema on write.

4. Column-Family базы данных (wide columns)
По-факту, это упрощенная версия документной модели с ограниченной вложенностью. Начиналось все с Google BigTable, а в миру есть open source реализация в виде Apache Cassandra. Изначально в Cassandra не было вторичных индексов и транзакций. Но по мере развития они появились (но там все очень интересно)

5. Поисковые движки
Они нужны для полнотекстового поиска (Elasticsearch, Apache Solr). Поддерживают индексацию текста, но ограничены в транзакционных возможностях. Реляционные СУБД также предлагают встроенный полнотекстовый поиск, но с менее удобным API.

6. Базы данных для массивов
Они предназначены для работы с многомерными массивами, например, научные данные (SciDB, Rasdaman). Ниша ограничена специфическими областями применения: геоданные, изучение генома.

7. Векторные базы данных
Используются для хранения эмбеддингов из машинного обучения (Pinecone, Milvus). Основное применение — поиск ближайших соседей в высокоразмерных пространствах. Реляционные СУБД уже начали добавлять поддержку векторных индексов.

8. Графовые базы данных
Моделируют данные как графы (узлы и связи). Примеры: Neo4j для OLTP-графов, TigerGraph для аналитики. Большинство графовых задач можно реализовать на реляционных СУБД с помощью SQL/PGQ (новый стандарт SQL:2023).

Общие выводы
- Большинство нереляционных систем либо занимают нишевые рынки, либо постепенно сближаются с реляционными СУБД.
- SQL остается основным языком запросов благодаря своей гибкости и поддержке современных приложений.
- Реляционные СУБД продолжают развиваться и интегрировать новые возможности (например, JSON, векторные индексы), что делает специализированные системы менее конкурентоспособными.

В продолжении поста будет про архитектуру баз данных.

#Data #Architecture #Software #DistributedSystems

Финал Медиа Баскет Лиги (#Sport)

Утром открыл IT конфу своим докладом, а вечером пошел на финал медиа лиги по баскетболу. Про эту лигу я узнал неделю назад, команд и игроков не знаю, но сами полуфиналы получаются динамиными. Жду финального матча:)

#Sport

Как стать продуктивнее в IT, если вы уже прокачали свои харды (Рубрика #Management)

Сегодня я выступлю на конференции soft weekend, первой софтовой офлайн-конференция в России (что бы это ни значило). Я не могу сказать, что люблю рассказывать чисто про софты, но эту конференцию организует мой знакомый, Андрей Смирнов, автор подкаста "Frontend Weekend", куда я ходил в гости в прошлом году. В итоге, я решил рассказать что-то из серии набора качеств и навыков, что важны для всех: и для крутых инженеров и для хороших менеджеров.

Доклад будет состоять из 4х частей, которые описаны ниже, причем фокус будет на третьем пункте, а точнее навыках и умениях помимо hard skills, что помогали лично мне расти на протяжении всей карьеры

1) Зачем нам нужны soft skills
- В современном мире процессы разработки становятся все сложнее, зона ответственности IC (individual contributor) все увеличивается и включает system design, operation, data, security, ... (подробнее в моем рассказе о современном SDE и SDLC)
- Для борьбы с этой сложностью обычно применяют разные абстракции, например, для инфры это IaaS -> PaaS -> SaaS -> ...(подробнее в моем рассказе об облачных технологиях для Финтех Школы)
- Мы все живем в комплексном и хаотичном мире (complex и chaotic из фреймворка Cynefin)

2) Как расти в таких условиях
- Для инженеров есть две стандартные дороги: индивидуального контрибьютора или менеджера. В обоих, с какого-то уровня надо уметь проявлять лидерство. Условно, до middle+ IC можно дорасти только на хардах, а вот дальше ...(подробнее здесь)
- Например, в T есть матрица для инженера вида: scope, impact, complexity, leadership, improvement. По этой матрице оцениваются достижения инженеров в Т-рост (подробнее в отдельном посте)
- Т-рост - это процесс, по которому проходят повышения в Т. Инициатором является сам сотрудник, который готовит заявку на повышение с учетом своих достижений, упирая на то, что он закрыл оси вышеуказанной матрицы, а также прикладывает артефакты, которые это доказывает

3) Какие навыки и умения помогут проявлять лидерство и расти в таких условиях
- Умение планировать свое время (а дальше если повезет и своей команды)
- Умение и желание брать на себя ответственность (и главное доводить сложные дела до конца)
- Навыки общения с коллегами и договороспособность (эта часть часто западает)
- Навыки самомотивации и мотивации окружающих (правда, если разбираться в вопросе, то внешняя мотивация - это скорее стимуляция)
- Важность любопытства и желание копать глубже, чтобы действительно разобраться как что-то работает (или скорее что не работает)

4) Важность hard skills как базы для дальнейшего роста (пи... не мешки ворочать)
Если вы раскачаете софт скиллы с отсутствующей базой в виде hard skills, то это будет шатким фундаментом, который может рухнуть в произвольный момент. А в некоторые компании без них в принципе не попасть - например, у нас для инженеров есть интервью по программированию, языку разработки и system design. Такой набор эффективно отсеивает мастеров разговорного жанра.

P.S.
Запись выступления будет и потом я поделюсь ей в этом канале.

#Leadership #Processes #Management

Опыты и эксперименты для детей 10 в 1 (Рубрика #ForKids )

Уже приближается конец недели, а завтра начнутся выходные, которые можно провести с семьей. А у меня в семье три сына, которые не любят скуку. Если не придумать для них развлечения, то они могут перевернуть весь дом. Одним из таких развлечений являются разнообразные химические/физические фокусы, которые позволяют сделать руками что-то интересное и немного рассказать о научной составляющей вопроса. Достаточно хорошим является вариант опытов "10 в 1", в котором мы сделали за прошлую неделю все эксперименты, а некоторые их результаты украшают интерьер нашей кухни, например, разноцветные кристаллы, приложенные к посту в качестве снимков. В общем, я рекомендую знакомить малышей с наукой при помощи научпоп подходов (особенно учитывая, что такие эксперименты очень простые и красочные).

#Physics #PopularScience #ForKids #ForParents

Зачем заниматься темой developer productivity в большой компании - D-Day (Рубрика #Management)

В выходные я выступал на конференции D-Day, что оффлайн проводится в Тирасполе.Я рассказывал про тему developer productivity: зачем заниматься этой темой, как это принято делать в индустрии, как мы подходим к этому в Т-Банке. В конце я порекомендовал такой набор источников для более глубого знакомства с темой.

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

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

How to Make the World Add Up (Ложь, наглая ложь и статистика) - Part II (Рубрика #Math)

Продолжая рассказ про книгу Тима Харфорда "How to Make the World Add Up", закончу списком оставшихся правил:

4. Чтобы увидеть всю картину, отступите на шаг назад. Важно уметь видеть информацию в контексте, тогда утверждения вида "случился еще один ужасный инцидент" могут заслонять тенденцию, что "в целом количество инцидентов снизилось":) То есть нам необходимы сравнения и контекст, чтобы понять как тезисы согласуются между собой.
5. Узнайте предысторию. Когда мы видим интригующие результаты исследований, то это часто связано с эффектом публикации (publication bias). Если смотреть шире, то нам нужно определить источник статистических данных и изучить, а все ли данные были учтены.
6. Спросите, кого не хватает. Надо всегда задавать себе вопрос, а все ли группы людей были учтены в исследованиях и если не все, то как бы поменялось исследование. В большинстве старых классических психологических исследованиях участниками были студенты колледжей, а не репрезентативная выборка всего населения. Одновременно, там не хватало даже студенток, которых можно было относительно легко привлекать к исследованиям, но об этом как-то не думали раньше. Про это подробнее можно прочитать в посте про "Опрос, что изменил опросы"
7. Требуйте прозрачности от компьютера. Этот пункт особенно актуален в наше время, когда у нас много больших данных и сложных алгоритмов. Важно не бояться задавать неудобные вопросы о том, что это за данные и как именно работает алгоритм. Интересно, что условный perplexity.ai сразу вместе со сгенерированным ответом дает ссылки на источники, откуда он брал информацию. Это не всегда спасает от галлюцинаций, но вы хотя бы можете сделать факт-чекинг.
8. Цените краеугольный камень статистики. Автор предлагает ориентироваться на официальную статистику, особенно в тех странах, где ей не принято манипулировать в угоду политическому курсу.
9. Помните, что дезинформация тоже бывает привлекательной. Если вам показывают красивую визуализацию, график или дашборд, то надо не стесняться и задавать вопросы о том, а что стоит за такой красотой:)
10. Не бойтесь изменить свое мнение. Автор говорит о том, что надо уметь менять свое мнение при появлении нового опыта или доступной информации. То есть надо рефлексировать относительно того, а не заблуждаемся ли мы, настаивая на старой точке зрения.
11. Золотое правило. Сохраняйте любознательность. В общем, автор предлагает копать глубже и задавать больше вопросов. Он выдвигает гипотезу, что любознательность можно прокачивать ...

Я не знаю можно ли прокачивать любознательность, но у меня она с детства была где-то на уровне 10 из 10. Помню как я доставал родителей, воспитателей, тренеров и учителей своими вопросами "А почему все работает именно так":) Походу, любознательность действительно дает хорошие плоды. Развивайте любознательность у себя и своих детей и изучайте с интересом мир вокруг вас!

P.S.
В своей книге автор упоминает и другие книги про статистику
1) Как лгать при помощи статистики (How to Lie with Statistics) - книга, где на пальцах объясняется как врут с помощью статистики. Собственно, автор книги зарабатывал на жизнь тем, что тасовал данные, убеждая в том числе, что курение не приводит к раковым заболеваниям
2) Темные данные (Dark Data. Why What We Don’t Know Is Even More Important Than What We Do) - книга про то, как можно облажаться с данными и что с этим можно сделать
3) The Tyranny of Metrics (Тирания показателей) - эта интересная книга, название которой идет наперекор стандартному подходу к измерению всего и вся:) Она напоминает по структуре научную статью и классно описывает проблемы, которые во многом рождены из закона Гудхарта "Когда мера становится целью, она перестает быть хорошей мерой".

#Math #Management #Statistics

Черная пятница в издательстве «Питер» (Рубрика #Sales)

В издательстве Питер очередная распродажа со скидками в 40% на бумажные книги и 50% на электронные. Для получения этой скидки надо использовать промокод "Бумажная" (или "Электронная", если покупаете элетронную версию) при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг и докупил на этой распродаже еще книг

Новые купленные книги
- Производительность систем - интересная книга о производительности от Brendan Gregg, крутого эксперта, который одновременно много сделал для внедрения eBPF, о чем можно узнать из документалки
- Креативный программист - я решил изучить креативные методы, что могут помочь в решении инженерных задач
- Продвинутые алгоритмы и структуры данных - книжка о самых необходимых алгоритмах решения сложных задач программирования в области анализа данных, машинного обучения и графов. Хочу подтянуть свои знания алгоритмов
- Ненормальные личности. Учение о психопатах - решил почитать про ненормальность от Ганнушкина
- Об уме вообще - книга Павлова (хозяина знаменитой собаки из экспериментов), который писал интересно о работе мозга

Книги, что я уже успел прочитать
- Чистый Python. Тонкости программирования для профи - решил вспомнить теорию по python
- Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад и она была ок. Сейчас я прочитал 150 страничек из нового издания и могу сказать, что книга не ухудшилась:)
- Гейм-дизайн: как создаются игры - эта книга про геймдизайн, про который я и до этого много читал и писал (1, 2, 3), а сейчас я уже прочитал и рассказал об этом
- Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT, я ее уже прочел и даже рассказывал оо ней
- Мифический человеко-месяц, или Как создаются программные системы - классическая книга Фредерика Брукса, которая в следующем году справляет свой юбилей. Я раньше уже рассказывал про эту книгу
- Распределенные данные. Алгоритмы работы современных систем хранения информации - в девичестве на английском эта книга Алекса Петрова называлась Database Internals и я про нее много рассказывал (1 и 2), а также мы ее обсуждали в подкасте "Code of Architecture"
- Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google - эту книгу я читал в оригинале и она называлась "Building secure and reliable systems", а также уже рассказывал про нее.

Книги, что мне еще предстоит прочитать
- Data mesh в действии - интересная тема о переходе от DWH в сторону Data Mesh и Lake House. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale".
- Грокаем алгоритмы искусcтвенного интеллекта - просто тема интересная для меня:)
- Настоящий CTO: думай как технический директор - тут я решил сравнить насколько я думаю как настоящий технический директор, а то вдруг я думаю как-то не так:)
- README. Суровые реалии разработчиков - книга про будни разработчиков и практиками инжиниринга
- Software: Ошибки и компромиссы при разработке ПО - эта книга подкупила меня своей второй главой, которая называется "Дублирование кода не всегда плохо".
- Грокаем Continuous Delivery - я вроде неплохо понимаю в CI/CD, но хочется почитать про него подробнее
- Грокаем функциональное программирование - интересно почитать просто про функциональщину
- Дизайн для разработчиков - я довольно много книг читаю про дизайн для дизайнеров (1, 2, 3), а тут хочу посмотреть как это подают разработчикам
- Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО - в рамках работы над книгой про engineering management полезно изучить другие источники
- Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании - для инженеров и технических руководителей сейчас полезно думать продуктово, особенно если вы работаете не в галере. Яуже писал про книги на эту тему: 1, 2, 3, 4, 5
- Паттерны проектирования API - я люблю паттерны, люблю хорошие API, плюс мне понравилось оглавление.

#Sales

Code of Leadership #22 - Интервью с Дмитрием Аношиным про data engineering (Рубрика #Data)

В этом выпуске ко мне пришел в гости крутой гость, Дмитрий Аношин. Дима является экспертом в data engineering, ведет канал @rockyourdata, также Дима почти 10 лет работал западных Bigtech компаниях. Кстати, выпуск доступен в виде подкаста и в Яндекс Музыке.

Мы обсудили следующие темы:
- Как Дима входил в IT порядка 15 лет назад
- Как он развивал свои навыки как дата инженер
- Как он уехал в Канаду и адаптировался там
- Как развивалась карьера Димы в Amazon, Microsoft и что он вынес из этого опыта
- Как Дима стал создателем обучающих проектов datalearn, surfalytics, а также как ему удалось написать целую гору книг
- Как находить мотивацию для роста и развития

Если говорить подробнее про Дмитрия, то он уже больше 15 лет занимается аналитикой и инжинирингом данных, а 10 последних лет проработал в Северной Америке. Из них 5 лет в Амазоне, где работал в нескольких командах, включая Alexa AI (в Бостоне) и Customer Behaviour Analytics (в Сиэтле). Поучаствовал в действительно инновационных проектах, где драйвером являются данные. Видел и Big Data и Machine Learning в действии в масштабе крупнейшей компании мира. После Амазона работал 4 года в Microsoft Xbox и Microsoft Azure Data&AI. Активно принимал участие в развитии Microsoft продуктов для аналитики - Synapse, Fabric, Azure Databricks.

Теперь, Дмитрий помогает создавать инновационные аналитические решения, дата команды и модернизировать устаревшие решения через свою компанию rockyourdata.cloud и глобально готовит инженеров и аналитиков через свое сообщество Surfalytics.com (на английском), до этого несколько лет развивал проект Datalearn.ru, на котором делился фундаментальными знаниями и помогал бесплатно всем желающим войти в ИТ, знания там все еще актуальны.

Дмитрий написал несколько книг по аналитике и преподает несколько лет Облачные Вычисления (Cloud Computing) в партнерстве с Microsoft в Университете Виктории.

Еще из интересных проектов:
- Создал онлайн выставку писем CEO про увольнения в крупных компаниях - https://www.layoffmemos.com/
- Совместно с Московским Зоопарком и Вконтакте организовал группу по наблюдению за популяцией пеликанов и экомониторинга с использованием AI - https://www.scifly.ai/

Из последнего, Дмитрий создает главный Российский портал Дата Инженеръ посвященный карьере дата инженера, куда он планирует добавить road map для вакансий Инженера Данных, Аналитика и BI разработчика и ссылки на лучшие бесплатные ресурсы: книги, тренинги, курсы, видео, телеграмм каналы, и многое друго, что поможет понять, кто такой иженер данных и как таким стать, преимущественно на русском языке.

#Database #Architecure #Software #Data #SystemDesign #Management

Insights on How Team Topologies Drive Organizational Success - Manuel Pais - GOTO 2024 - Part II (Рубрика #Management)

Этим постом я заканчивую рассказ про выступление Manuel Pais, со-автора книги "Team Topologies". В прошлом посте я начинал обзор этого рассказа про инсайт из практического применения топологии команд.

7. Автор затрагивает неконсистентный опыт пользователей. В качестве кейса приводится история BBC (ее тоже не на сайте). Здесь суть была в том, что у BBC было много продуктов, каждый из которых имел свой особенный интерфейс и это не очень нравилось пользователям:) В итоге, BBC просто выделили стандартные фронтовые компоненты, но и сделали большой реорг, что они описывали у себя на Medium. В итоге, автор выделяет следующие
- Принцип: optimize for innovation & speed when those are needed, allow "eventual consistency" and standartization to emerge later
- Practice: Collaborate, facilitate, x-as-a-service. Платформенным командам важно правильно выбирать тип взаимодействия
8. Автор переходит к медленному time-to-market. Рассматривается пример SAP, у которого сложности со скоростью из-за соблюдения требований законодательства и обеспечения безопасности (и наверное не только из-за этого). В итоге, ребята занялись внутренней платформой для упрощения работы команд разработчиков. Платформа рассматривалась как продукт, ориентированный на группы команд, страдающих от сложных процессов соответствия требованиям и безопасности.
- Принцип: turn blocking dependencies into unblocking ("dependency inversion" for teams)
- Practice: Product management in platform. Подробнее про это можно прочитать в моем разборе CNCF Platform White Paper: 1, 2 и 3
9. Автор переходит к работе с тезисом "we can't do that in my organization". Это кейс GfK/NIQ. У ребят аля SAFE и все команды заняты продуктовой разработкой. Они придумали, что каждый пятый спринт будут работать над платформенными задачами
- Принцип: "behaviors over structures". don't wait for the ideal org / process / scale
- Practice: Thinnest viable platform. Можно начать с максимально тонкой платформы, что уже приносит пользу организации
10. Топология команд рассматривается как социально-технический подход для увеличения потока и повышения удовлетворенности. Организации могут применять идеи топологии команд в разных сферах бизнеса, адаптируя их под свои нужды. Важно иметь видение и понимать принципы топологии команд. Примеры выше показывают, как можно адаптировать идеи и принципы для текущей ситуации. Сообщество вокруг топологии команд активно и заинтересовано, и есть множество ресурсов для изучения и применения этих идей.

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

Insights on How Team Topologies Drive Organizational Success - Manuel Pais - GOTO 2024 - Part I (Рубрика #Management)

Интересное выступление Manuel Pais, со-автора книги "Team Topologies", в котором он делится инсайтами из практического применения топологии команд. Для меня это видео супер-интересно, так как я давно сделал краткий обзор этой книги в трех частях
- Teams as means of Delivery
- Team Topologies that work for flow
- Evolving team interactions for innovation and rapid delivery
А потом еще записал и первый эпизод подкаста "Code of Leadership" вместе со Станиславом Халупом.

Это же выступление Manuel Pais содержит следующие интересные моменты
1. Ни один подход не решает все проблемы сразу, это относится и к топологии команд
2. Комикс Comic Agile забавно рассказывает про Team Topologies, но не слишком правильно (по мнению автора):)
3. Team topologies - это социо-технический подход для улучшения flow и hapiness. Быстрый flow требует большей автономии и четкой цели.
4. Крупные организации задаются вопросами: как расти устойчиво, как становится высоко-производительными, как вовлекать сотрудников
5. Автор разбирает проблему медленного delivery из-за высокой связности команд. В качестве case study приводится пример JP Morgan, где автор решали это через business aligned value streams. Для этого пришлось разобраться с природой зависимостей, сделать команды кросс-функциональными и улучшить коммуникации между ними. На выходе у ребят получилось уменьшить на 60% зависимости между командами. Вообще, публичные case studies доступны на сайте teamtopologies.com, но кейса JP Morgan в публичном доступе нет. Отсюда автор выводит
- Принцип: decouple teams by decoupling their streams/products ("decoupling responsibilities")
- Practice: Independent service heuristics (ISH). Суть в том, чтобы выделить independently-viable services. Начать можно с вопроса, а может ли такой кандидат в стримы работать как отдельный SaaS продукт в облаке
6. Автор переходит к отсутствию бизнес гибкости из-за организационных трений (org frictions). Здесь в качестве кейса приводится история Telenet (его тоже не на сайте). В этом кейсе для любой фичи требовалось участие огромного количества команд. Это замедляло любые изменения до предела. На выходе автор опять приводит
- Принцип: "minimize structural complexity" through grouping closely related streams of value
- Practice: Team (Tribe) interaction modeling. Надо идентифицировать и совместно стратегировать относительно командной структуры, которая сможет эволюционировать в дальнейшем

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

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

Подъехали фотки с моего выступления на выходных га конференции D-Day, где я выступал из онлайна. Мне понравилась организация этого мероприятия, мне было приятно выступить перед таким количеством заинтересованных людей.

ЦЕХ 4 - Урок #22 "Взаимодействие с обозревателями, критиками и СМИ. Эксперт — Екатерина Северина" (Рубрика #Writing)

Очередной урок из курса книгописания и книгоиздания от МИФ вела PR-менеджер, драматург и книжный обозреватель. Из этого урока я вынес следующие моменты

1) Успеху книги может способствовать личный бренд, который можно повышать за счет работы со СМИ. Это помогает и в плане SEO (по вашему имени находится релевантная информация в поисковиках)
2) СМИ тоже выгодно работать с авторами - это помогает им закрыть контентный голод и получить эксклюзивный материал, а также сэкономить силы штатных журналистов
3) Важно понимать какие СМИ интересны вашей аудитории и взаимодействовать с ними. Тут пригодится анализ публикаций СМИ и их целевой аудитории (часто у СМИ есть медиакиты для рекломадателей, где эти вещи базово описаны)
4) Для анализа СМИ можно почитать и их соцсети и комментарии читателей в них
5) СМИ выстроены в пирамиду: массовые СМИ ориентированы на новичков и не погружаются в глубокие темы, тематические СМИ, такие как "Мир фантастики", предлагают материалы для профессионалов, профи и эксперты в тематических СМИ готовы платить за качественный продукт и не совершают поверхностных суждений.
6) Профи и эксперты в тематических СМИ интересуются не только книгами, но и функционированием индустрии.
7) Также можно сотрудничать с книжными обозревателями и блоггерами - это помогает запустить сарафанное радио и литературный нетворкинг.
8) В общем, для того, чтобы эффективно работать со всеми этими людьми нужна база контактов, которая должна быть рабочей, приносить результат, динамичной и актуальной.
9) Основные элементы записи в базе контактов: фамилия, имя, СМИ, адрес, электронная почта, tg-канал.
10) Важно анализировать эффективность коммуникаций через свою базу и адаптировать подходы в зависимости от результатов (в уроке приводилось куча примеров как писать правильные письма и сообщения)
11) Вообще, есть целая пачка книжных материалов, что автор может предложить СМИ/обозревателям/блоггерам
- Обзор: краткое описание новых книг для привлечения читателей.
- Рецензия: критический анализ и оценка произведений.
- Препринт: отрывок из книги до её выхода.
- Тематическая подборка: рекомендации книг по темам.
- Интервью: редко встречаются, требуют весомого литературного капитала.
- Новости: большие материалы о значимых событиях, таких как смерть автора.

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

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Comic Agile - Team Topologies (Рубрика #Humor)

В эти выходные я смотрел лекцию Manuel Pais, со-автора книги "Team Topologies", на конференции GoTo. В самом начале своего выступления он ссылается на этот комикс "Comic Agile". На этом ресурсе много забавных комиксов, включая тот, что про Team Topologies. В общем, рекомендую, если вам тоже нравится с юмором подходить к менеджменту:)

#Humor #Management #Leadership #Processes #Software

Зачем измерять developer productivity в крупной компании? И как это делать правильно? (Рубрика #Management)

Сегодня я выступаю онлайн на конференции D-Day, что оффлайн проводится в Тирасполе. Я уже выступал на этой конференции 5 лет назад, но тогда это было очно:) В этот раз я решил рассказать про тему developer productivity, начать с того, а зачем ее мерить и дальше рассказать как, а напоследок поделиться тем, как это принято делать у нас в компании. По традиции в день доклада я публикую список материалов по теме, которые позволят изучить тему сильно глубже, чем я успею рассказать за 25 минут

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

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

Обложки книг Джона Маэды "Законы простоты" и "The Laws of Simplicity"

Законы простоты (The Laws of Simplicity) (Рубрика #Design)

На днях я прочитал книгу Джона Маэды о законах простоты. Сам Джон является выдающимся американским дизайнером, ученым и педагогом, который известный своими работами на стыке бизнеса, дизайна и технологий. Сейчас он работает вице-президентом по дизайну и искусственному интеллекту в Microsoft. Интересно, что это уже вторая книга этого автора, которая мне понравилась, первой была "ReDesisning Leadership" ("Редизайн лидерства"), о которой я уже писал в канале. Если же возвращаться к самой книге о законах простоты, то интересно, что он написал ее почти 20 лет назад, еще до выхода айфонов на рынок. Тогда она стала бестселлером, но дизайнеры с тех пор двигаются скорее в сторону сложности:)

Джон предложил использовать следующий список законов для нахождения баланса между сложностью и простотой в различных аспектах жизни и работы, делая системы более интуитивными и эффективными
1. Сокращение (Reduce) — Самый простой способ достичь простоты — это осознанное сокращение. Убирайте лишнее, но будьте осторожны, чтобы не убрать что-то важное.
2. Организация (Organize) — Организация помогает сделать систему с множеством элементов более понятной и управляемой. Правильная структура делает сложное проще.
3. Время (Time) — Экономия времени создает ощущение простоты. Чем меньше времени требуется на выполнение задачи, тем проще она воспринимается.
4. Обучение (Learn) — Знания упрощают все. Чем больше вы знаете о системе или процессе, тем легче с ними работать.
5. Различия (Differences) — Простота и сложность взаимосвязаны. Чтобы оценить простоту, необходимо иметь возможность сравнивать ее с чем-то более сложным.
6. Контекст (Context) — То, что находится на периферии простоты, не является незначительным. Контекст важен для понимания и восприятия системы.
7. Эмоции (Emotion) — Больше эмоций лучше, чем меньше. Эмоциональная связь с продуктом или системой делает их более привлекательными и понятными.
8. Доверие (Trust) — Простота требует доверия. Пользователи должны доверять системе, чтобы она казалась простой в использовании.
9. Неудача (Failure) — Некоторые вещи невозможно упростить. Не все попытки создать простоту будут успешными, но важно учиться на ошибках.
10. Единое (The One) — Простота заключается в вычитании очевидного и добавлении значимого. Это объединяющий принцип всех предыдущих законов.

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

#Design #Leadership #Management #SelfDevelopment #Processes

Менторинг сессия на канале SouthHub (Рубрика #Management)

Во вторник вечером я проводил менторинг сессию, запись которой доступна на Youtube. Моим менти был Антон Числов, технический директор МТС Авто. Запрос был на меторинг по теме как осуществлять крупные изменения в больших компаниях. Суть в том, что у ребят на носу 2 больших изменения
1) Переход от разработки по компонентам к stream-aligned командам
2) Переезд из MTS Digital в отдельную компанию внутри экосистемы

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

#Management #Leadership #Processes #Software

Моя жена, Анастасия, сейчас заканчивает магистратуру "Психоанализ и психоаналитическое бизнес-консультирование" в Вышке. И в рамках дипломной работы она с коллегами проводит исследование, посвященное формированию и развитию новой профессиональной идентичности. Если вы являетесь продакт-менеджером или планируете им стать, то вы можете принять участие в психаналитической группе "Как занять свое место в профессии". Подробности в крутом канале Насти (на который вы можете подписаться)

#SelfDevelopment

#psy
Мы с группой коллег проводим исследование, посвященное
формированию и развитию новой профессиональной идентичности.
Для практической части мы выбрали профессии, связанные с управлением продуктом.
Если вы недавно перешли в такую профессию, находитесь в процессе перехода или планируете его, приглашаю принять участие в нашей психаналитической группе "Как занять свое место в профессии".

Примеры вопросов, которые могут возникать:
- Вокруг все говорят, что ты product manager, а сам ты про себя так не говоришь/не можешь сказать кто ты;
- Хочешь стать product manager, но не дают\не получается (по разным причинам);
- Уже работаешь в управлении продуктом, но не можешь понять, кто ты такой в своей текущей роли на работе

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

Состав группы - 12-15 человек
Длительность встречи - 2 часа
Встречи будут онлайн по субботам, 6 встреч, 1 раз в неделю.

Перед стартом группы будет проведена индивидуальная встреча с одним из консультантов (1 час) для знакомства с методом и друг с другом.

Вся информация строго конфиденциальна и будет обезличена в рамках исследования.

Если вам интересно, пишите в лс

0b1000 в Т-Банке

Сегодня у меня юбилей в Т-Банке, 8 лет:) Именно столько лет назад я пришел в тогда еще Тинькофф. Я пришел из Банки.ру, где был лидом команды разработки, что отвечала за рейтинги банков, страховых и остальной UGC (user generated content), а также лидогенерящие странички:) В Тинькофф я вышел на позицию engineering manager заниматься проектами привлечения. Планы на старте были наполеоновскими и они действительно драйвили меня. Это был период роста и моя зона ответственности постоянно менялась. Я чувствовал себя не просто engineering менеджером, а скорее менеджером непрерывных изменений с девизом "пересобери себя и свою команду или умри"... Но как только я справлялся с новым вызовом, то получал следующий. Это происходило примерно каждые полтора-два года. Про многие из этих изменений я рассказывал на YaTalks в прошлом году и в расшифровке этого выступления. С тех пор я собрал у себя dream team из руководителей, которые отвечают за отдельные большие подразделения в 200-300 человек
- Клиентские интерфейсы: платформенные команды веба, мобилы и API
- Маркетинговые технологии: внешняя реклама, маркетинговая платформа
- Соц-медиа платформы: социальные сети, медиаплатформа, медиапроекты (ТЖ, Бизнес-секреты), игры
- Цифровые экосистемы: аутентификация/авторизация, биометрия, главная страница приложения, финздоровье

А еще у меня в подразделении есть важный для меня продукт в виде продуктовой аналитика и a/b платформы. Это важно для компании для того, чтобы быть data-driven, а для меня - это возможность закрыть гештальт относительно математики (теорвер, матстатистика), которая мне нравилась всю дорогу от лицея до физтеха и дальше:) Также я отвечаю за архитектуру как функцию в компании. Это мне близко как технарю, для которого важна engineering excellence и design крутых систем.

Напоследок, я хотел сказать спасибо ребятам из моего юнита "Клиентские интерфейсы, маркетинг и вовлечение". Ребята и делают всю работу, которая приносит радость нашим клиентам, деньги компании, а мне позволяет рассказывать об этом. Кстати, с частью ребят я записывал интервью
- Про архитектуру с моим замом, Антоном Костериным. Антон руководит архитектурной группой при мне
- Про про системных аналитиков с Кириллом Крайневым. Кирилл руководит маркетинговыми технологиями, а также драйвит развитие профессии системных аналитиков
- Про Staff+ инженеров, архитектуру и SDLC с Алексеем Тарасовым. Алексей руководит соц-медиа платформой, а также драйвит наши system design interview и помогает развивать направление staff+ для инженеров
- Про систему для продуктовой аналитики (Statist) с Андреем Цыбиным. Андрей руководит продуктовой аналитикой и a/b платформой.

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

P.S.
В общем, 8 лет - это большой срок, который можно и отметить. Особенно с учетом того, что я не уверен в том, что "доживу" до следующего круглого юбилея в двоичной системе:)

#Management #SelfDevelopment #Engineering #Processes #Software

Бегущий по лезвию 2049. Вселенная фильма (Blade Runner 2049) (Рубрика #SciFi)

В конце прошлой сложной недели я взял полистать этот артбук перед сном:) Отчасти решение выбрать именно эту книгу было принято из-за получения в этот день двухтомника Сергея Маркова "Охота на электроовец", который посвящен искусственному интеллекту. Это название отсылает к книге "Мечтают ли андроиды об электроовцах" ("Do Androids Dream of Electric Sheep?") Филиппа Киндреда Дика (кстати, про него я уже рассказывал при обзоре его биографии в комиксах). Именно эта книга про мечты андроидов послужила Ридли Скотту основой для его классического фильма "Бегущий по лезвию", что вышел больше 40 лет назад. А меньше 10 лет назад появилось продолжение от Дэни Вильнева "Бегущий по лезвию 2049". В итоге, в этой книге рассказывается про создание фильма и приводится куча иллюстраций того, как выглядели локации фильма на этапе задумки и как они модифицировались дальше до того состояния, что мы видим в самом фильме.

P.S.
У меня есть книга про Ридли Скотта "Ридли Скотт. Гений визуальных миров. От Чужого до Марсианина", в которой значительное место уделено "Бегущему по лезвию". Но ее я прочитаю в следующий раз:)

#SciFi

T=Математика (#PopularScience)

1 декабря будет день математики и мои коллеги из Т-Образования устраивают большой праздник с кучей активностей: лекции, математические игры, интенсив по финграмотности и многое другое
- 11 — 24 ноября - Интенсив по олимпиадным задачам (онлайн) - подготовка к муниципальному этапу ВсОШ (разборы от опытных преподавателей, тренировки в решении задач
- 16 ноября - Интенсив по финграмотности (оффлайн и онлайн) - мероприятие пройдет в T-Space (Москва, м. Белорусская), в программе будет несколько докладов
- 28-30 ноября - Турнир по математическим играм (онлайн) - на турнире будут командные игры: «Математический квадрат», «Математическая карусель» и «Семь чудес». Победители получат памятные призы от Т-Образования
- 1 декабря в T-Space в Москве - День математика (оффлайн) - мероприятие пройдет в T-Space (Москва, м. Белорусская), в программе будут лекции, нетворкинг и фуршет.

#PopularScience #Math

Интересная информация от канала "эйай ньюз", за которым я слежу, чтобы не отставать от новостей AI.
Здесь интересна информация о том, а как крупные компании используют AI в своих процессах и оказалось, что все просто
1) Customer support/service - тут всеми "любимые" чатботы и не только
2) Marketing/content generation - генерация маркетингового контента, рекомендаций продуктов (eBay)
3) Document processing / infromation retrieval - обработка документов, суммаризация встреч, поиск по данным
4) Development/code generation - генерация кода (Gitlab, Autodesk), теста (Notion), ...
5) Employee/internal tools - внутренние инструменты для сотрудников

В принципе, список неполный, но достаточно полезный. У нас, например, по всем из этих направлений тоже ведется работа.

Research Insights Made Simple #4 - Обсуждение "AI-Enhanced API Design"

В этом эпизоде мы обсуждаем интересный whitepaper "AI-Enhanced API Design" от ребят из Google, где рассказывалось о том, как подходы к управлению API влияют на продуктивность и usability. Исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API.

В разборе мне помогает крутой гость - Павел Каравашкин, мой коллега. Павел является руководителем разработки платформы T-API, а также лидером профессии системного анализа в Т-Бизнес, соведущим подкаста SA Т-Банка InSAйт. Паша любит велоспорт, Warhammer 40k и читать случайные статьи на Википедии.

Кстати, эпизод доступен и в подкасте Яндекс Музыки.

Материалы:
- AI-Enhanced API Design: A New Paradigm in Usability and Efficiency
- Мой обзор этой научной статьи
- Публичное T-API для партнеров
- Подкаст InSAйт

Мы обсудили следующие моменты
- Обзор статьи и личные впечатления Павла
- Обсуждение структуры статьи
- Проблемы и аспекты проектирования API
- Процесс разработки API в Google
- Гибкость и стандартизация в разработке API
- Методология исследований в Google
- Подходы к исследованием вокруг API в T-банке
- Проблемы и решения в персонализации
- Использование линтеров и метрик
- Анализ логов и задач разработчиков
- Исследования и метрики в Google
- Генерация контрактов
- Проблемы с архитекторами
- Методология эксперимента в Google и его результаты
- Ограничения эксперимента
- В общем про процесс разработки и помощь автоматизированных средств
- Важность этапа реализации
- Архитектура и улучшение процессов
- Измерение эффективности инструментария (отсылка к статье "Measuring developer goals" от ребят из Google)
- Роли в разработке
- Автоматизация кибербезопасности (отсылка к предыдущему подкасту)Заключение и планы на будущее

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

What Is This OpenTelemetry Thing? • Martin Thwaites • GOTO 2024 (Рубрика #Architecture)

Интересное выступление на goto конференции от Martin Thwaites, Principal Developer Advocate из Honeycomb. Основная суть выступления примерно такая
1) Автор начинает с истоков наблюдаемости, когда люди ориентировались еще на мигающие лампочки на самих устройствах:)
2) В 2000х годах использовались метрики для мониторинга производственных систем, так как места было мало и производительность систем была не слишком большой. Тут важно было правильно предагрегировать данные, изначально понимая какая информация будет нужна, так как метрики расчитывались заранее, а оригинальные события не хранились. Где-то в 2010х годах для хранения метрик стали использовать time-series базы данных
3) Дальше стали популярны логи, для которых зачастую использовался ELK стек (Elastic, Logstach, Kibana). Это позволило уйти от предварительной агрегации данных и улучшить наблюдаемость. По-факту, в Kibana можно было пост-фактум строить красивые дашборды, агрегируя данные так, как необходимо
4) Где-то с середины 2010х годов системы стали сложнее и распределеннее и дальше появились инструменты для распределенной трассировки и стандарты OpenTracing и OpenCensus
5) В какой-то момент они объединились и превратились в OpenTelemetry - это проект CNCF в статусе incubating, что наряду с graduated считается стабильным и пригодным для использования в проде
6) OpenTelemetry хорош тем, что он пришел на смену двум предыдущим стандартам, что со временем стали deprecated и позволил отвязать инструментализацию телеметрии от бекендов, в которые она отправляется. У этого стандарта есть протокол и SDK для всех популярных языков программирования
7) У OpenTelemetry есть и проблемы - он развивается через комитеты, что замедляет процесс доработок и расширений стандарта
😍 В OpenTelemetry есть логи, метрики, трейсы. Трейсы - это способ для описания взаимодействия сервисов с учетом причинно-следственных связей (это делается через связи между спанами). Вообще, трейсы позволяют очень удобно разбираться с поведением сложной распределенной системы.
9) Логи предназначены для людей и имеют шаблон сообщения, они полезны для локальной отладки и проверки работы трассировок
10) Метрики - это агрегированные временные ряды данных. Они используются для измерения и анализа производительности. Дешевы в хранении и быстры в обработке, но ограничены в контексте и размерности.
11) OpenTelemetry позволяет думать о соединениях между системами. Распространение данных включает корреляцию и передачу информации о состоянии. Спецификация контекста трассировки W3C определяет заголовки и данные для передачи.
12) Автор подробно говорит про W3C Baggage, propagation format for distributed context. Он как раз позволяет передавать дополнительный контекст между службами, но есть там и проблемки, например, передача данных через сторонние API может привести к утечке конфиденциальной информации.
13) Круто, когда инструментализация OpenTelemetry встроена в шаблоны ваших приложений - это помогает командам SRE получать стандартизированные observability данные
14) У OpenTelemetry есть collector, который используется для проксирования и обработки данных телеметрии. Он позволяет централизовать конфигурацию и отправку данных нескольким поставщикам, а также обеспечить центральную точку для инфобезов или обогощения данных
15) В OpenTelemetry можно настраивать семплинг для уменьшения затрат на наблюдаемость
16) Прикольно семплировать не с головы, а с хвоста, когда мы знаем что попало в трейсинг. Хвостовой сэмплер может сообщать о медленных процессах и ошибках, но компромисс здесь в том, что задержка отправки данных и большие затраты памяти.
17) У OpenTelemetry есть и проблемки - отправка данных через перекрестные зоны доступности может быть дорогой. Решения по отправке данных требуют компромиссов. OpenTelemetry требует постоянного внимания и настройки.
18) В будещем в OpenTelemetry ожидается больше семантических соглашений и библиотек

#SRE #Architecture #DistributedSystems #Software

Ководство (Рубрика #Design)

Недавно я прочитал седьмое издание книги Артемия Лебедева, которое доступно на его сайте онлайн под названием ".ру/Ководство". Если кратко, то кажется в далеком детстве Рунета Артемий Лебедев был достаточно интересен как в плане дизайна, так и текстов. Условно, если бы я читал его мысли в начале двухтысячных, когда только начинал свой путь в софтостроении, то это было бы полезно. Сейчас же эти статьи читаются скорее как байки о старых временах от интересного человека из той эпохи ... они пахнут нафталином как в детстве, когда шубу или пальто доставали из шкафа с зимней одеждой. В общем, почитать книгу можно ради воспоминаний ... и интересных мыслей про типографику. Кстати, книгу покупать не обязательно - их можно почитать и на сайте автора.

P.S.
Мне книга скорее понравилась, но допускаю, что это из-за того, что я помню как все начиналось ... в рунете:)

#Design #Visualization

Архитектурные материалы для изучения от облачных провайдеров (Рубрика #Architecture)

Как-то раньше я не писал о том, что помимо книг есть большое количество архитектурных материалов у главной тройки cloud провайдеров.

1) У AWS это называется AWS Well-Architected Framework, у него 6 ключевых столпов
- Operational excellence (операционная эффективность): Фокус на управлении и мониторинге систем для обеспечения бизнес-ценности и постоянного улучшения процессов.
- Security (безопасность): Защита информации и систем с помощью надежного управления идентификацией, защиты данных и обнаружения инцидентов.
- Reliability (надежность): Обеспечение того, что рабочие нагрузки выполняются в соответствии с ожиданиями и быстро восстанавливаются после сбоев.
- Performance efficiency (эффективность): Оптимальное использование ресурсов для удовлетворения требований системы.
- Cost optimization (оптимизация затрат): Помощь в отсутствии ненужных расходов при сохранении производительности.
- Sustainability (устойчивость): Фокус на минимизации воздействия на окружающую среду за счет оптимизации энергопотребления.

2) У Microsoft это называется Azure Well-Architected Framework. Он имеет схожие цели и структуру с AWS фреймворком, в нем даже то же самое название, но столпов всего 5 (выпала часть про sustainability)
- Cost optimization (оптимизация затрат): Максимизация ценности при минимизации расходов.
- Operational excellence (операционная эффективность): Эффективное управление операциями и автоматизация процессов.
- Performance efficiency (эффективность): Обеспечение производительности и масштабируемости приложений.
- Reliability (надежность): Построение отказоустойчивых архитектур, способных восстанавливаться после сбоев.
- Security (безопасность): Защита данных и систем через надежные методы безопасности.

3) У Google это называется Cloud Architecture Framework. Он имеет немного другую структуру, но также фокусируется на ключевых принципах построения облачных решений. У него пять столпов:
- Operational excellence (операционная эффективность): Эффективное развертывание, эксплуатация, мониторинг и управление рабочими нагрузками.
- Security, privacy, and compliance (Безопасность, конфиденциальность и соответствие требованиям): Обеспечение безопасности данных, их конфиденциальности и соблюдения нормативных требований.
- Reliability (надежность): Построение отказоустойчивых систем, способных выдерживать сбои.
- Cost optimization (оптимизация затрат): Максимизация бизнес-ценности за счет оптимизации использования ресурсов.
- Performance optimization (оптимизация производительности): Настройка ресурсов для достижения оптимальной производительности.

Из этого краткого описания фреймворков видно, что у них похожие фокусы на оптимизацию затрат, безопасность, оптимизацию производительности, надежность. В общем, на вопросы, которые важны для клиентов, что планируют заезжать в облака (но важны также и при разворачивании on-prem). Эти фреймворки направлены на то, чтобы помочь организациям постоянно оценивать и улучшать свои облачные архитектуры на основе лучших практик, предоставляемых соответствующими облачными провайдерами. Хотя конкретные детали реализации могут различаться между провайдерами, основные принципы остаются схожими на всех платформах.

Кстати, часть научных статей ребят превращаются в мануалы внутри этих фреймворков. Например, раздел "Deployment archetypes" из документации Google изложен в научной статье "Deployment Archetypes for Cloud Applications", которую я разбирал больше года назад в своем блоге.

#DistributedSystems #ExternalReview #SoftwareDevelopment #SoftwareArchitecture #Architecture #SystemDesign #SystemEngineering #Cloud

Корпоративный мессенджер Time

Около полугода назад я уже рассказывал про наш корпоративный мессенджер Time, на который мы оперативно переехали, когда Slack отказался работать с русскими компаниями. За эти пару лет само решение прошло испытание огнем, водой и медными трубами и показало то, что этот мессенджер можно использовать для общения в компании с десятками тысяч сотрудников. Также поверх него можно строить бизнес-процессы и автоматизации (аля chat-ops). Какое-то время назад мы начали продавать это решение разным заказчикам сначала в on-prem варианте, а за последние полгода добавился SaaS вариант, а также mvp для видео-конференц связи. С учетом такого большого количества изменений коллеги решили провести вебинар с продактом и парой клиентов (Атом и Юрент), чтобы рассказать про плюсы и минусы продукта, а также поделится опытом переезда в Time и тем, как они выбирали из доступных на рынке решений.

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

P.S.
Кстати, сайт сильно обновился и стал содержать больше полезной информации навроде базового описания стека решений и интеграций
- Time - это cloud-native решение, которое у нас развернуто в наших целевых runtime окружениях (kubernetes кластерах)
- TIme можно развернуть в геораспределенном режиме (у нас, например, он развернут на 2 геораспределенных дата центра)
- Под капотом используются стандартные стек: Postgres, Kafka, Redis, Open search / Elastic search
- Есть разные виды авторизаций (SAML, AD/LDAP, openID)
- Есть возможность мигрировать с других мессенджеров (Slack, MM, RocketChat)

А также есть чиселки для технарей про один из наших инстансов Time
- 45 тысяч пользователей на инстансе в день
- 2 миллиона cообщений в день
- 80 тыс пользователей
- 5,4 миллиона диалогов создали пользователи
- 186 тысяч каналов создано этими пользователями
- более 1200 ботов создано пользователями благодаря удобной документации
- 99,9% - SLA на доступность

#Software

Экскурсия по стадиону ЦСКА

Были сегодня на часовой экскурсии по стадиону и она нам понравилась:
- На экскурсию пришло человек 30-40, половина из них детей
- Экскурсовод был с хорошим чувством юмора и не просто рассказывал истории, но и делился анекдотами и байками
- Мы прошли через вход, куда заходят футболисты, дошли до раздевалки, прошли к выходу на поле и походили около скамеек команд, сделав ряд снимков, а дальше прошли в комнату для пресс-конференций каа обычно и бывает после окончания матчей

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

#Family #ForKids

ЦЕХ 4 - Урок #21 "Ведение блога и его продвижение в Телеграме. Эксперт — Олеся Полянская" (Рубрика #Writing)

Очередной урок из курса книгописания и книгоиздания от МИФ вела Олеся Полянская, руководитель команды по социальным сетям в МИФ, которая поделилась опытом и знаниями в области ведения блога в telegram. Интересно было послушать этот урок и сравнить со своим опытом:) Мне запомнились следующие тезисы из этой лекции:

1) Telegram по разному используют люди разных возрастов - молодые люди больше общаются, а люди постарше читают каналы
2) После бана части других соцсетей пользователей в tg в последнее стало больше
3) Часть каналов в tg фокусируются на новостях, а другие говорят про "вечные темы"
4) Часто важна не сама информация, а ее интерпретация автором канала, у которого есть свой голос и мнение
5) В tg не очень много алгоритмов, которые рекомендуют контент - это отличает tg от других соцсетей. Поэтому авторам важно сарафанное радио и/или стратегия промотирования через рекламу
6) Важно понимать зачем создаешь канал, какая у него будет аудитория и сколько времени получится на него уделять
7) Логотип канала очень важен, также важны контакты автора, а также способ форматирования текста для его удоства
😍 Теперь есть истории и видео-кружочки, их надо использовать с умом, учитывая ожидания аудитории. В tg также можно вести прямые эфиры
9) Важно писать о том, что интересно автору, а также писать регулярно, чтобы поддерживать доверие и интерес аудитории
10) Каналы в tg можно монетизировать через рекламу в них, но скорее всего и самому придется потратиться на рекламу канала
11) Зарабатывать можно не только на рекламе, но и на консультациях, продаже своих книг и всему остальному - популярный канал поможет этому

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

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

DuckDB: Crunching Data Anywhere, From Laptops to Servers • Gabor Szarnyas • GOTO 2024 (Рубрика #Architecture)

Интересный доклад про аналитическую реляционную базу данных DuckDB, которую можно запускать на своем ноутбуке и успешно обрабатывать объемы где-то до 1 Tb сильно эффективнее, чем на кластере Apache Spark. DuckDB имеет полную поддержку SQL и может читать/писать такие форматы, как CSV, Parquet и JSON. Он построен в соответствии с современной архитектурой, которая позволяет выполнять сложные запросы параллельно и выгружать на диск рабочие нагрузки, превышающие объем памяти.

В этом докладе Габор, технический писатель из DuckDb, рассказывает про ключевые составляющие DuckDB и демонстрирует, как DuckDB может обрабатывать сотни ГБ данных на ноутбуке или терабайты данных на одном сервере. Основные моменты следующие

1) Демо работы с CSV файлом на 15 Gb для анализа информации о задержках прибытия поездов - в демке видно, что все работает очень быстро. В продолжении демки Габор показывает, что можно увеличить количество данных в 40 раз и дальше после 15 минут загрузки данных те же самые запросы будут уже занимать десятки секунд, но это все равно быстрее, чем грузить данные в облако и дальше выполнять их там. Потом Габор показывает как DuckDB поддерживает стандартные SQL функции вида rank over, pivot, unpivot
2) Архитектура DuckDB выглядит как single-file database:) Условно, вы взаимодействуете с ней внутри вашего приложения и отдельного сервера как такового нет. Здесь она похожа на SQLite, который похожим образом работает для OLTP нагрузок, а DuckDB предназначен для аналитических нагрузок
3) Дальше автор переходит к обсуждению хранения и обработке данных и вспоминает про строчное и колоночное хранение (row-oriented vs column-oriented)
- Транзакционные системы используют строчное хранение, а системы на основе столбцов — столбцовое.
- Столбцовое хранение позволяет эффективно сжимать данные и удалять ненужные столбцы.
- Выполнение по столбцам удобно для аналитики, но может привести к нехватке памяти.
И дальше он рассказывает про векторизацию и кеш процессора, которая позволяет обрабатывать данные векторами, что экономит память. Векторы выбираются такого размера, чтобы помещаться в кэш процессора. Вообще, векторизация кода усложняет перенос между архитектурами, но современные компиляторы автоматически векторизуют код. И в DuckDB используются zonemaps для оптимизации индексации, а также DuckDB не имеет внешних зависимостей, что делает его портируемым на разные архитектуры.
4) DuckDB поддерживает множество форматов и протоколов, включая CSV, Spark, JSON, Delta и Iceberg. Есть поддержка протоколов HTTPS, AWS S3 и Azure Blob. Существует возможность подключения к транзакционным базам данных и интеграция с Pandas и NumPy.
5) У DuckDB есть интеграция с Pandas и NumPy что позволяет читать данные без создания копий. DuckDB работает параллельно, что ускоряет чтение данных по сравнению с самим Pandas
6) DuckDB в июне выпустил обновление и достиг 19 тысяч звезд на GitHub и 30 тысяч подписчиков в LinkedIn и Twitter. Недавно вышла версия Snow Duck с акцентом на стабильность и обратную совместимость.
7) У DuckDB есть множество расширений, которые основаны на механизме для добавления новых функций, типов данных и операторов. Примеры расширений: HTTPFS, JSON, Parquet
😍 DuckDB можно использовать для сокращения расходов на облачные хранилища данных за счет выполнения части вычислений локально. Автор показал TPC-H эксперимент с обработкой Parquet файлов через DuckDB и Apache Spark. Если файл небольшой, то затраты на координацию в Spark убиывают всю производительность
9) У DuckDB есть ограничения - она не поддерживает параллельные запросы на запись, а также работает на одной ноде
10) DuckDB финансируется за счет прибыли и консультирует крупные компании, фонд DuckDB обладает правами на код, а MotherDuck сооздает облачную версию DuckDB

#Database #Architecure #Software #Data #SystemDesign

The Engineering Executive's Primer - Part III (Рубрика #Management)

Продолжая первые посты об этой крутой книге (0, 1, 2) с обзором книги, я хотел бы рассказать про следующие главы.

7) Participating in Mergers and Acquisitions
В этой главе автор говорит про участие ИТ топ-менеджеров в merge & acquisitions процессах. Для начала автор разбирает про сложные мотивы для m&a действий - условно цели команды, что ведет сделки, отличаются от целей инженерных команд. В общем, важен общий взгляд на процесс и понимание бизнес-стратегии, чтобы оценить соответствует ли поглощение целям компании и выявить потенциальные риски. Отдельно автор описывает структурированный подход к оценке поглощений с инженерной точки зрения, куда входит создание шаблонов для оценки сложности внедрения, проблем интеграции, масштабируемости, безопасности, соответствия требованиям, затрат и инженерной культуры. Важно также запланировать интеграции между объединяемыми компаниями - важен четкий план интеграции для эффективного управления переходом после поглощения. Это включает решения по интеграции технологий, реструктуризации команд и роли лидерства. А дальше надо управлять этим процессом.

😍 Developing Leadership Styles
Автор предлагает модель из трех подходов к управлению
- Leading with policy - для повторяемых решений, которы надо делать консистентно разными людьми внутри организации
- Leading from consensus - для нечастых решений с контекстом, который распределен между несколькими заинтересованными сторонами.
- Leading with conviction - для решений без четкого предложения, когда вовлеченные лица сильно расходятся во мнениях или когда решение оказывает значительное долгосрочное влияние на вашу организацию
В этой главе автор приводит примеры из своего опыта в разных компаниях (Digg, Uber, Stripe, Calm). А дальше говорит о том, что надо уметь работать над прокачкой тех стилей лидерства, что несвойственны вам. Это позволит вам стать более универсальным руководителем:)

9) Managing Your Priorities and Energy
В этой главе автор рассказывает про свою стратегию к решению задач вида "Компания - Команда - Я". Изначально автор рекомендовал принимать решения, основываясь на иерархии: сначала компания, затем команда, и в последнюю очередь — личные интересы. Этот подход использовался для обеспечения соответствия решений целям компании, а не личным или командным предпочтениям. Однако позже автор осознал, что такая жесткая структура может привести к выгоранию и потере мотивации среди сотрудников. Но дальше автор подчеркивается важность управления энергией как процесса с положительной суммой. Предполагается, что предоставление людям возможности заниматься работой, которая их вдохновляет, даже если она не соответствует непосредственным приоритетам, может повысить общую продуктивность и удовлетворенность работой.

В итоге, концепт "Company, Team, Self" изменяется на подход "Eventual Quid Pro Quo", которая балансирует приоритеты компании с личными потребностями в энергии. Этот подход поощряет приоритизацию вдохновляющей работы при необходимости для поддержания долгосрочной вовлеченности и эффективности. Автор подчеркивает необходимость гибкости в применении стратегий. Утверждается, что хотя следование правильным приоритетам важно, это не должно происходить за счет личной энергии и мотивации. Лидеры должны адаптировать свои подходы в зависимости от личных нужд и контекста их ролей.

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

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

Кем может стать системный аналитик - подкаст InSAйт (Рубрика #Career)

Недавно сходил в гости к своим коллегам на подкаст InSAйт, который ведут Павел Каравашкин, руководитель группы разработки T-API, и Есения Киселева, старший системный аналитик, управление разработки продуктов эквайринга в Т-Банке. Темой разговора было карьерное развитие системных аналитиков, о котором я когда-то размышлял на конференции Flow. В итоге, мы обсудили темы
- Почему я когда-то не захотел быть системным аналитиком, а Паша – системным архитектором;
- Можно ли одновременно сохранять фокус на менеджерских и технических скиллах;
- Кем может стать системный аналитик и какие навыки ему важно качать;
- Что такое white paper и чем этот формат может быть полезнее книг;
- Как сделать доменные области более понятными для разработчика.

У этого подкаста есть свой канал в tg (@insight_t_bank), подписавшись на который можно узнавать о новых выпусках.

#Analyst #SoftwareDevelopment #Career #Podcast #SystemDesign #SystemThinking

В выходные у нашего младшего сына Кирилла был день рождения, ему исполнилось 4 года. На день рождения мы придумали активность для него и всех гостей - пойти в детский клуб, где дети побесились 3 часа в сумме, причему последний час был посвящен раскаршиванию помещения и друг друга. Так у меня появилась новая красочная аватарка:)

Масштабирование комплаенс-контроля надежности на сотни сервисов - Салих Фахрутдинов, Т-Банк

Интересный доклад моего коллеги, Салиха, который Staff SRE инженер в Origination Business Platform. В этом докладе Салих рассказал о том, как можно обеспечивать надежность сотен разных сервисов за счет контроля инвариантов, который реализован через стороннее приложение. В этом приложении настраиваются различные правила для проверок, например, использование разных портов для проб (liveness, readiness, startup), настроек java приложений (падение от OOM), параметров СУБД, наличие алертов на критические SLA и так далее. Дальше эти правила можно пополнять реактивно (после инцидентов) или проактивно по результатам исследований на улучшение надежности приложений. Само это приложение собирает информацию о соблюдении правил и позволяет сформировать отчет в виде leaderboard. Те руководители, чьи сервисы оказываются внизу лидерборда, обычно имеют нехилую мотивацию на устранение найденных проблем.

В принципе, другой вариант реализации этой логики проверок - это реализация внутри пайплайна поставки, примерно так работает наш Quality Gate, который проверяет уровень автоматизации тестирования. Но ребята решили пойти другим путем, чтобы иметь возможность проверить проиложения не только перед деплоем или вовремя деплоя, но и дальше по мере их работы в продакшене.

P.S.
В software architecture такие проверки предлагается делать через fitness functions, которые предлагались в книге "Building evolutionary architecture". Вот эпизод подкаста "Code of Architecture", в котором мы говорили об этом концепте.

#Architecture #Management #Leadership #SRE #Engineering #Software

Research Insights Made Simple #3 - Обсуждение paper "Security by Design at Google" (Рубрика #Security)

В третьем эпизоде подкаста мы обсуждаем интересный whitepaper "Secure by Design at Google" от Chirstoph Kern на тему security с человеческим лицом от Google, где рассказывалось о том, как создавать безопасный софт на большом масштабе. В разборе мне помогает крутой гость - Артем Мерец, мой коллега. Артем был разработчиком и 10 лет назад перешел в информационную безопасность. Он активно строил AppSec, когда он начал зарождаться в РФ как стрим, а затем увлекся атаками и несколько лет ломал инфраструктуру и приложения разных компаний в РФ и за пределами. И с 2021 помогаю выстраивать защиту Т-Банка в роли архитектора.

Сама научная статья доступна на сайте Google, а в моем блоге есть разбор

В этом выпуске мы обсудили следующие темы
- Общие впечатления от статьи
- Логические уязвимости и подходы Google
- Сложности безопасной разработки
- Концепция Security by Design
- Примеры безопасности из автомобильной индустрии
- Проблемы аудита кода
- Принципы безопасного дизайна
- Проблемы с инвариантами
- Автоматизация и категоризация инвариантов
- Применение инвариантов
- Проблемы безопасности в системах
- Примеры защиты от злонамеренных действий
- Дизайн для безопасности
- Shift left everything в разработке
- Проблемы и решения в безопасности
- Проект Yaga в Т-Банке
- Логические уязвимости
- Безопасная экосистема разработки
- Проблемы с памятью и микросервисной архитектурой
- Проблемы с безопасностью и инфраструктурой
- История о стажере-саботажнике в ByteDance
- Контроль артефактов и безопасность
- Экосистема для разработчиков

#Architecture #Security #CI #CD #Devops #Software #Management #Leadership #Engineering #Podcast

Обложки книг "Ухожу в Stand Up!" и "Mastering Stand-Up"

Ухожу в Stand Up! (Mastering Stand-Up) (Рубрика #Humor)

Это не утверждение, а название очередной книги, которую я дочитал буквально этой ночью. Книга попала ко мне интересным образом - пару месяцев назад меня позвали выступить на внутреннее мероприятие на всю компанию в формате стендапа. Я немного подумал над темами и выбрал одну из двух, про которые я обычно рассказываю - это была тема "Архитектуры", потому что про менеджмент шутили два других спикера. Как обычно, когда я сталкиваюсь с новой темой, то покупаю книги по ней - кажется, что еще с детства у меня пошла история о том, что получение книги == получению знаний из книги. В итоге, выступление на стендап я подготовил, но книгу прочитать не успел. Хорошо, что я заявился с этой же темой "Архитектура в Т-Банке: вчера, сегодня, завтра" на ArchDays и взял книгу в проработку. На прошлой неделе я рассказал этот доклад, а ночью дочитал последние страницы книги. Конечно, конференция по архитектуре - это не стендап-шоу, поэтому пришлось разбавлять шутки занудной теорией до гомеопатического состояния, но часть пользователей в отзывах к докладу отметила чувство юмора (ладно, это заметил один человек).

Если говорить о самой книге, то ее написал Стивен Розенфилд, основатель Американской школы комедии, который поставил обучение комиков на поток и в этой трехсотстраничной книге поделился своими рецептами становления хорошим стендапером. В книге 5 частей
1) Начинаем сотрудничать - в этой части автор подбадривает читателя и рассказывает о пути, который ему предстоит пройти, чтобы стать успешным: выясни в чем, твоя оригинальность, научись писать тексты для стендапа, отточи мастерство выступлений, придумай сценического персонажа, постоянно выступай и так далее
2) Виды стендап-комедии - здесь автор перечисляет виды, показывает примеры и объясняет разницу между ними. Например, он говорит о комедии наблюдений, сторителлинге, стендап-скетчах, акт-аутах, унижениях знаменитостей или людей из своего окружения, самоиронию, юмор на грани фола и так далее
3) Руководство по созданию материала для стендап-комедии - здесь автор рассказывает что делать до того как сесть за черновик, дальше как работать с черновиком, как обкатывать материал из него, как дорабатывать шутки формата сетап - панчлайн через фидбек аудитории на выступлениях (тут используется принцип working backwards для шлифовки и усиления шуток)
4) Руководство по выступлению со стендап-комедией - автор описывает что делать с волнением перед выступлением, как вести себя на сцене, как уложиться в регламент и что делать если шутка не зашла:)
5) Как добиваться непревзойденного мастерства - здесь автор рассказывает про классификацию шуток "A", "B", "C" и описывает как составить сет из шуток класса "А". Как создать удачный сценический образ, который должен быть оригинальным, правдоподобным, ярким, вызывать симпатию, иметь сценическое обаяние и смешную суть. Прикольно, что автор дает список причин почему шутка, которая раньше разрывала зал, стала уходить в тишину - а дальше он дает рекомендации как это можно исправить. Финалит последнюю часть автор рассказом про то, как быть ведущим и как победить свой внутренний голос, который мешает достигать своих целей (в данном случае быть смешным).

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

#Humor #PublicSpeaking #Leadership #SelfDevelopment

Как стать продуктивнее в IT, если вы уже прокачали свои харды (Рубрика #Management)

Через 3 недели я выступлю на конференции soft weekend, первой софтовой офлайн-конференция в России (что бы это ни значило). Я не могу сказать, что люблю рассказывать чисто про софты, но эту конференцию организует мой знакомый, Андрей Смирнов, автор подкаста "Frontend Weekend", куда я ходил в гости в прошлом году. В итоге, я решил рассказать что-то из серии набора качеств и навыков, что важны для всех: и для крутых инженеров и для начинающих маркетологов. В этот список вошли
- Умение планировать свое время (а дальше если повезет и своей команды)
- Умение и желание брать на себя ответственность (и главное доводить сложные дела до конца)
- Навыки общения с коллегами и договороспособность (эта часть часто западает)
- Навыки самомотивации и мотивации окружающих (правда, если разбираться в вопросе, то внешняя мотивация - это скорее стимуляция)

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

Конференция пройдет очно 23 ноября в Пространстве Весна, Спартаковский п., 2с1. Купить билет можно здесь

#Leadership #Processes #Management

Открытая менторинг сессия со мной на SouthHub (Рубрика #Management)

12 ноября в 19:00 я проведу открытую сессию менторинга на канале SouthHub. Менти выберут организаторы канала SouthHub, а подать заявку на участие может любой желающий. Запрос по менторингу может быть на одну из следующих тем
- Как выбрать орг. дизайн команд под задачи бизнеса: как понять, что требуется, как организовать команды.
- Как выстроить процессы в командах — discovery & delivery, архитектурные процессы и процессы обеспечения надежности.
- Как измерять эффективность процессов — какие метрики бывают и насколько им можно верить.
- Как осуществлять крупные изменения в больших компаниях.
- Как работать над техническим брендом параллельно с основной работой.

Сама сессия будет доступна в виде видео на канале SouthHub.

#Management #Leadership #Processes #Engineering #Software

"Архитектура в Т-Банке: вчера, сегодня, завтра" на конференции ArchDays 2024 (Рубрика #Architecture)

Сегодня в 15.40 я выступаю на конференции ArchDays с докладом "Архитектура в Т-Банке: вчера, сегодня, завтра", в котором я расскажу про развитие подходов к проектированию и архитектуре в Т-Банке с начала времен и до текущего момента. Я постараюсь объяснить какие причины побуждали нас меняться и как мы осуществляли сами изменения. Я расскажу про процессы и людей, которые занимаются у нас проектированием и почему архитектор - это не должность, а роль. А закончу тем, что расскажу куда мы движемся дальше.

Вот дополнительные материалы для изучения, которые я рекомендую к своему выступлению
1) "Эволюция web’а tinkoff.ru за последние 3 года" (youtube) - мое выступление на ArchDays 2019, в котором я рассказываю как мы переходили от коробочного решения к собственной разработке в одном из доменов
2) "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения" (youtube, статья с расшифровкой) - мое выступление на ArchDays 2020, в котором я рассказываю про архитектурные подходы, к которым мы пришли по итогам масштабной собственной разработки и какую мы ставку делали на платформизацию
3) "DevOps-эры в Тинькофф: культура, люди, инструменты" - выступление моего бывшего коллеги Станислава Халупа на Kuber Conf 2021 года, где он рассказывал про platform engineering и почему это направления стало важным для нас (мое саммари по выступлению, само выступление на youtube)
4) "Technical Governance для IDP на 7000 разработчиков" - статья Дмитрия Гаевского про governance для нашей внутренней платформы разработки Spirit (это расшифровка его выступления на Highload++ 2021)
5) Раздел про технологии на нашем сайте - здесь можно почитать про наши платформенные решения
6) "Code of leadership #17 - Interview with Anton Kosterin about Architecture" (youtube, ya music, пост) - серия подкаста с Антоном Костериным, моим замом, который помогает мне строить architecture governance
7) "Research Insights Made Simple #1 - API Governance at Scale" (youtube, ya music, пост) - первая серия подкаста с разбором научных статей, где я с моим коллегой разбирал подход к API Governance в Google, а также мы активно проводили параллели с architecture governance в нашей компании
8) "Measuring Developer Goals" - мой обзор статьи от Google на тему того, куда стоит двигаться платформе разработки, чтобы оптимально поддерживать цели инженеров при разработке софта

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #SystemDesignInterview #DistributedSystems

Code of Leadership (Рубрика #Management)

Примерно год назад я стартанул подкаст про engineering management с названием Code of Leadership. За это время получилось выпустить 21 эпизод, но я не планирую на этом останавливаться:) Подкаст доступен в Youtube и Ya Music.
Вот ссылки на материалы по каждому эпизоду:

1) Team topologies со Станиславом Халупом
2) "Antifragility in IT" с Александром Бындю
3) "Herding Cats" с Женей Кузовлевым
4) "Turn the ship around" с Екатериной Шестимеровой
5) "Project Phoenix" с Иваном Михеевым
6) Интервью про Staff+ инженеры, архитектура и SDLC с Алексеем Тарасовым
7) "Your brain at Work" с Эрнесто Инаркиевым
8) Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)
9) "An Elegant Puzzle - System of Engineering Management (часть 1)" с Eugene Sergueev
10) "An Elegant Puzzle - System of Engineering Management (часть 2)" с Eugene Sergueev
11) Интервью с Кириллом Крайневым про системных аналитиков в Тинькофф
12) Интервью с Димой Гаевским про платформу Spirit (Internal developer platform) в Тинькофф
13) "Accelerate" с Игорем Курочкиным
14) Interview with Artem Ivanov about Risk Tech
15) Interview with Roman Lebed about Information security
16) "The Five Dysfunctions of a Team" с Андреем Соколовым
17) Interview with Anton Kosterin about Architecture Governance
18) Interview with Pavel Akhmetchanov about Processes and Tools
19) Interview with Evgeny Sokolov about Modern Education
20) Interview with Alexey Grishin about Software Architecture
21) "A Philosophy of Software Design" с Гришей Скобелевым

#Architecture #Processes #Management #Leadership #Software #Statistics #Project #Productivity #ProductManagement

CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async (Рубрика #ComputerScience)

Я часто рассказываю про то, что надо знать базу для того, чтобы развиваться в software engineering. Но обычно сложно описать, а что же входит в это определение "база" и является джентельменским набором хорошего инженера. Но тут мой коллега, Женя Козлов, крутой инженер, написал серию статей про процессоры, модели памяти, многозадачность и конкурентность. В этой серии разбираются моменты, которые полезны инженерам, что делают высоконагруженные системы, которые плотно работают с данными. Собственно, сам Женя у нас лидит команду, что занимается Statist - это наша система продуктовой аналитики, которая давно заменила нам Amplitude и по всем характеристикам тянет на data intensive application. В общем, я очень рекомендую вам эту серию статей от Жени, если вам интересно понять как компьютер обрабатывает под капотом те программы, что вы пишите на своем любимом языке программирования.

1) Начальный пост про многозадачность в OS
2) Про развитие процессоров и взаимодействие OS с ними
3) Про Hyper Threading
4) Процессы. Начало
5) Процессы в Linux
6) Потоки. Начало
7) Потоки в Linux
😍 Модели ввода-вывода. Универсальная(блокирующая) модель ввода-вывода
9) Multiplexed IO
10) Asynchronous IO

#Software #ComputerScience #Engineering #SRE #Architecture

Research Insights Made Simple #2 - Обсуждение paper "Defining, measuring and managing technical debt" (Рубрика #Management)

Это второй выпуск подкаста с разбором научных статей, которые посвящены разным темам computer science и engineering management. В этом выпуске мне помогает мой коллега, Дмитрий Гаевский, Technical CPO (Chief Product Owner) нашей внутренней платформы разработки Spirit. Для второго выпуска мы взяли научную статью про технический долг и то, как он влияет на продуктивность инженеров. Эта статья от ребят из Google вышла в 2023 году.

Основные материалы
- Whitepaper доступен здесь
- Мой разбор whitepaper есть в блоге

В этом выпуске мы успели обсудить темы
- Исторический контекст и метафора технического долга
- Долг или инвестиции в качество кода
- Исследование технического долга в Google
- Категории технического долга в общем
- Категории, выбранные для исследования
- Измерение технического долга
- Проблемы с метриками и целевыми состояниями
- Концепция opportunity cost
- Проблемы с термином "технический долг"
- Управление техническим долгом
- Альтернативы термину "технический долг"
- Результаты работы с техническим долгом в Google
- Объединение объективных и субъективных данных
- Проблемы разделения технической и продуктовой работы
- Альтернативные подходы к техническому долгу

#Architecture #Software #Management #Leadership #Engineering #Podcast

Иллюстрации для книги "Карта гипотез"

The Engineering Executive's Primer - Part I (Рубрика #Management)

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

0) Preface
Во введении автор рассказывает про то, как он пришел к идее этой книги после предыдущих книг "Staff Engineer" и "An Elegant Puzzle. Systems of Engineering Management". Первая является классным источником информации по карьерному пути для инженеров, которые переросли уровень senior и отправились покорять новые моря. Я про нее уже рассказывал: 1 и 2. Вторая книга хороша для engineering managers, про которую я рассказывал раньше, а потом было две серии подкаста "Code of Leadership" с разбором этой книги вместе с Eugene Sergueev, senior engineering manager из Flo health: 1 и 2
1) Getting the Job
Начинает книгу автор с того, чтобы рассказать про то, а как же можно получить работу в качестве engineering executive. Для начала стоит ответить себе на вопрос, а точно стоит в это вписываться? Дальше возникают вопросы, а где это делать: внутри текущей компании или во внешней. Дальше автор обсуждает хаотичный процесс найма топов, который отличается от компании к компании, а дальше еще идет и обсуждение условий. Ну и заканчивается все тем, а как размышлять относительного того, а принимать офер или нет. В общем и целом, глава действительно неплохо описывает этот непростой процесс и дает структуру и подход для взвешенного принятия решений.
2) Your First 90 Days
Здесь автор говорит о том, что в первые 90 дней придется серьезно попотеть и начать с того, чтобы разобраться с тем как работает бизнес и откуда приходят деньги, что определяет культуру компании, как установить здоровые взаимоотношения со стейкхолдерами и своими peers, насколько хорошо функционирует инженерная команда с точки зрения delivery, насколько высоко техническое качество софта и инструментов для поддержки процессов разработки, что с моралью инженерной команды и насколько сама команда устойчива для выбранного темпа развития команды. Дальше важно ограничить количство ранних изменений, что вы делаете в первые 90 дней. Кроме этого важно выстроить доверие с коллегами и позаботиться о поддержке с их стороны. Вообще, классно разобраться как в компании осуществляется работа и как выглядят технологии (включая код и деплой, дежурства, работа с инцидентами, ...)
3) Writing Your Engineering Strategy
Эту главу я разбирал еще тогда, когда она была просто статье в блоге автора. Статья была отличной и она не стала хуже после превращения в книжную главу:)
4) How to Plan
Автор рассказывает про стандартный подход к планированию в компаниях:
- Ежегодное финансовое планирование (включая план по headcount)
- Полугодовые или квартальные планы, например в виде OKRs для команд. Эти планы таргетируют бизнес результаты или список проектов, что надо сделать
- Внутрикомандные процессы управления работой (Kanban, Scrum, etc), которые направлены на то, чтобы уложиться в квартальные/полугодовые планы
- Отдельно автор говорит о том, что могут быть еще и периодические ревью, например, каждый месяц. Эти ревью направлены на отслеживание прогресса по выполнению целей компании

Продолжение в следующих постах: 2

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

The Engineering Executive's Primer - Part 0 (Рубрика #Management)

Я уже давно прочел новую книгу Will Larson для IT топ-менеджеров, про которую я писал раньше. Прочел и прочел, но все как-то не доходили руки написать про нее, но сейчас я в очередной раз сижу в аэропорту и жду самолета, поэтому время есть:) Сразу скажу, что книга мне понравилась - у Вилла как обычно отлично со структурой книги, а отдельные главы достаточно емкие и наводят на размышление (интересно, что они обычно появляются как статьи в блоге lethain.com, один из немногих блогов, что я читаю)

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

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

System Design Interview - Highload++ 2024 (Рубрика #Architecture)

В этом году я зайду в декабре на Highload++, чтобы подискутировать на тему system design interview. Этот формат собеседования стал достаточно популярным в крупных компаниях6 а кто-то его вкручивает в свой процесс собеседований как карго-культ. В этои дискуссии мы обсудим
- Что это за тип интервью
- Зачем он нужен компаниям и можно ли обойтись без него
- Какие у него есть плюсы и минусы

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

P.S.
До этого я уже рассказывал про процессы найма в большие компании и типы интервью на примере Т-Банка. Про System Design у меня тоже было много материалов. Например можно посмотреть в общем про system design в Tinkoff, больше про то, как мы оцениваем прохождение собеседования и как подготовиться к собеседованию или публичные интервью на ArchDays

#Career #HR #Management #Architecture #Software #Leadership #Processes

API Design Patterns (Паттерны проектирования API) (Рубрика #Architecture)

В последнее время я много изучаю материалов на тему governance. Туда входит architecture governance, API governance и другие подходы для того, чтобы двигаться в сторону engineering excellence. И так получилось, что я в выходные снял с полки эту книгу "API Design Patterns" из последней закупки на распродаже в издательстве "Питер". Книгу написал Джей Джей Гивакс, соавтор статьи "API Governance at Scale" про подходы в Google. Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta - это видно по заглавной страничке с авторами whitepaper:)

Когда я начал читать эту книгу, то понял, что она очень хороша - автор четко и методично рассказывает про паттерны для создания ресурсно-ориентированных API. Он делится теми подходами, к которым пришли ребята в Google и делает очень доступно. В общем, пока я еще всю книгу не прочитал, но уже могу порекомендовать ее для прочтения.

P.S.
Я разбирал статью "API Governance at Scale" в первом выпуске нового подкаста "Research Insights Made Simpe" (видео в Youtube, подкаст в Ya Music). Отдельно разбор есть в моем блоге в виде статьи.

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

Testing strategy: avoid the waterfall strategy trap with iterative refinement (Рубрика #Management)

Очередная интересная статья от Will Larson, который постепенно создает свою новую книгу про стратегию. В этой главе речь идет про гибкое тестирование стратегии и улучшение ее на основе обратной связи:) Как обычно у Вилла все очень структурно

1) Когда стоит тестировать стратегию?
Когда хочется понять насколько она достижима и сколько реально будет стоить. По-факту, автор предлагает перед ее финализацией делать аля PoC (proof of concept), который позволит собрать недостающую информацию. Но иногда это можно не делать - например, при разрешающей стратегии (ее имплементация стоит не дорого), при слишком долгом ожидании обратной связи (вопросы с наймом в разных регионах) или когда мы почти уверены в своей стратегии

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

3) Роли для тестирования стратегии
Автор выделяет роль спонсора и руководителя (guide). Собственно один авторизует стратегию и помогает ей случиться, а второй ее реализует, отслеживает выполнение и эксалирует в случае проблем. Забавно, что я успел побывать и тем и другим за время карьеры:) Важно, чтобы эта пара могла принимать сложные решения быстро, а не уходила в paralysis of analysis

4) Meetings & Metrics
Единственное обязательное требование для этапа тестирования стратегии — спонсор, руководитель и все ключевые лица, работающие над стратегией, должны встречаться каждую неделю. В ходе этой встречи надо смотреть на показатели, что отражают текущие области, которые вы пытаетесь улучшить, обсуждать, чему вы научились на основе предыдущих показателей или данных, а также планировать разовые контрольные проверки, чтобы убедиться в прогрессе.

5) Выявление стратегий, не прошедших тестирование
Хотя не все стратегии должны быть уточнены в ходе фазы тестирования, по сути, все неудачные стратегии пропускают фазу тестирования, чтобы перейти непосредственно к реализации. Стратегии, которые пропускают тестирование, звучат правильно, но не достигают многого. Один из самых стандартных паттернов провала - это "давление без плана", когда стратегия представляет собой лишь аспект «звучит правильно» без каких-либо деталей. Я видел много таких стратегий

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

В финале автор говорит о том, что тестирование не поможет понять, а может ли стратегия быть хорошей. Но оно позволит выявить недостающие детали, необходимые для перевода стратегии в работающее состояние:)

#Management #Strategy #Leadership #Software

Обложки для книг "The Tyranny of Metrics" и "Тирания показателей"

The Tyranny of Metrics (Тирания показателей) (Рубрика #Management)

Эта интересная книга за авторством Muller Jerry вышла в 2018 году в Princeton University Press, а в 2020 году ее перевели в Альпине. Мне понравилось название, которое идет наперекор стандартному подходу к измерению всего и вся:) В итоге, книга напоминает по структуре научную статью. А когда я начал читать эту книгу, то легко узнавал проблемы, которые классно описывал автор. Во многом они рождены из закона Гудхарта "Когда мера становится целью, она перестает быть хорошей мерой". В итоге, автор не предлагает отказаться от показателей, а скорее говорит о том, что помимо них должны быть качественные показатели и мнение разбирающихся в теме людей, которые принимают решение. Иначе получится как с XSolla, где были уволены сотрудники с аргументацией, что "биг дата» показала их невовлеченность".

Вот содержание книги
0) Введение - автор рассказывает о том, как он, работая в сфере образования профессором и завкафедрой, оказался вынужден сдавать все больше и больше отчетов по мере обвешивания системы образования метриками. Дальше он заинтересовался историей вопроса и в итоге получилась эта книга
1) Постановка проблемы - в этой части автор рассказывает об одержимости показателями и к чему это может приводить. Делает это он в главах с кратким описанием проблемы и перечнем характерных ошибок
2) История проблемы - так как автор - это учений с интересами в истории, экономики и политики, то он глубоко погружается в историю вопроса и рассказывает про
- Происхождение системы вознаграждения в зависимости от результата (pay for performance)
- Почему количественные показатели стали такими популярными
- Принципалы, агенты, мотивация (внутренняя и внешняя)
- Философия и критика
3) Можно ли применять количественные оценки ко всему подряд - тут автор разбирает на конкретных примерах результаты применения чрезмерной количественной оценки
- В образовании - автор разбирает колледжи и университеты
- Школы - автор рассказывает про зарубежный опыт, но мы все можем видеть результаты ЕГЭ
- Здравоохранение - тут автор показывает как рейтинг хирургов на основе успешных операций приводит к тому, что они отказываются от сложных операций и предлагают сразу ехать на кладбище
- Охрана правопорядка - тут цель в снижении преступности приводит к тому, что часть преступлений классифицируют как менее тяжкие, которые не входят в рейтинг или просто не реагируют на часть обращений
- Вооруженные силы - тут гонка за показателями особенно вредна в сценариях борьбы с террористами, повстанцами и другими иррегулярами
- Бизнес и финансы - тут автор проходит по KPI, OKR, вспоминает разгон показателей для радости инвесторов, подделывание отчетности. В итоге, часто менеджеры концентрируются на операционных показателях и перестают думать о стратегии развития
- Благотворительность и помощь другим странам - автор говорит о том, что тут методы бизнеса работают не очень, так как вовлеченные в благотворительность часто ориентируются на свою внутреннюю мотивацию, а внешние KPI начинают ее подмывать:)
4) Экскурсы. Автор показывает что иногда прозрачность - это враг результативности. Он делает это на примере политики, дипломатии, разведки и браков:)
5) Выводы. Сначала автор рассказывает о непредвиденных, но предсказуемых последствиях увлечения показателями, а потом говорит о том, а когда и как применять количественные показатели. Про эту часть я расскажу отдельно позже.

В общем, книга мне очень понравилась, так как я часто вижу описанные автором проблемы и стремлюсь их исправить. Иронично, что продуктовая аналитика и a/b платформа, что нужна для контролируемых экспериментов, а также metric store, где должны считаться метрики по продуктам для всей организации, сейчас находится в моем юните, а значит правильное применение данных - это отчасти и моя профессиональная задача:)

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

#Data #Statistics #Management #Leadership #Processes

Research Insights Made Simple #1 - Обсуждение paper "API Governance at Scale" (Рубрика #Architecture)

Это первый выпуск подкаста с разбором научных статей, которые посвящены разным темам computer science и engineering management. В этом выпуске мне помогает мой коллега, Даниил Кулешов, Staff Engineer, который развивает вместе со мной в Т-Банке архитектурную функцию на уровне всей компании.

Для первого выпуска мы взяли научную статью про governance, а точнее про API governance от ребят из Google, которая вышла в 2024 году. Сама статья достаточно хорошо раскрывает тему governance, что позволяет закрыв глава подставить на место API слово architecture и многие мысли и выводы авторов останутся корректными.

Основные материалы
- Whitepaper доступен здесь - https://research.google/pubs/api-governance-at-scale/
- Мой разбор whitepaper есть в блоге - https://tellmeabout.tech/review-whitepaper-api-governance-at-scale-fdab581b8489
- Перечень Google стандартов на API доступен здесь - https://google.aip.dev/

#Software #Architecture #DistributedSystems #Whitepaper #Management #Processes #Leadership

Сервис Unidraw.io от T-Bank - наш ответ Miro - Продолжение (Рубрика #Visualisation)

Раньше я уже анонсировал этот инструмент в отдельном посте, а теперь
1) Я уже обкатал этот инструмент при создании обзоров всех whitepapers, про которые я рассказывал с сентября, а также при проведении System Design Interview
2) Пару дней назад на Хабре появился рассказ про бекстейдж развития этого инструмента у нас в компании "Unidraw — путь длиной в два года"

Если говорить про обзоры статей, то визуализаций в Unidraw мне хватает и я не часто вспоминают про Miro. Для демонстрации тезиса я решил пошарить все эти доски, чтобы вы могли проверить все сами - ближайший месяц они будут доступны и неавторизованным пользователям, а потом придется все-таки заводить аккаунт, чтобы их посмотреть:)
1) Defining, measuring and managing technical debt - статья с обзором и доска
2) API Governance at Scale - статья с обзором и доска
3) Hybrid Productivity - статья с обзором и доска
4) A Human-Centered Approach to Developer Productivity - статья с обзором и доска
5) Measuring Developer Goals - статья с обзором и доска
6) Software quality - статья с обзором и доска
7) AI-Enhanced API Design: A New Paradigm in Usability and Efficiency - статья с обзором и доска
8) Secure by Design at Google - статья с обзором и доска

В общем, я как опытный пользователь Unidraw могу отметить, что инструмент уже работает хорошо, а также в него постоянно доезжают новые фичи:) Кстати, фичу с прямоугольными стикерами сделали по моей просьбе - она мне нужна была как раз для переезда на Unidraw с моими обзорами статей и книг:) Спасибо ребятам, что создали инструмент и продолжают его дорабатывать!

У инструмента есть свой канал t.me/unidrawio и чат для пользователей t.me/unidrawiochat, так что у пользователей есть возможность быть в курсе новостей и доносить обратную связь напрямую команде.

#Data #Visualization

Architecture Modernization: Aligning Software, Strategy & Structure • Nick Tune • GOTO 2024 (Рубрика #Architecture)

Интересный и полезный доклад на тему модернизации архитектуры существующих систем от Nick Tune, principal consultant at Empathy Software. Если сократить доклад, то тезисы примерно такие:
- Успешным компаниям часто требуется модернизация архитектуры, так как их прежняя архитектура: предназначена для меньшего объема клиентов и не тяент нужную нагрузку, опирается на старые технологии, которые не позволяют добавлять фичи с нужной скоростью. В итоге, модернизация может превратить недостатки в достоинства
- Такая модернизация касается не только технических вопросов - на самом деле надо оценивать весь стек от UX до глубоких бекендов, включая огрструктуру и процессы работы сотрудников
- В модернизации могут помочь разные инструменты, но автор выделяет следующие 5 штук
1) Listening Tours - сюда обычно входят опросы, интервью с сотрудниками, фокус-группы, gemba и так далее. Задача в том, чтобы услышать своих сотрудников
2) Impact mapping - это простая методика совместного планирования для команд, которые хотят добиться большого эффекта с помощью программных продуктов.
3) Wardley mapping - это карта бизнес-стратегии, где компоненты располагаются по оси Y, что обозначает положение в цепочке создания стоимости и привязаны к потребностям пользователя, а ось X описывает эволюцию компонентов (от зарождения до commodity)
4) Event storming - это крутая техника проведения воркшопов для коллаборативного изучения сложного бизнес домена, про которую я уже рассказывал
5) Modernization strategy selector - модель выбора оптимальной стратегии модернизации для каждой подсистемы, которая позволяет использовать портфельный подход к модернизации, где оптимальный возврат инвестиций может быть определен на гранулированной основе для достижения оптимального общего возврата инвестиций в модернизацию.
- Ну и напоследок автор говорит о том, что для старта надо выбирать область, где модернизация может принести обозримые результаты за ограниченный промежуток времени. В общем, надо уметь срывать низковисящие плоды - это позволяет показать, что модернизация может приносить пользу, а не превратится в очередное бесконечное начинание без конца и без края и без ощутимых результатов:)

#Management #Software #Engineering #SoftwareDevelopment #Processes #ChangeManagement #Strategy #Architecture

A Brief Outlook of Enterprise Architecture Role in the Digital Age (Рубрика #Architecture)

Когда я выбирал научные статьи с research разделов bigtech компаний, то мне казалось, что большая часть whitepaper интересна. Но тут я решил поискать материалы про enterprise architecture в ACM Digital Library и нашел ... Пока ощущение от их чтения грустное. Конкретно в этой статье 2022 года от Ахмеда из Египта (Ahmed S. Elsheikh) сделано все достаточно топорно и как-то механистически, но давайте ниже я расскажу подробности

1) В абстракте автор начинает с того, что с 1980х годов корпоративная архитектура существует как отдельная дисциплина, которая помогала бороться со сложностью
2) Но с 2010х годов появилась отдельная волна цифровых трансформаций (digital transformation), которая привела к волне подрывных инноваций и бизнес и технологические ландшафты изменились навсегда:)
3) Автор решил исследовать как эти две волны связаны межжду собой через исследование статей на тему digital enterprise architecture
4) Для начала автор рассказывает про святую троицу: Enterprise architecture => TOGAF => Archimate, где корпоративная архитектура - это околонаучная дисциплина, TOGAF - это фреймворк, а Archimate - это фреймворк для моделирования архитектуры. Дальше автор рассказывает про application portfolio management strategy, capability architecture и capability-based planning
5) Но возникает вопрос как это все добро применять с цифровизации, цифровой трансформацией и другими историями про трансформаторов и трансформации:)
6) Автор погуглил словосочетание "digital enterprise architecture" в Clavirate "Web of science" и нашел 55 статей
7) Дальше автор взял базовую статистику по году выхода, авторам, количеству цитат и построил графики - походу статья без графиков не очень научна
😍 Из графиков видно, что с 2015 года пошли не разовые публикации, а косяком, где в 2017 году был пик в 10 публикаций, дальше небольшое проседание и в 2021 году был новый рекорд в 14 публикаций. Из этой статы видно, что исследователи корпоративной архитектуры сразу подхватили тренд цифровой трансформации:)
9) Дальше автор разбил эти 55 статей по 3 группам, выделив отсечку по количеству отсылок к публикациям (количество цитат из них)
10) Получилось 3 группы:
- Взаимное влияние корпоративной архитектуры как отдельной дисциплины и цифровой трансформации как отдельной волны подрывных технологий и бизнес потребностей в одно и то же время
- Как корпоративная архитектура как отдельная дисциплина может помочь и поддержать корпорации, что цифровые и глобальные одновременно
- Как корпоративная архитектура как отдельная дисциплина может помочь и поддержать цифровые трансформации в разных контекстах и секторах индустрии
11) Автор кратко буквально в одной строке характеризуют каждую статью из этих групп (очень глубокая проработка материала)
12) Напоследок автор формулирует направления для исследования примерно так
- Связь между глобальными цифровыми корпорациями и конкретные трансформации, например, корпоративная архитектура может отличаться между индустриями
- Не хватает некоторых логичных областей (указанные три категории выше не закрывают все сценарии)
- Как отличаются корпоративные архитектуры, когда в основе цифровых трансформаций разные подрывные технологии (автор делает отсылку к блокчейну и бигдата - чуток подпротухшими сейчас кажутся предложенные автором disruptive technologies)
- Как фреймворки для корпоративной архитектуры и фреймворки для цифровых трансформаций (походу и такая дичь штука есть)

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

P.S.
А я подумал, что лучше бы я прочитал еще одну научную статью от Google:)

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment

Обзор paper "Defining, measuring and managing technical debt" (Рубрика #Architecture)

Я продолжаю читать и писать о статьях из серии developer productivity, о которых рассказывал в обзоре первого whitepaper "A Human-Centered Approach to Developer Productivity". В третьем whitepaper с заголовком "Defining, Measuring, and Technical Debt" речь идет про технический долг и как он влияет на продуктивность разработчиков. Эта тема часто поднимается, но редко когда можно услышать четкое определение термина, а также объяснение как его считать и что с ним делать. Авторы решили закрыть этот пробел и написать как с этим дела в Google. А я решил сделать обзор этой статьи.

#Architecture #Software #Management #Leadership #Engineering

Как формировать структуру команд под запросы бизнеса (Рубрика #Management)

Недавно меня позвали выступить на митапе с этой темой, которую я рассказывал на YaTalks в 2023 году. Это знаковое для меня выступление, так как я делился основами и принципами дизайна команд, которые помогали мне на протяжении 7 лет работы в Тинькофф. Это приглашение показалось мне отличной причиной рассказать сразу и продолжение о том, как за 2023 и 2024 года мы трансформировали мое подразделение в 1000 инженеров в 5 отдельных самостоятельных технических доменов со своими engineering директорами. Но оказалось, что я не сделал краткого саммари прошлого выступления. Поэтому я решил исправиться и написать расшифровку (а видео досупно на youtube).

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

Вот список рекомендаций для дальнейшего изучения
Принципы и подходы
- Backcasting мы обсуждали в серии Code of Architecture про Technology Strategy Patterns
- Про working backwards написана целая книга
- Про проектный и продуктовый подход у меня есть хорошая статья
- Про Kanban рекомендую почитать пару книг: “Визуализируйте работу” (“Making Work Visible”), про которую я рассказывал, а также "Канбан Метод. Базовая практика", про которую я тоже рассказывал
- Про закон Конвея можно почитать в wikipedia
- Обратный маневр Конвея в 2014 году попал в техрадар от ThoughtWorks
- Про team topologies можно почитать мои краткие саммари: Teams as means of Delivery, Team Topologies that work for flow, Evolving team interactions for innovation and rapid delivery
- Про управление изменениями классно написано в книге "Наш айсберг тает", про которую я уже писал
Отдельные выступления про их применение
- В 2019 году на ArchDays я рассказывал про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях
- В 2021 году на Techlead Conf я рассказывал про то "Как мы меняли разработку лучшего* мобильного банка под требования бизнеса"
- В 2022 году на Highload++ Spb я рссказывал доклад "Канал. Продукт. Платформа” или эволюция подходов к развитию мобильного банка Тинькофф"

#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software

Обложки для книг "Continuous API Management, 2nd Edition" и "Непрерывное развитие API"

Continuous API Management, 2nd Edition (Непрерывное развитие API) (Рубрика #Architecture)

Второму изданию этой книге уже порядка 3х лет, а читал я ее последние несколько месяцев и только недавно закончил. Книга мне действительно понравилась и я решил поделиться с читателями канала. В этой книге 12 глав, которые закрывают многие вопросы, связанные с governance, которые обобщаются дальше вопросов управления API

1. The Challenge and Promise of API Management - зачем компании хотят управлять своими API, какие проблемы при этом возникают и какие возможности это дает. Здесь авторы рассказывают в общем об основных вопросах, рассмотренных в книге. Отдельно отмечу важность разделения для API интерфейсов (контракты), имплементации (код) и развертывания (инфра)
2. API Governance - глава с фундаментальными концепциями для управления API и какое это значение имеет для принятия решений
3. The API as a Product - глава про важность восприятия API как продуктов (API as a Product). При этом на API можно смотреть с точки зрения целевой аудитории и принимать решения, которые являются лучшими для них
4. The Pillars of an API Product - основные колонны, на которых основаны API. Авторы выделяют следующие области, которые рассматривают детально: strategy, design, documentation, development, testing, deployment, security, monitoring, discovery, change management
5. Continuous API Improvement - глава про то, как жить с непрерывными изменениями и как ими управлять
6. API Styles - здесь авторы рассказывают об основных стилях, которых они насчитывают 5. Вот они: tunnel style (RPC), resource style (REST), hypermedia style (RESTful), query style (graphql), event-based style
7. The API Product Lifecycle - жизненный цикл одного API, который состоит из этапов: create => publish => realize => maintain => retire ... Авторы подробно разбирают как на каждом этапе требуется прорабатывать конкретные pillars
8. API Teams - какие роли нужны в командах для эффективного развития API как продукта. Причем не просто в вакууме, а в зависимости от зрелости самого API
9. API Landscapes - здесь авторы переходят от единичных API к их множеству, которое можно воспринимать как ландшафт. Авторы рассказывают про API Management at Scale, который опирается на принципы, протоколы и практики. Это очень сильно пересекается с paper "API Governance at Scale" от Google, про которое я рассказывал раньше. Плюс авторы вводят модель 8v, которая позволяет управлять ландшафтом, ориентируясь на разные ракурсы. Вот эти восемь V: variety, vocabulary, volume, velocity, vulnerability, visibility, versioning, volatility
10. API Landscape Journey - рассказ о том, а как внедрять API Governance. Авторы предлагают модель enabling team, которая поможет внедрить и раскатить процессы API Governance на всю организацию
11. Managing the API Lifecycle in an Evolving Landscape - здесь авторы пересекают pillars и 8vs и рассказывают о том, как они связаны между собой
12. Continuing the Journey - последняя глава подводит итог книге и готовит читателей к старту Continuous API Management внутри компании

P.S.
Обложки книг представлены в следующем посте.

#Architecture #Software #Governance #Management #Leadership #Processes #Leadership

Обзор whitepaper "API Governance at Scale" (Рубрика #Architecture)

Я дописал обзор статьи про API Governance от ребят из Google, про которую я уже несколько раз упоминал (1 и 2). В общем, статья получилась интересной и полезной - ее подходы хорошо масштабируются за границы governance именно API, например, мы многое из этого пытаемся применять в процессах architecture governance на уровне компании. В общем, читайте статью, а в следующий понедельник по ней выйдет первая серия подкаста "Research insights made simple", где я буду ее обсуждать со своим коллегой Даниилом Кулешовым.

#Architecture #Management #Governance #SystemDesign #Software #Leadership

Массовое вымирание стартапов: что происходит на глобал tech-рынке и как это влияет на рынок труда (Рубрика #Management)

Интересное интервью Дениса Калышкина, венчурного инвестора из фонда I2BF (инвестируют в американские стартапы) Кире Кузьменко из New HR
Обсуждение было сконцентрировано вокруг тем
— Вымирают ли стартапы или нет?
— Как инвесторы выбирают, куда инвестировать в текущей ситуации?
— Что происходит с внутренними стартапами в крупных компаниях?
— Как оценивать стартап кандидату, который хочет там работать?
— Когда будет дно кризиса и надолго ли текущий кризис с нами?
— Надо ли идти сейчас в предпринимательство вместо найма?

#Startup #Management #Leadership #Invest

Архитектура на старте: подготовка к успеху - Podlodka Techlead Crew (Рубрика #SRE)

Поучаствовал вчера в дискуссии на подлодке насчет проектирования надежных систем. В ней участвовали Олег Бондарь, Филипп Дельгядо и я. Мы поговорили про ключевые принципы для построения надежной архитектуры. Дискуссия была интересной и динамичной. Мы уделили много вопросам observability и я позвал всех участников на конфу T-Observability Day Tech 2024, что пройдет 23 октября в нашем московском офисе T-Space. Кстати, про конфу я уже рассказывал тут в канале

P.S.
Год назад я выступал на конференции с докладом "Проектируем надежные системы — стоит ли игра свеч", про который я уже рассказывал. И тот доклад был основан на солидном списке материалов
- "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, и про тип интервью, в котором мы проверяем на практике работу инженеров в рамках инцидента
- "Публичное интервью по troubleshooting для SRE-инженеров на конференции Devoops" - публичное интервью с разбором инцидента
- Крутой доклад "Паттерны отказоустойчивой архитектуры" ребят из Яндекса про отказоустойчивые системы

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE

Code of Leadership #21 "A Philosophy of Software Design" (Рубрика #Architecture)

Этот выпуск подкаста посвящен рассмотрению крутой книги Джона Остерхута "A Philosophy of Software Design". В разборе книги  помогает Григорий Скобелев, Java/Go techlead, чей основной профиль это highload приложения, также он является директором программного комитета Podlodka Techlead/Java Crew. А в свободное время он делает свой подкаст/книжный клуб - { между скобок }, LinkedIn

В этой серии рассмотрена первая половина книги, где получилось обсудить темы
- Знакомство с гостем
- История создания книги
- Общее содержание книги
- Философия борьбы со сложностью
- Управление техническим долгом
- Подходы к управлению процессом разработки
- Эволюция и технический долг
- Подходы к приоритизации
- Продуктовый подход и оценка импакта
- Виды сложности и метрики кода
- Когнитивная нагрузка и простота кода
- Принципы обучения и решения задач
- Автоматизация и тесты
- Причины когнитивной сложности
- Исследования в Google
- Стратегическое и тактическое программирование
- Примеры из практики
- Проблемы с накоплением технического долга
- Модуляризация и интерфейсы
- Проблемы с интеграцией через базу данных
- Скрытие информации и абстракции
- Проблемы с монолитными системами
- Генерализованные и специализированные модули
- Централизованное хранилище данных
- Уровни абстракции
- Декораторы и фасады
- Эволюция кода и опыт инженеров

Продолжение обзора книги будет в следующей серии

#Architecture #Processes #Management #Leadership #Software #SystemDesign

Operationalize a Scalable AI With LLMOps Principles and Best Practices (Рубрика #ML)

Я уже давно заметил, что модность темы можно отследить по наличию связки somethingOps, вот дошла очередь и до LLMOps, про что рассказывается в недавней статье от DZone. Раньше уже была на хайпе темы
- DevOps - тема уже давно на хайпе (подробнее в книге "Accelerate", про которую я рассказывал), сейчас больше говорят про Platform Engineering
- DevSecOps - горячая тема, подробнее в книге "Agile Application Security", про которую я рассказывал или недавней статье "Secure by Design at Google", который я разбирал отдельно
- DataOps - давняя и актуальная тема про выстроенные процессы работы с данными. Они нужна как пререквизиты для эффективной работы над ML-моделями
- MLOps - это очень актуальная тема, которая включает набор практик, которые объединяют ML, DevOps и инженерию данных, которые направлены на создание, деплой и эксплуатацию ML систем в проде надежно и эффеективно. Интересно, что эту тему мы разбирали в выпуске подкаста "MLOps в теории и на практике"
Подробнее про XOps подходы можно посмотреть в докладе "The Pipeline-Driven Organization", про который я уже рассказывал

В этой же статье речь идет про подмножество MLOps подходов, которые сфокусированы именно на LLM приложениях, которые сейчас являются горячей темой. В приведенной ниже статье сначала приводится определение LLMOps. Дальше разбирается разница между MLOps и LLMOps по критериям на чем основной фокус, как выглядит адаптация моделей, оценка качества моделей, управление моделями, включая версионирование и метаданные, как модели деплоятся и как мониторится их работа. Дальше автор разбирает базовые характеристики LLM
- Что они существуют в разных формах: проприетарные модели с платными API, pre-training models, fine-tuned models
- Что существует так называемый prompt engineering, так как многие LLM принимают в качестве входа текст на естественном языке
- Иногда можно добавлять контекст к запросам пользователей (context-based prompt engineering:), чтобы повысить их эффективность, для чего используются новые инструменты, навроде векторных баз данных (про которые был недавно интересный доклад)
- Они достаточно большие, иногда сотни гигабайт, а также им может требоваться GPU не только для тренировок, но и для обработки real-time запросов
- Оценивать их качество достаточно сложно, поэтому часто надо встроить человеческий фидбек прямо в MLOps процесс для оценки и тестирования моделей

Ключевыми моментами приложений с LLM сейчас являются следующие моменты
- Prompt engineering, про который мы говорили выше
- RAG (retrieval augmented generation), который полагается обычно на уже упоминавшиеся векторные базы для семантического поиска, а также на feature store, где хранятся признаки.
- Fine-tuning LLMs - это процесс адаптации предварительно обученной LLM к сравнительно небольшому набору данных, специфичному для отдельной области или задачи.
- Pre-training a model from scratch - это что-то на богатом про процесс обучения языковой модели на большом массиве данных (например, тексте, коде) без использования каких-либо предварительных знаний или весов из существующей модели:)

Дальше автор показывает референсные архитектуры LLM приложений с RAG от Databrics, а финализирует плюсами и минусами LLMOps

+ Minimal changes to base model - большинство LLM приложений можно запустить поверх базовых моделей с небольшими изменениями
+ Easy to model and deploy - LLMOps как раз упрощает использование моделей
+ Advanced language models - можно начинать использовать сложные модели через API, а потом перейти open source модели
- Human feedback - в случае LLM обратная связь от людей необходима, что добавляет сложностей
- Limitations and quotas - при использовании внешних API надо понимать их ограничения и стоимость использования
- Risky and complex integration - при использовании внешних API надо понимать какими данными вы делитесь и насколько это ок

#AI #ML #Software #Architecture #Future

Носки врозь! (Рубрика #ForKids)

Нашим детям подарили эту книгу-детектив Матюшкиной и Оковитовой про найденный и похищенный клад. Главными героями являются лучшие в мире сыщики кот Кис-Кис и пес Фу-Фу, которые приступают к поиску улик и подозреваемых среди других животных, живущих в лесу. В общем, книга очень забавная - в лесу много животных с яркими особенностями, интрига закручивается серьезная, а на место еще одного ссыщика претендует Кролик:) Отдельно отмечу, что в книге много забавных стихов, которые нравятся детишкам.

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

#ForKids #ForParents

ЦЕХ 4 - Урок #20 "Social media marketing (SMM). Эксперт — Олеся Полянская" (Рубрика #Writing)

Очередной урок из курса книгописания и книгоиздания от МИФ вела Олеся Полянская, руководитель команды по социальным сетям в МИФ, которая поделилась опытом и знаниями в области SMM. Мне запомнились следующие тезисы из этой лекции:

1. Соцсети могут помочь в публикации книг и повышении узнаваемости автора и его книг
2. Их можно использовать для коммуникаций с аудиторией, получения обратной связи и монетизации
3. Сейчас уже существует множество блогов и каналов, но уникальность голоса и опыта автора всегда найдет свою аудиторию
4. Для ведения своего блога нужна понятная стратегия и планомерная работа
5. Важно понимать, зачем вы будете вести блог, чтобы не забросить дело на полпути. Цель должна быть вдохновляющей и значимой, а не просто меркантильной.
6. Важно правильно выбирать платформу для публикаций: разные соцсети, мессенджеры и так далее
7. Важно формулировать ключевые идеи и формировать свой стиль, через который виден личный опыт и уникальность
8. Можно делать тематические подборки и инструкции - они работают хорошо
9. Можно использовать бесплатное и платное продвижение для своих блогов, а можно давать рекламу в своем блоге
10. Важно понимать свою аудиторию и правильно формировать контент под своих читателей
11. Можно делегировать работу по развитию своего блога, оставив на себе только создание контента
12. Нужен контентный план публикаций и их ритмичность - иначе аудитория будет отваливаться, особенно, если автор будет пропадать надолго
13. Создание публикаций требует большого количества времени - это надо понимать, решая завести свой блог
14. Надо быть готовым к токсичным комментариям
15. Переводить аудиторию между разными соцсетями достаточно сложно, поэтому стоит диверсифицировать используемые платформы

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

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Беслатный онлайн-курс по математике для школьников 4-6 классов от Т-Образования (Рубрика #Math)

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

P.S.
Я сам учился в ЗФТШ (заочной физико-технической школе при МФТИ), но это было уже в 10 и 11 классе и помогло мне в свое время поступить на Физтех. Но эта штука не очень масштабировалась, а наше обучение в рамках Тинькофф Поколения сможет охватить больше направлений и помочь большему количеству школьников получить актуальные и полезные знания и навыки. В общем, я считаю, что наши программы обучения - это топчик:)

#Math #Courses #SelfDevelopment #ForKids #Science