Терри Пратчетт, трилогия «Мойст фон Липвиг»

«О, господин фон Липвиг! Я всю жизнь мечтала работать за прилавком Почтамта! Моя бабушка всему меня обучила, нас даже кормили лимонами, чтобы натренировать выражение лица!»

Передохнём от работы и серьёзности, поговорим о жизни и радости!

В Терри Пратчетта я влюбился с первой строки. Стиль Пратчетта — это юмор, ирония и абсурд, под которыми спрятаны серьёзные вопросы.

Недавно я дочитал трилогию про Мойста фон Липвига: «Держи марку!», «Делай деньги!» и «Поддай пару!». Книги посвящены приключениям чудом выжившего прохвоста и мошенника, который постепенно становится на путь истинный и начинает применять свою изобретательность на благо общества.

Выбор был случайным. Я просто хотел почитать Пратчетта и наткнулся на рекомендацию этой серии. И ни капли не пожалел. Сэр Пратчетт мастерски вплетает в канву юмора, иронии и абсурда сложные темы: честность и честь, прощение и даже относительность понятия свободы.

Читая эти книги, я отдыхал душой и местами смеялся до слёз. Но третья книга показалась слабоватой по сравнению с первыми двумя. Если «Держи марку!» и «Делай деньги!» я прочитал на одном дыхании, то «Поддай пару!» оказалась скучноватой. Дочитывал я её из чистого упрямства и желания поставить точку в серии. Но серия всё равно 🔥!

Если читали что-то хорошее из художки в последнее время — пишите в комментах! Пополним друг другу списки на чтение 💛

Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

Говори о проблемах словами через рот

Вы умеете читать мысли? Вот и я не умею. И никто не умеет. Но люди почему-то продолжают ждать, что прилетит вдруг волшебник в голубом вертолёте и всё исправит.

На круглом столе Подлодки по soft skills (скоро опубликую запись и саммари) я выделил один конкретный, простой и крайне полезный навык: говорить о своих проблемах словами через рот.

⭐️ Сами не догадаются

Я не просто так начал пост с того, что люди не умеют читать мысли. Но все дружно забывают об этом, когда думают о своих желаниях и проблемах. Кто-то стесняется говорить об этом, кто-то даже стыдится. Но всех их объединяет надежда, что другие люди “сами догадаются”.

Не догадаются. Даже пытаться не станут, скорее всего. Мы живём в диком ритме и бурном потоке информации, часто забывая подумать даже о своих желаниях и проблемах. Мало кому хватает ресурса подумать ещё и о других людях — со своими делами бы раскидаться.

⭐️ Чаша терпения

Проблемы и внутренние конфликты имеют неприятное свойство: они раздражают, и это раздражение накапливается. В какой-то момент чаша терпения переполняется — и происходит “бум”. Причём происходит он в самый неподходящий момент.

Во избежание этого “бума” напряжение нужно снимать. И нет, поныть кому-то в пятницу за рюмкой чая тут не поможет. Жалобы на жизнь только усиливают раздражение и фрустрацию. Нужны реальные действия, которые что-то изменят.

⭐️ Упрости жизнь себе и другим

Решение простое и сложное одновременно. О своих проблемах можно и нужно говорить с теми людьми, которые реально могут помочь. Не просто поныть, а рассказать о проблеме и своём взгляде на неё, предложить варианты решения.

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

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

Если нужна помощь — говорите об этом. Никто не обязан догадываться о наших проблемах.

// Ставь 💛 в поддержку тех, кто не стесняется говорить о своих проблемах

Сезон кода в Казани объявляется открытым!

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

Мне нравится, что в последние годы становится всё больше летних IT-мероприятий под открытым небом, посвященных не только докладам, но и приятному времяпрепровождению. И в этот раз повезло Казани — здесь Т-Технологии проведут «Сезон кода» — фестиваль для IT-специалистов всех направлений! Пройдёт он в экстрим-парке «Урам» со всеми вытекающими последствиями в виде экстрим-активностей и афтепати с DJ-сетом на открытом воздухе.

⭐ Что будет на фестивале

➡ Эксперты Т-Банка в мощных докладах расскажут о рабочих кейсах и внутренней кухне;
➡ Зона со скейт- и баланс-бордами, самокатами и мастер-классами по теггингу;
➡ Инженерные зоны, где гости смогут познакомиться с IT-решениями и получить карьерную консультацию;
➡ Много нетворкинга;
➡ Афтепати с видом на мост «Миллениум», DJ-сетом и отдыхом в лаундж-зоне.

Конечно же, на фестивале будут доклады. Основных секций будет три:

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

➡ Где: г. Казань, экстрим-парк «Урам»
➡ Когда: 12 июля 2025, 10:30

⭐ Регистрация

Для регистрации на «Сезон кода» нужно выполнить всего два шага:
1️⃣ Зарегистрироваться на сайте фестиваля.
2️⃣ Пожертвовать от 1 000 ₽ в один из трёх благотворительных фондов.

После этого билет придёт на указанную почту.

‼️При внесении пожертвования обязательно укажите ту же почту, что и при регистрации, иначе билет может потеряться.

📎 Переходите по ссылке и регистрируйтесь на фестиваль. Желаю вам прекрасно провести время в компании единомышленников! 💛

Волков бояться – на собесы не ходить

После пары постов о лоуперформерах и работе с ними я понял, что не могу обойти стороной такое явление, как «волки».

Тема over-employment и фейковых резюме сама по себе не нова. Просто IT — более молодое направление, до которого наконец-то добрались любители лёгкой жизни и халявы. Я фейков насмотрелся ещё в годы фриланса, поэтому не был особенно удивлён этому тренду.

Удивила же меня идеология, которая больше напоминает секту. Ни с кем не устанавливай связи, работай по минимуму, доверяй только своим, свято следуй догмам. В отдельную догму выносится «нагибай бизнес», который, дескать, цинично относится к людям и всё такое. Напоминает нагибаторов из доты :)

⭐️ Играй за имя на груди — и люди запомнят имя на спине

Тони Адамс, бывший футболист из клуба "Арсенал" всё верно сказал.

Я за свою жизнь выстроил не одну команду. И все мои команды круто работали, достигали результатов и были эффективны. Знаете, почему? Потому что мы работали как единое целое: одна цель, общие радости и фейлы, помощь и взаимовыручка. Небольшая, но сплочённая команда может достигать кратно большего, чем большая группа людей.

Так вот, с «волком» невозможно выстроить команду. Просто потому, что этот человек не является командным игроком. Он преследует свои цели за счёт других людей. Ему плевать на результат, на людей, на команду. Он пришёл снять по максимуму бабок и соскочить. С таким человеком невозможно затащить хоть сколько-нибудь значимый проект, просто потому что ему безразличен результат.

Настоящий волк хотя бы охотится.

⭐️ Доверие — фундамент команды

Однажды мне досталась команда, в которой был человек с накрученным резюме. Конечно, он это тщательно скрывал (как ему казалось). Но я быстро об этом узнал и первым делом уволил его. Средства OSINT позволяют выяснять подобную информацию за пару минут и пару сотен рублей :)

Причина тому проста. Я работаю только с людьми, которым могу доверять и на которых могу положиться. Я должен быть уверен в каждом члене команды. Могу ли я быть уверен в человеке, который попал на своё место обманом и заинтересован только в наживе?

Доверие в команде — штука очень хрупкая. Его сложно выстроить и очень легко разрушить. «Волк» в команде может нанести доверию непоправимый ущерб, после которого команда может и не восстановиться. Но если эту болезнь вылечить быстро, то сотрудники вам только спасибо скажут.

Знаете, как я объяснил команде увольнение? «У него было фейковое резюме и две работы.» Этого было достаточно.

⭐️ Найм сломан?

«Волки» действительно подсветили одну фундаментальную проблему в современном IT. Найм сломан, было бы безумием это отрицать.

Собесы стали маскарадом, на котором задача сводится к «показать себя программистом». Пока инженеров нанимают по стандартным вопросам, задачам и алгоритмам — будут люди, желающие хакнуть эту систему. Даже я на менторских консультациях учу своих клиентов разделять навыки инженера и навыки прохождения собеседований.

Но фейки на собесах приведут только к тому, что мы откатимся на 10 лет назад и будем проводить все собесы офлайн, а нанимать в первую очередь по рефералке. Классическая трагедия общин — «волки» пытаются сделать лучше себе, но гадят всем, включая самих себя.

Зато ценность действительно крутых ребят на этом фоне растёт по экспоненте.

⭐️ Итоги

Лично я просто не уважаю «волков». Я не питаю к ним ни презрения, ни ненависти. Я просто считаю подобное поведение низким и недостойным.

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

Но люди, которые хотят только результат без сопутствующих усилий и изменений личности... Вспомните Остапа Бендера — обаятельного авантюриста, который хотел лёгким путём заработать миллион и гулять в белых брюках по набережной Рио-де-Жанейро. Если читали произведения Ильфа и Петрова, то знаете, чем закончился его путь (и каким он был).

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

Что делать, если сотрудник просел по перформансу?

В постах про лоуперформеров постоянно возникал один вопрос: как отличить реального раздолбая от человека, у которого случилась временная просадка?

Давайте поговорим, что же делать в случае просадки перформанса у кого-то из сотрудников.

⭐️ Не торопись

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

Некоторое время стоит просто понаблюдать. Возможно, проблема пройдёт сама по себе.

⭐️ А поговорить?

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

Не давите на человека. Просто расскажите ситуацию со своей точки зрения (метод BOFF в помощь) и дайте сотруднику возможность рассказать свой взгляд на вещи. Даже сам факт разговора может помочь человеку вернуть мотивацию, потому что он будет чувствовать себя получше, когда выговорится.

⭐️ Personal Improvement Plan

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

Ключевая работа здесь на вас как на менеджере. Нужно сделать целый ряд действий:
➡️ Определить причину проблемы. От этого будет зависеть весь остальной план, потому что отправлять выгоревшего сотрудника на обучение – так себе идея.
➡️ Определить сроки улучшения. Кому-то может понадобиться 3 месяца, а кому-то и месяца вполне хватит.
➡️ Подобрать задачи на этот срок. Желательно, чтобы сотрудник сам проставил оценки этим задачам.
➡️ Согласовать срок и задачи с сотрудником. Обе стороны должны «окнуть».
➡️ Поставить регулярные синки. Я обычно ставлю 1-1 на 30 минут раз в неделю – этого хватает.

Дальше уже всё зависит от сотрудника. Либо он справляется с поставленными задачами, либо получает оговорённые заранее последствия. И вы должны проговорить это явно.

На эту же тему недавно хороший пост выпустили коллеги из канала «Метод утёнка». А ещё рассказали, какие вообще перформеры бывают и чем отличаются.

// А как вы помогаете своим сотрудникам восстановить производительность?

Максимилиано Контьери, «Рецепты чистого кода»

Ну что, отдохнём немного от софтов и побалуемся вкусным техническим контентом? Не думали же вы, что я только софтовые книги читаю, правда?

Всякого интересного технического я читаю довольно много. Но раньше редко делился этим в блоге — всё казалось как-то не к месту. Даже отдельный канал для технички завёл. Однако недавно понял, что сам себя перемудрил. Я же технический руководитель, как-никак. Так что буду писать обо всём понемногу.

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

⭐️ О чём книга

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

В книге затрагиваются следующие темы:
➡️ Чем плохи анемичные модели и как их сделать лучше
➡️ Как уменьшать сложность кода
➡️ Как упрощать условные операторы
➡️ Работа с техническим долгом и исключениями

⭐️ 3 идеи из книги

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

🟡Использование утверждений вместо отрицаний. Частенько в коде попадаются методы/переменные/функции, которые “не-что-то”. Утвердительные названия проще читаются, поэтому такие наименования лучше менять на "что-то”.

🟡Проблема йо-йо: когда для понимания кода приходится перемещаться вверх-вниз по иерархии классов. Сейчас я с кайфом пишу на Go, который лишён этой проблемы (и полон других). Но раньше (особенно на .NET) разобраться с источником проблемы могло быть очень непростой задачей.

⭐️ Мои впечатления

Скажу сразу честно: книга — кусок тихого ужаса. Я не знаю, пробовал ли автор на практике сам то, что написал, но выглядит это всё жутко. Штош, про плохие книги тоже нужно говорить.

Начну с того, что все примеры написаны на разных языках. Одни проблемы актуальны только для JS, другие — только для Python, третьи — ещё для чего-то. Читать это как минимум неудобно, особенно если не знаком хотя бы с азами синтаксиса.

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

Короче говоря, рекомендую держаться подальше от этой поделки. Лучше почитать Чистый код Мартина и Объектно-ориентированное конструирование Мейера, на которые так активно ссылается автор. Эти книги хотя бы написаны программистами, которые реально код писали.

Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

Почему ты не растёшь, хотя постоянно что-то читаешь и делаешь пет-проекты

Как вы знаете, я иногда консультирую. И за последнее время ко мне пришли сразу несколько ребят с одним и тем же запросом: «Я хочу расти как инженер. Что для этого почитать/посмотреть/поделать?» Я решил запилить серию постов на эту тему, поэтому призываю вас к активной дискуссии, чтобы улучшить эти материалы и сделать их полезными для всех.

Поехали!

⭐️ Не «почитать» и «посмотреть», а «поделать»

Недавно я посвятил серию постов принципам обучения. Напомню ключевой тезис: получение информации не есть обучение. Просто прочитать книжку и даже пересказать её своими словами (или написать обзор содержания) недостаточно для развития. Полученные идеи нужно «переварить», сделать своими и применить где-то в жизни. Тогда и только тогда будет в коня корм.

Для того чтобы расти как профессионал, нужно делать что-то новое (или старое по-новому).

⭐️ «Поделать» в первую очередь нужно на работе

Почему-то очень многие разработчики при упоминании роста сразу думают о пет-проектах. Даже на консультациях не раз слышал: «Я тут думаю пет-проект запилить…»

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

А это по-своему сложно. Все умеют расти в условиях, когда есть сложные задачи и новые вызовы. Там много ума не надо — бери да делай. А что делать, когда задачи относительно рутинные и ничего сверхъестественного не происходит?

⭐️ Где брать задачи на вырост?

Напомню мысль из ещё одного поста: говорите о своих проблемах словами через рот. Вам скучно и хочется новых вызовов? Поговорите об этом с руководителем. Если он не может помочь — попросите его поднять вопрос выше, на уровень своего руководителя. А ещё лучше найдите проблему и придите к нему сразу с предложением её решения. Всегда есть инженерные проблемы и вызовы, на которые никто не обращает внимания и которые представляют собой мину замедленного действия. Я так на прошлом проекте парочку архитектурных задач затащил.

Профессиональное развитие само по себе является набором навыков. Например, можно прокачать в себе навык поиска проблем и узких звеньев с последующей «продажей» их реализации (поверьте моему горькому опыту — очень ценный навык для техлида). Можно развивать в себе навыки роста на рутине (об этом напишу отдельно). Можно делать те же пет-проекты, но с чётким пониманием, как их использовать для роста.

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

// Ставьте 💛, если интересно продолжение и пишите в комментариях свои вопросы к следующим постам

Как превратить рутину в профессиональный рост

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

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

⭐️ Майндсет senior-специалиста

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

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

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

⭐️ Поиск проблем — это навык

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

Развивается этот навык точно так же, как и все другие — постоянным действием. Лучше всего у меня работают два инструмента: журнал проблем и регулярная рефлексия.

➡️ Журнал проблем

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

➡️ Регулярная рефлексия

Раз в неделю я сажусь и размышляю. Я задаю себе следующие вопросы:
❓Что меня тормозит или бесит в работе? Как я могу убрать это навсегда или хотя бы надолго?
❓Что меня расстраивает в нашей работе?
❓Куда я трачу слишком много времени и сил за скромный результат?
❓Что мешает нам как команде быть в 2 раза быстрее?

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

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

Проблемы не мешают росту. Они и есть рост. А в следующем посте поговорим, что дальше делать с найденными проблемами.

// Не забываем ставить 💛во имя решения проблем

Б. Бейер et al., «Site Reliability Engineering. Надёжность и безотказность как в Google»

Одна из важнейших зон ответственности технического руководителя — обеспечение надёжности. Если вы сделали прекрасный, полезный для людей продукт, но ваши серверы лежат — считайте, что продукта нет.

Как технический руководитель, я регулярно обогащаю свои знания в области SRE (даже курс по администрированию кубера проходил). И, конечно, мне интересен опыт одной из крупнейших технологических компаний мира, работающей с колоссальными нагрузками и строгими требованиями к надёжности — Google.

⭐️ О чём книга

Книга представляет собой сборник статей и транскрипций выступлений на тему надёжности от инженеров из Google. Для удобства читателя они разбиты на четыре раздела: введение в SRE, принципы, практики и управление.

В книге раскрываются следующие темы:
➡️ Как организована работа SRE-команд в Google
➡️ Процесс дежурств и всё, что с ними связано
➡️ Как справляться с критическими ситуациями
➡️ Почему SRE должны заниматься разработкой
➡️ Как строить эффективные команды SRE

⭐️ 3 идеи из книги

🟡«Скучность» ПО является его достоинством. Вряд ли кто-то захочет работать в среде, где программа может вести себя как попало. Чем более предсказуемы наши системы — тем лучше всем вокруг.

🟡Упреждающий подход к авариям: SRE-инженеры в Google часто устраивают учебные сбои и ломают собственные системы, чтобы найти несовершенства в процессах мониторинга, алёртинга и устранения сбоев.

🟡RPS — плохая метрика. Разные запросы имеют разные потребности в вычислительных ресурсах. Стоимость запроса может изменяться от целого ряда факторов. RPS однозначно стоит использовать для мониторинга нагрузки, но этот показатель не должен быть единственным.

⭐️ Мои впечатления

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

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

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

В целом, книга достаточно хороша, чтобы погрузиться в проблему построения надёжных, отказоустойчивых систем и организовать базовую работу команды SRE. Это скорее инженерная философия Google, чем учебник. Рекомендую читать главы выборочно — всё подряд читать не стоит.

Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

Программа активностей на июль

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

⭐️ Yandex Dream → Teamlead

Недушная конференция от Яндекса для тимлидов и им сочувствующих. В программе — доклады по управлению и круглые столы от интересных спикеров. Я буду участвовать в круглом столе на тему «Перегруженность — для слабаков: полезные лайфхаки для управления временем» с такими крутыми собеседниками, как Геннадий Евстратов, Евгений Россинский и Оля Елисеева.

Также меня пригласили поучаствовать в экспертных консультациях — мы с коллегами будем разбирать ваши запросы и делиться своими рекомендациями. Для меня это новый и очень интересный формат.

🗓 19 июля, целый день
📍 Москва и онлайн

⭐️ Sber Frontend Meetup

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

Ссылки на регистрацию пока нет — как только появится, поделюсь в канале.

🗓 22 июля в 18:00
📍 Москва и онлайн

⭐️ Selectel Day Off 2025

Душевный IT-фестиваль, посвящённый борьбе с выгоранием. Все доклады, мастер-классы и активности сводятся к одной теме — помочь гостям чувствовать себя лучше морально и физически.

Я буду выступать с докладом «Предохранители от выгорания, или почему совет „Устал? Отдохни!“ не работает». Я расскажу о том, как сам проходил через постоянные циклы выгорания и чинил это, а также поделюсь простыми, но очень эффективными практиками самомониторинга.

🗓 27 июля, целый день
📍 Санкт-Петербург

До встречи 💛

Как перестать сливать свои идеи

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

⭐️ Это действительно проблема?

Далеко не всё то, что бесит, действительно важно. Решение всех проблем подряд напоминает стрельбу из пушки по воробьям. Со стороны это выглядит как бодрая и активная деятельность, но результатов от неё мало.

Поэтому в первую очередь нужно проанализировать найденную проблему и оценить её влияние. Помочь в этом могут следующие вопросы:

💛На кого влияет проблема? Кому она мешает жить?
💛В чём заключается негативное влияние проблемы? Почему оставить всё как есть — плохо? Как проблема влияет на бизнес, на команду и её процессы?
💛Каков масштаб влияния проблемы? На сколько человек она влияет? Насколько сильно влияет?

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

⭐️ Проработка решения

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

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

💛Какова цена внедрения предложенного решения? Цена должна соответствовать масштабу проблемы. Решение должно выглядеть выгодным.
💛Какие есть альтернативные решения? Возможно, эту проблему можно решить частично и подешевле, а не полностью и дорого.
💛Какие могут быть последствия и риски у нового решения? В реальной жизни всё — это компромисс, поэтому решение одной проблемы неизбежно создаст новые трудности.

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

Умение думать в терминах ценности и издержек — важнейший навык роста.

⭐️ Что делать, если проблему не приняли?

Начну с неприятного: большинство ваших прекрасных идей будет отвергнуто. Ситуации бывают разные, но чаще всего причина отказа кроется в недостаточной подготовке. Проще говоря — не удалось «продать».

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

В следующем посте я приведу пару примеров того, как работал с проблемами.

// Эта часть — одна из самых важных в цикле. Задавайте ваши вопросы в комментариях, давайте вместе разбираться.

Как превратить «бесит» в конкретное улучшение: 3 случая из моего опыта

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

⭐️ Бесячие мелочи

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

Вот пример. В процессе релиза ответственному нужно было смотреть метрики и логи, а также проверять состояние подов в Kubernetes. Действия достаточно простые, но каждый раз приходилось искать эти самые метрики и логи, да и команды kubectl имеют свойство забываться, если ими не пользоваться. При очередном релизе я понял, что у меня уже глаз дёргается, и просто добавил в документ процесса релиза все необходимые ссылки, описания команд kubectl и короткую инструкцию, как ими пользоваться.

Это простое действие заняло у меня минут десять, но заметно упростило жизнь всем, кто занимался релизом. А ещё стало проще онбордить людей — вся информация по процессу релиза была под рукой, в одном документе.

⭐️ Системная боль

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

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

Я в какой-то момент заподозрил проблему и провёл анализ: просто взял несколько последних эпиков и посмотрел задачи, которые заводились на доработку (примерно прикинул по датам заведения). Оказалось, что доработки могут доходить до 20% эпика. Просто подумайте: каждый пятый тикет — доработка! Да и разработчики раздражались из-за этого.

Я предложил следующее решение: внедрить API-first. Теперь спека API проектировалась на стадии проработки требований и согласовывалась обеими сторонами. Спека писалась после дизайна, так что было легко заранее продумать, что нужно получать фронту от бэка. В качестве аргументации использовал анализ, описанный выше.

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

⭐️ TBD: полгода работы ради стабильности

Одна из самых крупных проблем, которую я решал, — общий переезд нескольких команд на trunk-based development. Найти эту проблему было очень просто: бизнес постоянно был недоволен скоростью поставки, а из-за интеграции работы в большом монолите постоянно лезли баги.

Здесь я тоже провёл дополнительный анализ проблемы: взял несколько последних релизов и посчитал, сколько времени у нас занимает один релиз и сколько в среднем багов вылезает в зависимости от его объёма. Цифры получились страшные.

Следующим шагом я проработал вариант решения. Оно было сложным и требовало значительной переработки процесса CI/CD. Но любые идеи попроще были равносильны прикладыванию подорожника к открытому перелому.

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

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

⭐️ Итоги

Проблем и пространства для улучшений вокруг очень много. Важно развить в себе наблюдательность и научиться замечать их. «Придумывать» проблемы не рекомендую — вряд ли такие решения будут кому-то полезны (да, гениальные стартапы по выгулу собачек?). Просто внимательно наблюдайте, слушайте окружающих — и идеи не заставят себя ждать.

«Проект "Феникс". Роман о том, как DevOps меняет бизнес к лучшему», Кевин Бер et al.

«Я не понимаю, почему на неё все дрочат, честно говоря» (с) Андрей Синицын

Про эту книгу я слышал уже много раз, причём она постоянно мелькает в подборках книг для тимлидов. Я поддался любопытству и решил прочитать её, чтобы разобраться, откуда столько восторженных отзывов. Тем более что недавно я прочитал «Site Reliability Engineering. Надёжность и безотказность как в Google», и мне хотелось расширить своё восприятие роли DevOps в бизнесе.

⭐️ О чём книга

Книга — это бизнес-роман о том, как страдающая компания по производству и продаже автомобильных запчастей выбирается из глубокого кризиса. По формату очень напоминает «Цель» (к которой есть несколько отсылок). Главный герой внезапно становится руководителем, чья задача — сделать так, чтобы технологическое состояние компании позволило ей успешно конкурировать на рынке.

В книге раскрываются следующие темы:
➡️Как можно применить теорию ограничений к работе IT-отдела
➡️Как выстраивать надёжность с помощью стандартизации процессов
➡️Почему так важно постоянное совершенствование процессов
➡️Что вообще такое «работа» и какая конкретно работа важна

⭐️ 3 идеи из книги

🟡Разобраться с тем, какая работа важна, гораздо важнее, чем впихнуть ещё больше работы в систему. Часто мы перегружены работой, но даже не задумываемся о том, какая её часть действительно несёт ценность. А ведь работа вполне может быть избыточна, оттягивая на себя ценные ресурсы.

🟡Для повторяющейся работы нужно создавать спецификации. Просто хороший инженер с инструкцией для стабильной работы гораздо ценнее гения-всезнайки. Чем более стандартизирована такая работа — тем меньше вероятность, что что-то пойдёт не так или её будет некому делать.

🟡Незапланированная работа откусывает ресурсы у запланированной. Поэтому количество незапланированной работы нужно старательно и неуклонно снижать. Она всё равно будет (всякое бывает), но стремиться нужно в первую очередь к следованию плану.

⭐️ Мои впечатления

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

Мне особенно понравилось, что книга концентрируется не на технической стороне вопроса, а на бизнесовой. Часто мы забываем в своей технической работе о том, что все наши сервисы в конечном счёте служат бизнесу, чья задача — зарабатывать деньги, предоставляя ценность своим клиентам. И трудности в работе IT могут оказывать крайне негативное влияние на эту ценность.

В целом книга не является «открывающей глаза» или «полной озарений», а в некоторых аспектах ещё и морально устарела (они там с bare metal на виртуалки пытаются переехать). Но читается она интересно, довольно легко (несмотря на корявый перевод) и содержит довольно много полезных идей.

Хорошая книга для отдыха от серьёзной литературы с пользой. Если хочется погрузиться в DevOps как управленческую практику — это хорошее и ненапряжное начало.

Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

От хаоса в голове к системе анализа своего дня

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

С одного из таких вечеров и началась моя история работы с дневником. Я понял, что голову просто разрывает от мыслей и их срочно нужно куда-то выгрузить. Тогда я просто сел, открыл свой любимый Obsidian и начал писать.

⭐️ v1: просто выгрузка

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

Я эту технику уже знал и несколько раз использовал, поэтому применил её для своего первого дневника. После яростного печатания в течение примерно 30 минут я почувствовал, что голову немного отпустило. Все эмоции и события сегодняшнего дня перенеслись с головы в текст.

Это состояние мне настолько понравилось, что я повторил написание дневника на следующий вечер. И ещё раз. И ещё.

⭐️ v2: короткая рефлексия

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

Тогда я понял, что нужно сфокусировать свою деятельность. Я оставил фрирайтинг, но добавил простые вопросы, на которые сам себе отвечал:

💛Что я сегодня делал? Почему это важно?
💛Что я сегодня понял и осознал о себе и мире?
💛Что в будущем буду делать по-другому?

Я старался отвечать на эти вопросы коротко и по существу, не вдаваясь в художественные детали (всё-таки не мемуары пишу). Ответы на них сократили время написания дневника примерно наполовину, а ощущения стали приятнее – важные события дня теперь были как на ладони.

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

⭐️ v3: заметки в течение дня

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

В этот блок я просто записывал все мысли, идеи и штуки «на подумать», которые происходили в течение дня. У меня периодически происходят ситуации, которые неплохо бы отрефлексировать в спокойной обстановке – для этого и был предназначен этот блок.

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

⭐️ v4: утренние вопросы

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

💛Как я себя чувствую? Какое у меня состояние и настроение?
💛Какие три главных дела я должен сделать сегодня?
💛Какие трудности меня поджидают и как мне подготовиться к ним?

Эта практика уже имела очень интересное влияние на меня. Первый вопрос помогал мне осознать своё состояние и планировать из него (а то раньше я грешил тем, что нагружал себя работой, будучи заболевшим или невыспавшимся). Второй вопрос помогал настроить фокус на день. Третий вопрос помогал «подстелить соломку» на трудности предстоящего дня.

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

⭐️ v42: гибкая система

Сейчас мой дневник – это гибкая система утренних и вечерних вопросов к себе, которые я регулярно обновляю. Какие-то вопросы становятся для меня важными и я добавляю их, а другие отмирают и перестают приносить пользу. Форма может меняться, но суть та же: дневник помогает мне понять себя и сделать свою жизнь чуть лучше.

// А вы ведёте дневник? Какую его часть считаете самой полезной?

3 вида задач, которые воруют твои силы и время

В субботу в рамках круглого стола на Dream Teamlead нам задали прекрасный вопрос: «Какой совет вы бы дали себе в начале карьеры руководителя?»

Мой ответ звучал так: «Половина работы, которая кажется тебе важной, на самом деле — бесполезная хрень». А мои коллеги мудро добавили: «Осталось понять, какая именно половина».

В последние месяцы у меня значительно выросла нагрузка, поэтому я вновь вернулся к работе над своей продуктивностью. И «не делать бесполезную работу» — это чуть ли не главная техника, которой и был вдохновлён мой ответ. Но как же понять, какая работа является бесполезной?

⭐️ Что такое бесполезная работа

Под бесполезной работой я подразумеваю следующие вещи:
➡️Задачи, которые можно было вообще не делать
➡️Задачи, которые можно было сделать в меньшем объёме
➡️Задачи, которые можно было сделать проще

Во всех трёх случаях ресурсы тратятся нерационально. В первом случае всё очевидно: если задача не несёт ценности, то время и силы на неё тратятся зря. Отсекать такие задачи помогает, к примеру, техника «5 нахрена».

А вот с меньшим объёмом и упрощением всё интереснее.

⭐️ Достаточно хорошо

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

Особенно остро эта проблема ощущается в задачах, результат которых чётко не определён. Например, на этом «горят» многие начинающие авторы каналов: нет критериев хорошего поста, поэтому они продолжают дорабатывать материал до мифического идеала. Другой классический пример — рефакторинг уже работающей задачи на пару дополнительных дней.

Для каждой задачи нужно определить целевой результат (да, тот самый definition of done). Как только он достигнут — задачу можно спокойно закрывать и двигаться к следующей.

⭐️ Упрощай

Другой тип потери времени и сил — задачи, которые можно было сделать проще. Это работа вида «квадратное катим, круглое носим». Собираем релизы руками, забываем нажать какие-то кнопки или проставить галочки, на созвоне час обсуждаем то, что решается за пару сообщений… Примеров — тьма.

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

Для того чтобы упростить задачу, нужно заметить возможность упрощения. Иногда это происходит как озарение в процессе работы: делая задачу, я внезапно понимаю, что её можно упростить или автоматизировать. Но гораздо эффективнее замечать потенциал для упрощения ретроспективно, анализируя проделанную работу.

Важно не просто делать меньше. Важно перестать делать то, что не нужно.

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

// Ставь 💛 во имя борьбы с бесполезной работой

«Эссенциализм», Грег МакКеон

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

Я поставил перед собой задачу: делать меньше, не теряя в качестве и результатах. И эта задача оказалась на порядок сложнее, чем «собрать тудушник и календарик».

Занявшись этой задачей, я вспомнил про отличную книгу — «Эссенциализм». Я уже читал её несколько лет назад, и тогда она дала мне в руки волшебный вопрос: «Зачем?». Столкнувшись с той же задачей, я решил перечитать её с новым пониманием и опытом.

⭐️ О чём книга

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

В книге раскрываются следующие темы:
➡️Почему большая часть деятельности не является важной
➡️Как определить, что важно, а что — нет
➡️Как отказываться и избавляться от лишней работы
➡️Как снижать усилия, достигая тех же результатов

⭐️ 3 идеи из книги

🟡Научитесь расставлять акценты в своей жизни. Или за вас это сделает кто-то другой. Если мы сами не управляем своим временем, вниманием, направлением деятельности и смыслами, то кто-то обязательно займёт это вакантное место. Если мы не можем выбрать, на что направить своё время и энергию, за нас это сделают другие: начальство, коллеги, клиенты или даже члены семьи.

🟡Эссенциалист рассматривает больше вариантов выбора, потому что выбирает более тщательно. Он хочет вложить свои силы и время в 1–2 проекта, поэтому тратит больше ресурсов на анализ и выбор, чем обычный человек.

🟡Главный актив, который нам доступен, — это мы сами. Мы должны достаточно вкладывать в себя: здоровье, физическое и моральное состояние, обучение. Тело и дух должны быть в порядке, иначе мы не сможем ни адекватно работать, ни двигаться к своим целям.

⭐️ Мои впечатления

По сути, вся книга посвящена одной мысли: «лучше меньше, да лучше». Мысль хоть и простая, но сделать её жизненным кредо довольно сложно. Особенно в наш век соцсетей и успешных успехов (LinkedIn вообще хоть не открывай).

Эссенциализм — это не просто идея, это принцип жизни. Только в такой роли он становится эффективным. Невозможно где-то делать всё подряд, а в других местах резко становиться избирательным.

Книга хорошая. Очень рекомендую к прочтению тем, кто постоянно «ничего не успевает» и хронически опаздывает жить.

Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте (а ещё я его обновил, зацените, какой он стал красивый).

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

Что делать, если кажется, что ты больше ничему не учишься?

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

Отчасти это связано с тем, что любая работа рано или поздно приедается. Новизна со временем уходит, поток новых знаний снижается, а ранее казавшиеся сложными задачи становятся рутиной.

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

Это нормально — так устроена наша психика. Именно поэтому вам в магазинах сначала предлагают что-то дорогое, а потом более дешёвое — на фоне дорогого оно кажется дешевле, чем есть на самом деле. Но в работе это искажение губительно, потому что вы всё время будете изнывать от скуки.

Есть классная техника, которую я использую для борьбы с этим состоянием — Today I Learned (TIL). Когда я чувствую, что заскучал, то просто добавляю эту рубрику в свой дневник и вечером записываю в неё все те небольшие, но интересные штуки, которые сегодня узнал и применил.

Например, вот что я узнал за последние пару рабочих дней:
➡️ Библиотека squirrel не умеет в нормальную работу с UNION.
➡️ Gemini довольно неплохо работает с текстами.
➡️ Я всё так же ненавижу верстать, а флексы — это боль.

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

// Вопрос на подумать: а что нового-интересного узнали вы за последние несколько дней?

Подпитка для мозга

У меня есть тайный доклад о том, как эффективно подкачивать свои hard skills (и не только их). Тайный — потому что его сокращённую версию мало кто видел, а схему полной видел только один человек в мире.

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

Это — одна из причин, почему я активно читаю каналы своих коллег по IT-шно-управленческому цеху. И один из таких каналов я сегодня хочу вам порекомендовать.

«Artur speaking» — это канал о жизни простого программиста, который уже достаточно поел реальности и при этом не растерял оптимизма. Артур делится тем, что его волнует в работе: говнокод, переусложнения, неквалифицированные управленцы и многое другое. Мне нравится то, что Артур не стесняется называть вещи своими именами, но при этом хорошо аргументирует своё мнение.

Вот несколько классных постов, с которых можно начать:
➡️ 10 признаков плохого разработчика
➡️ О переусложнении на ровном месте
➡️ Про неквалифицированных начальников

Подписывайтесь, читайте, забирайте себе полезные идеи 🔥