Leetcode - прогресс за второй месяц

Раньше я уже рассказывал про свой опыт с Leetcode, но теперь прошел еще один месяц и я оценил качество курса "Data Structures and Algorithms", который я пока прошел на 40%:) Этот курс действительно помогает вспомнить стандартные приемы и вернуть их на уровень легкого и осознанного применения. В итоге, мне стало казаться, что ежедневные задачки на leetcode стали проще, на что мой коллега, другой технический директор, предположил, что я просто научился лучше писать код:) А если говорить без шутко, то я каждый день утром или вечером хотя бы полчасика-часик уделял на leetcode и пропустил только один день на неделе, когда провалялся с давлением. И эта ритмичность помогала не соскочить и отложить тренировку на завтра:)

P.S.
Судя по картинке, можно увидеть, что темп чуток упал. Мне кажется, что это из-за того, что в феврале не было таких больших каникул как в январе, плюс я не решал запоем задачки по sql:)

#SelfDevelopment #Algorithm #Software #SoftwareDevelopment

Спортивное программирование (Competitive programming 3)

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

#SelfDevelopment #Algorithm #Software #SoftwareDevelopment

Code of Leadership #7 Your brain at Work

Седьмой выпуск Code of Leadership посвящен тому, как мы принимаем решения и как работает наш мозг. В этом выпуске в гости пришел Эрнесто Инаркиев - чемпион Европы по шахматам, гроссмейстер, который входит в ТОП-100 лучших шахматистов мира и в ТОП-30 по быстрым шахматам. Эрнесто создал курс "Эффективное мышление", который я проходил в прошлом году и который мне понравился

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

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

#Brain #SelfDevelopment #Thinking #Management #Leadership

Layers of Leadership • Lee Campbell • YOW! 2023

Интересное выступление от Lee Campbell, VP of Engineering at VGW, которое состоит из следующих частей
— Leadership challenges - рассказ про вызовы, что стоят перед лидерами: people, delivery, operations. Для лидера при работе с людьми важно работать на competency (build it right, run it right), performance (right thing, right time) и alignment (right people, right place). Дальше он переходит к
— Start-up challenges - тут автор говорит про формирование команды и погружается в вызовы стартапов. Автор предлагает метафору direction - map - path, которые позволяют стартапу и его команде двигаться в условиях неопределенности. Автор говорит про троицу
—— Competency (what) -> reference example
—— Performance (how) -> performance expectations
—— Alignment (why) -> outcome focused
— Teamwork challenges - здесь автор говорит про вопросы людей вида "кто и что сделает и когда?", "Как я могу вырасти в компании" и на уровне системы: "Что должна делать эта система?", "Плох ли технический долг?". Для ответов на эти вопросы автор предлагает использовать maps and measures
—— Competency (what) - competency matrix для сотрудников
—— Performance (how) - maturity models для систем и команд
—— Alignment (why) - measurable outcomes для измерения результатов команд
— Org. challenges - тут речь про следующие вызовы:
—— Большие проекты никогда не приоритизируются и будут выполнены примерно никогда
—— KPI, OKR - когда решение становится outcome, про разделение между работой и целями и метрики, на которые напрямую не повлиять
Для решения этих проблем автор предлагает использовать
—— Driver trees - деревья, которые позволяют выстроить связь от "Что" до "Как" через набор драйверов, на которые мы можем повлиять
—— Paths & practices - автор говорит про обучение, а также про работу над performance себя и своих команд и приводит пример с работой над улучшением работы в рамках инцидентов
—— Coordinated strategy - приведено на снимке

#Leadership #Management #Culture #Software

Why Most Data Projects Fail & How to Avoid It • Jesse Anderson • GOTO 2023

Интересное выступление про data проекты от Jesse Anderson, автора книги "Data Teams". Автор говорит о ключевых вопросах, которые стоит задать при старте проектов
- Who - Автор говорит про правильный состав команды для data проектов. Собственно автор про это написал целую книгу и он говорит про баланс data scientists, data engineers, operations.
- What - Автор задает вопрос про бизнес значение того data продукта/проекта, которым вы занимаетесь. Автор говорит о том, что фразы "Мы делаем AI" от CEO не хватает для data strategy:) В общем, надо понимать как ваш проект принесет ценность для бизнеса. Причем помимо стратегии нужен план и его execution. Особенно во времена, когда tech компании занимаются сокращениями в направлениях, что не приносят деньги.
- When - Автор говорит о том, а когда эта бизнес ценность будет создана. Нужен проект с понятными временными границами, чтобы он не был слишокм долгим, чтобы быть отмененным где-то посердине и не слишком коротким, обещающим золотые горы, которым на самом деле будет невозможно соответствовать.
- Where - И вот мы наконец-то добрались до первого технического вопроса, а где собственно эти данные будут обрабатываться, как будет выглядеть архитектура решения. И тут для ответа тоже не хватает фразу "Мы будем использовать технологию XYZ вендора ABC". Проблема в том, что вендор может пообещать все что угодно, но это обещание не факт, что выполнимо, более того, не факт, что оно оптимально для заказчика:)
- How - Здесь речь идет про план выполнения и про фокусировку на приоритетных направлениях. Хотя часто такие data проекты пытаются успеть сразу везде, а дальше теряют эффективность на context switches и застывают на месте, переставая генерировать какую-либо ценность кроме рассказов о наступлении AI:) Автор интересно рассказывает про то, как бизнес заказчикам перпендикулярно на конкретные технические решения, но важно какую бизнес-ценность они могут получить по результатам выполнения плана.
- Why - Автор задает вопрос, а почему же эти данные обладают ценностью? Просто отгружать данные и гонять ETL/ELT пайпланы не достаточно. Важно понимать как использование данных в новых проектах позволит обеспечить нужный ROI (return on investments), причем автор говорит о том, что он ищет 10x ROI для data проектов

Напоследок автор говорит о том, что для AI и data проектов важно понимать, что такие проекты сложны и требуют навыков, людей и организационных изменений для своего успеха. И это достаточно сложно и не все способны приносить пользу в таких проектах. Конкретно, автор рассказывает про то, что если запускать data и AI проекты внутри DWH команд, то такие проекты обречены на неудачу ("the team where good data projects go to die). Это обусловлено не тем, что DWH технологии плохие, а потому, что это скорее проблема людей ("people problem"), которые очень специфично разбираются с проблемами и очень специфичным образом выстраивают свою работу. В общем, автор говорит о том, что эта не та команда, которая должна отвечать за data и AI проекты нового типа.

P.S.
Такое же выступление было на YOW 2022 и я про него рассказывал раньше. Выступление получилось хорошим и автор заново его рассказал уже на goto конференции в 2023 году:)
P.P.S.
Мне мысли автора нравятся и я запланировал прочитать его книгу еще год назад, но до сих пор не прочитал:)

#Management #Leadership #Data #DataScience #AI #Engineering #Software #SoftwareDevelopment #ML

Книги от ДМК Пресс на тему экспериментов и статистики

На следующей неделе выйдет серия "Code of Leadership" с Андреем Цыбиным, техническим директором нашей продуктовой аналитики и a/b платформы, которую мы в этом году должны масштабировать на всю компанию. В интервью мы обсуждали вопросы продуктовой аналитики, а про a/b решили поговорить в следующий раз. Но сама тема для меня ключевая - 7.5 лет назад, когда я приходил в Тинькофф, то a/b платформа для привлечения уже входила в мой контур ответственности. Дальше она много лет эволюционировала, но всегда была ограничена вебом и мобилкой. А теперь мы с Андреем сделаем ее всеобъемлющей:) И так как мне эта тема глубоко интересна, то у меня уже была целая пачка книг на эту тему, а буквально вчера мне доехала еще коробка новых книг:)

#AB #Experiments #Statistics #Engineering #Math

How to Take Great Engineers & Make Them Great Technical Leaders • Courtney Hemphill • GOTO 2017

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

1) Communication (general management 101)
Здесь автор говорит про правильный подход к написанию документов от Барбары Минто "pyramid principle", где начинать нужно с ответа на главный вопрос, дальше приводить поддерживающие аргументы, а дальше приводить факты и данные. Та же Барбара придумала подход SCQA к сторителлингу: situation, complication, question, answer. А дальше автор переходит к целеполаганию и рассказывает про OKR (objectives and key results) от Энди Гроува.
2) Culture
Здесь автор вспоминает про Проект Аристотель от ребят из Google (я рассказывал про это), где авторы выяснили, что основной фактор эффективных команд в Google - psychological safety. Еще можно почитать про генеративную культуру Веструма (я рассказывал про это). Также автор отмечает важность менторства как внутри компании, так и с людьми извне. А заканчивается pairing:)
3) Authenticity (be a human)
Здесь автор рассказывает про радикальную прямоту (radical candor), а также про использование ретроспектив.
4) Paths (dual track leadership)
Тут автор говорит про два трека развития: engineering management и individual contributors. Про возможность расти не только как менеджер, но и как инженер. Мы про это общались с моим коллегом, Лешей Тарасовым, в шестом выпуске Code of Leadership про Staff+ инженеров.

P.S.
Автор приводит интересные метафоры между engineering частью и менеджерской частью.
1. Open Source -> Writing
2. Continuous Integration -> OKRs
3. Test Driven Development -> Psychological Safety
4. Pair Programming -> Mentorship
5. Code Reviews -> Radical Candor
6. Regular Refactoring -> Retrospectives

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

Практическое руководство по статистическому управлению процессами

Эту книгу Юрия Адлера и Владимира Шпера я читал несколько недель. И дело не в том, что книга скучна, а скорее в том, что она сложна для восприятия и требует понимания статистики и системного мышления. Авторы пропагандируют использование контрольных карт Шухарта, которые в свое время популяризировал сам Шухарт и его коллега Деминг, который приложил руку к японскому экономическому чуду. Все это укладывается в цикл PDCA Шухарта-Деминга (plan - do - check - act). Сама книга состоит из восьми глав

1. Что такое системное, статистическое и визуальное мышление и для чего оно нужно?
2. История возникновения статистического мышления. Основы теории вариабельности.
3. Основы теории вариабельности (продолжение). Анализ стабильности процессов. Игра "Красные бусы"
4. Правила построения и интерпретации ККШ (контрольных карт Шухарта). Классификация типов ККШ
5. Построение и анализ гистограмм. Диаграммы ствол-и-листья (stem-and-leaf) и ящик-с-усами (box-and-whisker). Вероятностные сетки и законы распределения
6. Индексы воспроизводимости процессов (ИВП)
7. Проблемы и трудности при построении и применении ККШ и гистограмм на практике. Алгоритм процесса анализа стабильности и воспроизводимости
8. SPC, AI, Big Data и новые идеи в области ККШ

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

Это философия обучения и действий, основанная на следующих фундаментальных принципах:
- любая работа осуществляется в системе взаимосвязанных процессов
- во всех процессах есть вариации
- понимание и снижение вариаций - ключ к успеху

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

1. Как выбрать показатели, требующие изменения?
2. Сколько таких показателей надо измерять?
3. Каким методом следует измерять каждый выбранный показатель?
4. Как часто надо измерять каждый показатель?
5. С какой точностью надо измерять каждый показатель?
6. Кто должен анализировать каждый показатель?

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

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

#Management #Process #Statistics #Math #Metrics #Leadership

Is Software Engineering Real Engineering? • Hillel Wayne • GOTO 2023

Это выступление Hillel Wayne пытается ответить на философский вопрос: software engineer - это тварь дрожащая или право имеет называться инженером:) Этот вопрос появился из цитат ученых по computer science навроде цитаты Gerald Weinberg

If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.

Ну и в тему этой цитаты автор вспоминает историю с leftpad.

Для поиска ответа автор пошел через опросы настоящих инженеров, которые одновременно работали в области software engineering, а дальше устроил им интервью с тремя вопросами

I. Are we really engineers?
II. How similar are we to engineers?
III. What can we learn from each other?

1) Первый вопрос потянул за собой выяснение термина "engineering", на который было три варианта ответа: physical, consequential, licensed. Дальше автор разбирает каждый пункт и приводит примеры, отвергая все гипотезы. В итоге, остается самое простое, что engineering - это то, что делают инженеры ("what engineers do"). Забавная рекурсия:) Тут еще автор проходится по подходу "Software craftmanship", в котором авторы пытались отстроится от традиционных инженерных дисциплин (без понимания того, как они работают).

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

3) Ну и последний вопрос, а чему мы можем научиться друг у друга
Здесь автор отмечает два момента:
- Up-front planning time
- Responsibility
Забавно, что с этим сталкиваются все, кто проектируют API и контракты, систему плагинов или любой as-a-Service продукт.

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

#Management #Leadership #Engineering #Software #Philosophy