Keynote: Debug your thinking - Laila Bougria - NDC London 2024

Интересный доклад, посвященный улучшению мышления от Laila Bougria, где она рассказывает о том, чему она научилась и как важно критическое мышление и и ментальный отладчик для решения проблем и принятия решений. Вообще, основная метафора доклада - это debugging мышления примерно тем же способом, как мы действуем в случае с софтом, в котором есть непредсказуемые ошибки. Автор дает следующие советы
- Важно анализировать проблемы, сделав паузу и подумав о доступных альтернатив. Можно использовать технику 5 почему (5 whys)
- Полезно использовать технику рефрейминга, когда мы переосмысливаем проблему и находим альтернативное решение, которое отсутствовало в списке альтернатив
- Надо знать о том, что при решении проблем есть склонность к быстрому их решению и использованию старых подходов, которые раньше сработали. Условно натягиваем сову на глобус, старое решение на новую проблему вместо того, чтобы подумать от проблемы. В эту же тему фраза про "Когда в руках молоток, то все проблемы становятся похожи на гвозди"
- Важно научиться нестандартно мыслить - можно посмотреть на детишек, которые переодически выдают очень интересные мысли:)
- Для простора мышления надо быть уверенным в безопасности, это та же тема про pshychological safety, что ребята в Google нашли самой важной для эффективности команд в своем проекте Аристотель, про который я уже писал. Здесь же есть поинт про инклюзивность, который расширяет пространство рассматриваемых альтернатив
- Важно знать про когнитивные искажения (biases), которые влияют на наше мышление и по возможности устранять их влияние
- Для повышения эффективности мышления важно быть осознанным и наблюдать за своими мыслями и предубеждениями, что помогает выявлять и исправлять ошибки.
- Важно уметь работать с обратной связью и использовать RFC для получения обратной связи от разных людей. Также важно записывать свои мысли и решения для улучшения коммуникации и повышения ясности (аля ADR, architecture decision records)
- На рынке труда востребованы креативность, умение решать сложные проблемы и критическое мышление, поэтому стоит прокачивать эти качества в себе

P.S.
Раньше я уже публиковал подборку книг
1) На тему системного и критического мышления
2) На тему работы мозга

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

#Thinking #CriticalThinking #Reasoning #Philosophy #SelfDevelopment #Brain #Management #Leadership

Доверительное a/b тестирование (Trustworthy Online Controlled Experiments)

Уже после начала отпуска я дочитал книгу по a/b экспериментам, которые являются необходимым инструментом для bigtech компаний для того, чтобы оценить эффективность тех или иных идей по оптимизации веб-сайтов, приложений, ml-моделей.

Это дейстительно крутая книга, которую написали совместно три автора:
- Ron Kohavi - Technical Fellow and corporate VP of Microsoft's Analysis and Experimentation (previously director of data mining and personalization at Amazon)
- Diane Tang - Google Fellow, with expertise in large-scale data analysis and infrastructure, online controlled experiments, and ads systems
- Ya Xu - head of Data Science and Experimentation at LinkedIn

Эта книга на русском вышла в издательстве ДМК Пресс и ее даже можно читать, сверяясь периодически с первоисточником.
Книга состоит пяти частей:
1) Введение для всех - объяснение мотивации проведения экспериментов, как выглядит полный цикл проведения экспериментов, как оценить надежность полученных данных и как прокачать культуру экспериментирования и прийти к платформе
2) Избранные темы для всех - пример известных экспериментов по оценке влияния скорости вебсайтов на бизнес показатели (full дизайн эксперимента и разбор его результатов), какие организационные показатели бывают, как выбрать OEC (overall evaluation criteria) для оценки эффектов экспериментов, как проведенные эксперименты формируют институциональную память и как их можно использовать для метаанализа, как проводить этичные эксперименты
3) Дополнительные и альтернативные методы контролируемых экспериментов - что делать, если честный a/b тест не провести (экспертная оценка, исследование UX, фокус-группы, обзоры, ...), как дизайнить наблюдательные исследования для исследования причинно-следственных связей
4) Платформы для экспериментов - очень важный раздел для тех, кто решил делать свою платформу. Здесь идет речь про эксперименты на стороне клиента (например, в мобильном приложении), про инструментарий для экспериментов, как выбрать еденицу рандомизации (страница/экран, сеанс пользователя, пользователь, компания, ...), как найти компромисс между скоростью/качеством/риском при дальнейшем развитии экспериментальной платформы, как анализировать масштабные эксперименты
5) Развернутое описание анализа экспериментов - тут наступает время статистики и авторы рассказывают про t-тест, p-значение и доверительные интервалы, ошибки первого и второго родов. Рекомендую почитать книгу "Understanding Statistics and Experimental Design. How to Not Lie With Statistics", про которую я писал раньше. Тут же идет речь про оценку дисперсии и повышение чувствительности экспериментов, как и зачем проводить a/a тестирование, какие существуют ограничительные показатели при проведении экспериментов, навроде SRM (sample ratio mismatch), как может происходить утечка и интерференция между вариантами (например, при экспериментах в соцсетях или на e-com платформах), как мерить долгосрочные эффекты.

В общем, книга топовая и я рекомендую ее к прочтению тем, кто глубоко погружен в тему a/b экспериментов ... или тем, кому просто нравится статистика:)

#Math #Statistics #PopularScience #Science #ML #Data #Software #PlatformEngineering

ЦЕХ 4 - Урок #4 "Как организовать работу. Эксперт — Ренат Шагабутдинов"

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

0) Есть много авторов книг на тему писательского мастерства и можно почитать их, чтобы вдохновиться идеями
1) Важно помнить, что все мы разные и советы авторов не всегда применимы именно к нам
2) Писать надо о том, что нам интересно и нравится - это чувствуется по книге
3) Надо уметь работать с помехами и сопротивлением. Первое - это другие дела, что отнимают время от писательства, а второе - это когда высвободили время под наипсание, но книга не пишется.
4) Важно в своей работе опираться на принципы,а не инструменты. Например, среди принципов может быть однозначность, работа над книгой в самое продуктивное время (что для каждого из нас свое), отказ от уведомлений.
5) При работе важен темп и ритмичность. Это можно обобщить на расписание внутри дня, недели, месяца. Классно, когда внутри дня у нас есть слоты, когда мы можем поработать над книгой.
6) Системность в работе важна - важно фокусироваться не на большой цели, а на ежедневной системной работе. Причем можно так спроектировать окружение для работы, чтобы не отвлекаться на лишнее и не тратить усилия на самоконтроль. Про это есть в книге "Теория игр", про которую я вспоминал раньше
7) Важно вести здоровый образ жизни - достаточно спать, есть, двигаться. Именно это позволяет достичь оптимальной физической продуктивности, а в здоровом теле - здоровый дух:)
😍 Если вы уперлись в писательский блок, то можно продолжать писать и не оценивать себя в процессе работы. Можно переключиться на другое дело и немного погулять, отпустив свои мысли в свободное плавание, ну и есть еще куча советов
9) При старте написания можно использовать разгонные блоки для того, чтобы расписаться. Плюс, некоторым помогает проговаривание текста вслух.
10) Можно использовать отпуск для работы над книгой, но помогает он редко, так как отпускные дела забирают все время:)
11) Структура книги бывает полезна в самом начале книги, но по мере написания она обычно претерпевает много изменений:)
12) Структуры книги бывают разные: от общего к частному, от частного к общему, хронологические и так далее
13) Композиция книги тоже может быть разной: линейной, параллельной, полифонической, кольцевой
14) Большинство авторов используют Word или Google Docs, но есть и более продвинутые приложения. Бывает полезно использовать аля Miro для mind maps
15) Объем книги в России считают в авторских листах, объем книги обычно бывает в пределах от 4 до 40 авторских листов. Объем книги должен быть обусловлен ее содержанием, плюс полезно смотреть на объем по частям и главам и контролировать, что они примерно равны
16) Сроки написания книги всегда больше, чем вы планировали (здесь работает закон Хофштадтера)
17) Важно делать бекапы в разных местах, чтобы не потерять внезапно черновик рукописи
18) Можно использовать LLMs для генерации чернового материала
19) Полезно иметь систему для работы с заметками, например, как описана в книге "How to take smart notes, Zettelkasten", про которую я уже вспоминал
20) Бывает полезно использовать бета-ридеров, которым доступен для прочтения черновик книги и которые дают полезную обратную связь

#Writing #SelfDevelopment #Management

Как я получаю информацию, чтобы быть в теме IT и не только

Недавно ко мне прилетел примерно такой вопрос от моего коллеги, Вовы Коноплева, CTO нашего банка для юрлиц, который ведет свой канал @konoplevthoughts
Мне вопрос понравился и я решил ответ на него превратить в отдельный пост, где я расскажу про свои источники информации

1) Книги
Я отслеживаю важные книги по интересным мне темам. Для этого я ориентируюсь на новинки на платформе
- Сайт онлайн-платформы O’Reilly, где есть книги разных издательств, а также видео и курсы
- Сайт издательства Питер, где интересно отслеживать новинки, а потом читать их неисковерканные в английском варианте
- Сайт издательства ДМК Пресс, где интересно отслеживать новинки и их даже можно покупать и читать (например, тут я писал про последнюю купленную партию книг из ДМК насчет статистики)
- Сайт издательства МИФ, где я покупаю много книг, но редко какие из них посвящены IT, так как это не профильная тема для МИФ
Отдельно отмечу, что меня интересуют книги как по IT, так и по современной науке, но обычно в формате научно-попуплярной литературы. Это позволяет мне поддерживать знания в актуальном состоянии.

2) Whitepapers
Я люблю читать важные whitepapers на темы, что меня задевают: архитектура , менеджмент, распределенные системы. Для этого у меня есть тоже набор источников
- Сайт ACM (Association for Computing Machinery) - сайт ассоциация вычислительной техники, старейшей и наиболее крупной международной организации в компьютерной области. На этом сайте есть куча whitepapers. Отдельно отмечу, что вступление в ряды членов ACM позволяет здорово сэкономить на доступах: само членство стоит 99$, за 75$ можно получить доступ к уже упоминавшейся выше платформе O'Reilly, Skillsoft Percipio и Pluralsight, а еще за 99$ к ACM Digital Library. В итоге, 273$ в год дают бандл, что стоит дешевле в 2 раза, чем доступ к O'Reilly отдельно
- Сайт Google Research, где есть куча интересных whitepapers, например, я уже публиковал такую подборку
- Сайт Amazon Science, где тоже много отличных материалов, например, "Dynamo: Amazon’s highly available key-value store" 2007 года, "Amazon Redshift and the case for simpler data warehouses" 2015 года, "Amazon Aurora: Design considerations for high throughput cloud-native relational databases" 2017 года, "Amazon DynamoDB: A scalable, predictably performant, and fully managed NoSQL database service" 2022 года
- Сайт Meta Research (запрещенной в России Meta), где тоже куча интересного материала

3) Telegram каналы
Приведу тут не весь список каналов, а тот, из которого я частенько узнаю что-то новое
- Сиолошная (@seeallochnaya) - здесь я читаю понятные тексты про LLMs и все, что с ними связано. По этим текстам мне кажется, что я неплохо все понимаю
- gonzo-обзоры ML статей (@gonzo_ML) - здесь я узнаю про whitepapers и понимаю, что пока не слишком хорошо во всем этом разбираюсь:)
- Инжиниринг Данных (@rockyourdata) - здесь я узнаю про современный ландшафт технологий работы с данными, но с фокусом на западных SaaS решениях и примесью on-prem решений
- Архитектура ИТ-решений (@it_arch) - отсюда я узнаю про интересные статьи на тему архитектуры и проектирования
- DDDevotion (@dddevotion) - тут я черпаю новости относительно DDD и той же архитектуры и проектирования

4) Популярные ресурсы на тему IT
- Сайт консультантов Thought Works и конкретно их выпуски про техрадары
- Сайт InfoQ и их ежемесячные рассылки по архитектуре

5) Каналы в Youtube
- Канал конференции goto, где есть записи с конференций крутых спикеров, многие из которых являются популярными авторами
- Канал конференции NDC, где тоже есть крутые выступления

6) Обучающие платформы
- Leetcode, где можно практиковать написание кода
- Edx - ресурс с крутыми университетскими курсами (я его использовал активно раньше)
- Coursera - ресурс с крутыми университетскими курсами (я его использовал активно раньше)
- Stepik - российский ресурс с хорошими курсами

#SelfDevelopment #Education #Software #Architecture #Management #Leadership

GitHub Copilot: Coding Will Never Be The Same Again • Ryan J. Salva • YOW! 2023

Интересное выступление от Ryan J. Salva, VP of Product в Github, который рассказывает о том, как работает Copilot, и сопровождает все это несколькими демо. Ну и основным лейтмотивом выступления является обсуждение того, как Copilot помогает инженерам повышать свою продуктивность и изменять свой способ работы с кодом. Основные мысли в выступлении следующие
- Copilot умеет делать подсказки кода, который возможно вам будет полезен, исходя из контекста
- Контест обычно задается тем промптом, который вы пишите вначале в виде комментария на естественном языке
- Кроме того, у пользователя есть возможность общаться с помощником в чате, задавая вопросы по кодовой базе или прося сгенерировать какой-то кусок кода
- Архитектура системы на пальцах состоит из трех частей: code editor <-> proxy <-> model
- Контекст обирается со всего редактора (автор показывает на примере VS Code). В дело идут другие открытые вкладки, что тоже используются для контекста
- Для разных целей используются разные модели - условно для подсказок нужно low latency, поэтому используется модель попроще и побыстрее (GPT-3.5), а для чата приемлемо некоторое время ожидания, поэтому можно использовать модель помощнее и помедленнее (GPT-4)
- В принципе, в чате можно попросить Copilot сгенерировать ответ, используя данные всего вашего проекта (workspace)
- Дальше есть возможность использовать RAG (retrieval augmented generation), когда к вопросам пользователя «подмешивается» дополнительная информацию из каких‑то внешних источников для расширения возможностей copilot
-- Пример с документацией по внутренней дизайн системе для создания интерфейсов
-- Пример с информацией из observability платформ (splunk, datadog, ...) для связки условного сбоя, изменений за последнее время и имен авторов (чтобы подключить их к разбору инцидента)
- Дальше автор рассказывает про fine tunning модели, например для внесения смещения в сторону определенных стилей, версий API или SDK, языков программирования. Тут автор говорит, что модель дообучается на той обратной связи, что ей доступна (принятые и отклоненные suggestions, код, что прошел код ревью на merge request и код, что в результате код ревью был исключен и так далее)
- Ребята в Github проводили много экспериментов по исследованию влияния использования LLMs и результаты показывали значимые эффекты. Особенно мне понравилось исследование, где качество MRs оценивали инженеры вслепую, когда не знали использовали ли авторы MRs при работе LLMs или нет. И эта слепая оценка показала значимо более высокие оценки качества MRs у тех, кто пользовался помощью LLMs
- Интересно, что LLMs больше бустят начинающих разработчиков, а у продолжающих эффект меньше
- Дальше автор рассказывает про экономический эффект, что они посчитали в результате исследования с командой McKinsey и там получилось число 1.5 триллиона долларов за следующие три года (вообще консультанты любят рисовать большие цифры)
- Ну и завершается все тем, что ИИ не отнимет работу и инженеров, а скорее избавит их от рутины и в будущем для инженеров будет важна креативность и системное мышление, что позволит решать более сложные задачи, а вот зубрить синтаксиса языка придется меньше:)

#AI #Software #Leadership #Future #ML #DataScience #Productivity #Engineering #Processes

Measuring Engineering Productivity (from Software Engineering at Google) - Part I

Пока у меня отпуск я знакомлюсь с крутой книгой от инженеров из Google, где они преоткрывают завесу тайны над своими инженерной культурой, процессами и практиками. Книга мне нравится и я решил поделиться актуальной главой про то, как в Google подходят к измерению инженерной продуктивности и вот основные мысли из этой главы
- Google - это data-driven компания, где решения принято строить на основе объективной информации, а не субъективных мнений
- При росте бизнеса растет и инженрная команда, но если организация растет условно линейно, то затраты на коммуникацию растут квадратично (можно вспомнить количество ребер в полном графе - n * (n-1) / 2). Поэтому мы не можем просто масштабировать организацию линейно - надо уметь делать каждого инженера более продуктивным
- Для повышения продуктивности надо уметь находить неэффективности в инженерных процессах и фиксить найденные проблемы. Для этого в Google собрали отдельную команду исследователей, изучающих инженерную продуктивность. В этой команде есть как инженеры, так и social scientists из множества областей, включая когнитивную психологию и поведенческую экономику. Эти ученые изучают человеческую сторону инженерных процессов
- Эта команда очень щепитильна к темам своих исследований - померить можно конечно многое, но сначала надо ответить на вопрос, а стоит ли вообще это измерять. И у них есть особый процесс для триажа (triage), где они задают вопросы командам, которые пришли к ним с запросом на исследование
-- What result are you expecting, and why? - этот вопрос позволяет понять изначальные предубеждения и учесть их при оценке эксперимента
-- If the data supports your expected result, what action will be taken? - есть смысл измерять что-то, если этот приведет к каким-то решениям и действиям
-- If we get a negative result, will appropriate action be taken? - если негативный результат исследования не повлияет на решение, то проводить исследования тоже не стоит
-- Who is going to decide to take action on the result, and when would they do it? - надо понимать кто ЛПР (лицо принимающее решение) и имеет ли он отношение к заказу исследования. Надо понимать какие подходы к исследованию этот ЛПР считает валидными - ему нужны количественные данные, качественные (в виде интервью), он верит результатам опросов или доверяет только данным из логов систем (activity based stats). В общем, это совет из серии того, что надо знать свою аудиторию и ее потребности:)
Если вовремя задать эти вопросы, то многие измерения просто не стоят того, например, авторы приводят такие примеры

- You can't afford to change the process/tools right now
- Any results will soon be invalidated by other factors
- The results will be used only as vanity metrics to support something you were going to do anyway
- The only metrics available are not precise enough to measure the problem and can be confirmed by other factors

- Дальше авторы рассказывают про свой подход GSM (goals - signals - metrics) для
-- Goal - это ожидаемый конечный результат, он формулируется в высокоуровневых терминах и не содержит отсылок к тому, как его измерять
-- Signal - это то, как вы поймете, что результат достигнут. Его бы вы хотели измерить, но не всегда это просто
-- Metric - это прокси для сигнала. Это то, что мы реально можем померить, может быть это не идеальное измерение сигнала, но достаточно близкое

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

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

Measuring Engineering Productivity (from Software Engineering at Google) - Part II

Продолжая первый пост, расскажу про исследование readability процесса, в котором авторы сформулировали цель относительно developer productivity, разложив ее на пять отдельных компонент со звучным акронимом QUANTS:
- Quality of the code - качество создаваемого кода, тест-кейсов, архитектуры, ...
- Attention from engineers - как часто инженеры достигают состояния потока, насколько у них много переключений контекста.
- Intellectual complexity - насколько большая когнитивная нагрузка возникает при выполнении задачи. Какой баланс между присущей и привнесенной сложностью (условно есть внутренняя сложность проблемы, а есть дополнительная, которая внесена нашими процессами, инструментами, ...)
- Tempo and velocity - скорость решения задач, пропускная способность (количество задач в единицу времени), темп поставки изменений
- Satisfaction - насколько инженеры довольны своими инструментами, насколько они удовлетворены своей работой и создаваемыми продуктами, насколько они ощущают выгорание

Дальше авторы исследования про readability разложили свои цели по этим 5 критериям:
- Quality of the code - инженеры пишут более качественный код в результате процесса readability review
- Attention from engineers - по этому пункту авторы не выставляли никакой цели
- Intellectual complexity - инженеры изучают кодовую базу Google и лучшие практики в результате процесса, а также получают менторинг от опытных сотрудников
- Tempo and velocity - инженеры выполняют рабочие задачи быстрее и более эффективно в результате процесса
- Satisfaction - инженеры видят пользу readability процесса и испытывают позитивные ощущения от участия в нем

Дальше авторы зафиксировали ожидаемые сигналы и метрики и провели исследование. Интересно, что почти все темы были покрыты метриками из опросов (квартальный опрос и отдельный readability опрос) и только часть про tempo/velocity отчасти опираются на метрики из логов: по медианному времени ревью Changelist (аля MR).

В общем, результаты исследования показали, что readability процесс приносит пользу даже в самых инструментализированных языках (C++, Java). Поэтому сам процесс остался на месте (по крайнейм мере на момент написания книги в 2020 году).

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

How To Be A Great Programmer • Dave Farley • GOTO 2023

Это короткое видео Дэйва Фарли посвящено тому, как быть крутым разработчиком. Интересно, что сам Дейв - тертый калач, который в давние времена написал книгу Continuous Delivery (я про нее рассказывал), а недавно - "Modern Software Engineering: Doing What Works to Build Better Software Faster", которая стоит у меня на полке и ждет своего часа. В этом видео Дейв выделил шесть вещей, которые он считает важными для крутых инженеров
- Code as communication - тут Дейв говорит о том, что код - это средство для коммуникации людей между собой, а не просто для общения с компьютером. Удобочитаемость кода важная для экономии времени и денег, если мы не пишем одноразовый скрипт. Так совокупная стоимость владения на протяжении работы с кодом меньше, так как большую часть времени мы читаем и дорабатываем код, а не раз и навсегда высекаем его в камне:) Интересно, что у Google есть отдельный процесс насчет поддержания readability в их огромной кодовой базе, про который я рассказывал в прошлом посте "Measuring Engineering Productivity". У ребят из Google как раз был вопрос насколько этот процесс окупается и стоит ли его отменить в силу появления линтеров и статических анализаторов. В итоге, ребята поняли, что он приносит пользу и решили его оставить
- Be coutious of framework - здесь Дейв говорит о пользе фреймворков, которая сопряжена с риском. Фишка в том, что фреймворки определяют структуру вашего кода (через концепцию inversion of control) и это влияет на развитие и поддержание проекта. Дейв предлагает прибегать к изоляции стороннего кода за собственной абстракцией. В терминальной стадии риск подсаживания на фреймворки выглядит как разработчик на Spring Boot или Angular/React, которые под свой фреймворк ... и все:)
- Code is design - код и проектирование неразделимы. Автор говорит о том, что зачастую люди под проектированием понимают выбор конкретных технологий навроде K8s, что заменяет решение изначальной проблемы. Другая проблема - это выделение отдельной должности архитектора, к которому отъезжают вопросы проектирования и архитектуры. Кстати, на эту тему был выпуск подкаста "Code of Leadership", где мы с Лешей Тарасовым, техдиром социальных платформ в Тинькофф, обсуждали staff+ трек для индивидуальных контрибьюторов и почему архитектор - это роль высокоуровневых инженеров, а не выделенная должность. В итоге, Дейв заканчивает тезисами хороший код - это выбор организационных принципов для решения проблем. Дизайн - это выбор, который мы делаем каждый день, когда пишем код.
- Quality over features - великие программисты гордятся своей работой и стремятся сохранить и поддерживать свою способность вносить изменения в течение длительного времени. Это имеет смысл, если вы делаете не одноразовые скрипты. Так совокупная стоимость владения на протяжении работы с кодом меньше, так как большую часть времени мы читаем и дорабатываем код. Качество кода проще поддерживать, если у вас есть настроенный CI/CD и вы работаете в продуктовом, а не проектном подходе
- Software development is a social activity - автор говорит о том, что разработка софта - это социальная активность и для того, чтобы быть крутым инженером надо уметь хорошо общаться, уметь активно слушать окружающих, а также внятно доносить свои мысли.
- Avoid code ownership - великие разработчики открыты для критики и готовы учиться новому. В профессиональной среде важно разделять ответственность за код и избегать единоличной ответственности.

P.S.
Раньше я уже рассказывал про другое видео Дейва "The Most Powerful Software Development Process Is The Easiest", которое может быть интересно посмотреть в продолжение этого видео.

#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE #SelfDevelopment

ЦЕХ 4 - Урок #5. "Как преодолеть писательские блоки. Практическое занятие. Эксперт — Юлия Баяндина"

Продолжая серию постов про свое обучение книгописательству (смотри предыдущие посты: 1, 2, 3 и 4), я расскажу про пятый урок. Он был посвящен тому, как преодолевать писательские блоки. Это практическое занятие вела Юлия Баяндина — партнер и содиректор МИФа, которая девять лет назад с нуля выстроила систему контент-маркетинга.

Занятие было практическим - каждый участник работал со своим листом A4, который он постепенно заполнял текстом в следующем порядке
1) Воспоминания о своем детстве, юности и других периодах жизни. Я родился на берегу Белого моря в городе Северодвинске и до 18 лет жил с видом на побережье, за которым начинался хвойный лес, который уходил в бесконечность и сливался с горизонтом:)
2) Светлые воспоминания о каждом десятилетии, например, в детстве мне очень нравилось понимать что-то новое об окружающем мире - я был любопытен и любил мучить окружающих вопросами:)
3) Воспоминания о начале писательской деятельности. У меня первым опытом было написание фанфика на трансформеров, которые мне нравились в детстве. В итоге, я попробовал написать что-то по ним в первом классе ... круто, что старых тетрадок не сохранилось:) Ну а сейчас у меня есть желание перейти от статей к крупной форме и соединить их в книгу.
4) Мысли о том, что такое творчество. Мне кажется, что моя текущая работа тоже имеет творческую природу, так как решение комплексных задач до сих пор тешит мою любознательность и позволяет не скучать:) Ну и последние несколько лет я творчески подхожу к изложению своих мыслей в блоге и канале
5) Описание того, а что для нас это книги. Для меня книги - это способ отдохнуть и зарядиться энергией. А своя книга - это способ выгрузить на бумагу мысли, которые крутятся уже давно. Надеюсь, что потом я смогу чуток отпустить эти темы и переключиться на смежные
6) Наши мысли про профессию или роль писателя. И кто из авторов может быть для нас примером. Конкретно для меня авторы - это люди, которые проявили силу воли и смогли дописать свою книгу и изложить свои мысли на бумаге. Я прочитал много книг и мне нравится слишком много авторов, чтобы выделять конкретных.
7) Чем мы хотим поделиться с аудиторией. На этот вопрос я отвечал еще в первой домашке и я хотел рассказать про менеджмент и техническое лидерство в IT. Книга о том, с какими задачами сталкиваются лидеры в технологических компаниях России и мира. В книге не стоит задача описать каждую ситуацию и ее решение, скорее я хочу поделиться своей системой мышления, которая позволит читателям стать эффективнее в плане лидерства.
😍 Описание своих читателей и целевой аудитории. Для меня целевыми читателями будут инженеры и инжиниринг менеджеры, которые сталкиваются с техническими и управленческими вызовами при разработке софта в своих организациях.
9) Описание группы поддержки - обычно именно им посвящены благодарности в начале или конце книги. Мне понравилась фраза вида "спасибо моей семье за то, что эта книга вышла на пару лет позже, чем могла бы":)
10) Список людей, что нас вдохновляют. Мне нравятся ребята вида Джеффа Дина, Эндрю Танненбаума, Вила Ларсона
11) Создание обложки книги с отзывами на книгу, которые мы придумываем сами от лица людей, что нас вдохновляют.
12) Создание аннотации к книге, которая в одном абзаце должна заинтересовать потенциального читателя, взявшего книгу в руки.
13) Название книги и свое имя на обложке.
14) Ну и в конце надо представить, что книга уже вышла, вы получили свою бумажную копию книги и дальше вспомнили, что прошло между стартом работы и выпуском, а также что вам помогло дойти до конца.
15) Ну и в конце надо написать заголовок к эссе, которому у нас получилось в результате этого урока.

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

#Writing #SelfDevelopment #Management

Code of leadership #14 - Interview with Artem Ivanov about Risk Tech

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

- Дополнительные материалы про RiskTech, технический стек, контакты и вакансии
доступны здесь
- Плюс если кто-то хочет пообщаться с Артемом лично, то можно писать ему в Linkedin

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