Никита Ульшин про IT

Сейчас я буду ссать вам в уши Очередной раз я убедился в том, как важно грамотно работать со входящей обратной связью. Увы, далеко не все люди умеют высказывать своё мнение конструктивно и вменяемо. Был у меня очередной прогон очередного доклада. Слушатели по кругу дают обратную связь, всё очень круто, конкретно и конструктивно. Но очередной спич начинается с фразы: «А мне вообще не понравилось. Если бы мне пришлось давать название этому докладу, то моей версией было бы «Сейчас я буду ссать вам в уши»». Далее последовал эмоциональный, напрочь лишенный конструктива спич минут на 15 о том, как плохо я всё сделал, какие у меня отвратительные и непонятные слайды, как я обесценил несколько профессий и так далее. Я узнал, что в моём докладе нет логики, ценности и смысла, что я сам себе противоречу и ещё несколько забавных фактов о себе самом. Как я отреагировал? Я просто молча выслушал всё это и спросил, какие у нас будут следующие шаги. Человек потерял дар речи — не такой моей реакции он добивался. А я просто на ходу применил все те принципы, которые описывал в цикле постов про работу со входящей обратной связью (вот ссылка, если не читали — обязательно сделайте это, я считаю эти посты одними из своих лучших). Человек в моих глазах не обладал достаточной экспертностью и компетенцией, а также разочаровал меня своим высказыванием. Поэтому лист с «обратной связью» после созвона отправился в мусорное ведро. А буквально через пару часов я получил гениальную технику, как подобную ситуацию можно развернуть в обратную сторону с помощью эмпатии. Но об этом напишу в отдельном посте. // Ставь 💛, если понравился заголовок

Ребята из YADRO так устали сидеть за компьютерами, что запустили серию экскурсий, чтобы появился веский повод отложить задачи и прогуляться пешком по центру Москвы 😍 💡 В коллаборации с просветительской компанией «Глазами инженера» они запустили познавательные прогулки по Мясницкой и проспекту Сахарова. Программу составляли инженеры для инженеров, поэтому вы не услышите банальных фактов и городских легенд. Зато увидите дом-компьютер, выучите несколько архитектурных терминов и проведете полтора часа на свежем воздухе. 💙 Билеты на сентябрь уже в продаже по ссылке!

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

«Новые принципы делового общения», Кэл Ньюпорт История циклична. Каждый раз ближе к отпуску я начинаю уставать и искать методы снижения своей когнитивной нагрузки. И каждый раз нахожу что-то новое и интересное. Про книгу Кэла Ньюпорта «Новые принципы делового общения» я уже несколько раз слышал хорошие отзывы от уважаемых мной людей. Сначала я думал, что она будет чем-то вроде книги Ильяхова — о том, как писать грамотно и понятно. Но вскоре понял, что ошибся: книга Ньюпорта посвящена диаметрально противоположной теме. А именно — как бесконечная переписка убивает нашу продуктивность. ⭐️ О чём книга Книга посвящена такой теме, как информационный шум. Ньюпорт на примерах и исследованиях показывает, что бесконечный обмен сообщениями в мессенджерах и электронной почте убивает продуктивность. Также он приводит набор принципов для более аккуратного управления своим вниманием. В книге раскрываются следующие темы: ➡️ Какой вред нам нанесло повсеместное распространение электронной почты ➡️ Почему общение по почте и в мессенджерах — это не работа ➡️ Как защитить своё внимание в мире постоянной болтовни ⭐️ 3 идеи из книги 🟡Обсуждать рабочие вопросы и решать их — это разные вещи, зачастую конфликтующие. Сколько я видел болтологий вокруг дел, которые просто нужно взять и сделать — не счесть. Конечно, иногда без обсуждения не обойтись, но всему нужно знать меру. 🟡Компании увязают в «более эффективных коммуникациях», хотя на самом деле самая эффективная коммуникация — та, которой не было. Есть куча продуктов для упрощения поиска в почте и мессенджерах, для написания саммари, ещё для бог весть чего. Но они, по сути, исправляют последствия информационного шума, а не работают с его источником. 🟡Когда вы действительно работаете, а не дёргаетесь по каждому сигналу мессенджера, продуктивность труда значительно увеличивается. А восемь часов работы становятся довольно трудной задачей. Но такой подход позволяет производить намного более качественный продукт. ⭐️ Мои впечатления Книга достаточно хорошая и простая. В ней читается любимый посыл Ньюпорта: «Хорош болтать, давайте работать». Ньюпорт приводит много исследований и примеров, которые показывают, как информационный шум снижает продуктивность и креативность. Вместе с тем книга очень водянистая. Идей немного, зато всякие истории и исследования занимают огромный объём. Если убрать всю воду, то, по моим ощущениям, книжку можно уместить в пару ТГ-постов. Это не значит, что читать её не стоит — очень даже наоборот. Просто рекомендую пропускать «водичку», которую автор местами переливает по кругу. Рекомендую к прочтению, книга неплохо помогает посмотреть на постоянную рабочую болтовню с другой стороны. Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте. ➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog

Сам себе рост: как я начал искать задачи, а не ждать подачек Я вырос с убеждением, что учиться и расти — это значит больше читать всяких книжек, больше знать. Про «больше уметь» мне деликатно забыли рассказать, хотя именно это — краеугольный камень роста. Я увлёкся этим вопросом и решил изложить свой взгляд на то, как расти на работе через «что-то новое поделать». Взгляд не уложился в один пост, поэтому получилась очередная серия мыслей о том, как профессионально расти через выполнение интересных, сложных и полезных другим людям проектов. Особенное внимание я уделил вопросу поиска задач для роста себя любимого. Искать и создавать себе возможности для роста — бесценный навык, который позволяет в любой ситуации вытаскивать для себя новый опыт. ⭐️ Содержание ➡️ Почему ты не растёшь, хотя постоянно что-то читаешь и делаешь пет-проекты ➡️ Как превратить рутину в профессиональный рост ➡️ Как перестать сливать свои идеи ➡️ Как превратить «бесит» в конкретное улучшение: 3 случая из моего опыта ➡️ Почему хорошие идеи отвергают и как это изменить Приятного чтения! // Если после серии остались вопросы – пишите в комментариях, я с удовольствием отвечу

Психологическое айкидо: как защитить себя от неконструктивной критики На прошлой неделе я написал пост о том, как в очередной раз проверил боем свои принципы работы с входящей неконструктивной критикой. Однако на этом история для меня не закончилась. Я в моменте сумел лишь сдержать свой гнев, чем сбил агрессора с толку. Я не стал ругаться и распалять эту ситуацию дальше, что для меня большое достижение с учетом врожденной вспыльчивости. Но буквально через пару часов у меня был другой созвон, где я вскользь упомянул произошедшее. Ситуация заинтересовала моего собеседника и он рассказал мне технику, которая позволяет развернуть ход разговора на 180 градусов. С ним этой техникой в свою очередь поделился один крутой коуч. Первый этап заключается в осознании, что человек вряд ли негативно настроен лично ко мне. Мы виделись буквально пару раз по 30 минут — я должен был бы сделать что-то очень серьёзное, чтобы заслужить такое отношение. Следовательно, у человека есть некоторая внутренняя боль, которую он выплёскивает в виде «социально приемлемой» агрессии. После осознания можно сделать разворот, озвучив свои догадки. Пример звучал так: «Мы не так давно знакомы, чтобы я успел заслужить настолько негативное отношение к себе. Что такого у тебя произошло, что ты отыгрываешься на мне?». Очень важно говорить это без агрессии, с эмпатией. Люди могут неосознанно отыгрывать свой внутренний негатив на окружающих. У человека может что-то болеть физически, могли произойти неприятности, в конце концов он мог просто переутомиться. И иногда в таких состояниях мы не замечаем, что ведём себя не лучшим образом. Мягкая, добрая формулировка этого вопроса позволит человеку остановиться и посмотреть на своё поведение со стороны. Даже если критик не захочет отвечать на этот вопрос честно или впадёт в отрицание, он всё равно лишится возможности атаковать. С момента озвучивания вопроса все его нападки будут выглядеть как попытки на вас отыграться за что-то, в чём он не хочет признаваться. Так что в лучшем случае вы поможете человеку или поддержите его, а в худшем — полностью дискредитируете его высказывания. Сложно ли это? Невероятно. Поэтому мы с уважаемым собеседником оба посмеялись над тем, что нам и сдерживать-то себя с трудом удаётся, а уж подобное поведение — вообще уровень шаолиньских мастеров. Но надо же стремиться к лучшему. // Пробовали ли вы делать что-то подобное? Поделитесь опытом в комментариях.

«Распределённые системы. Паттерны и парадигмы для масштабируемых и надёжных систем на основе Kubernetes», Брендан Бёрнс

Тяжесть — это хорошо. Тяжесть — это надёжно. (с) Борис Бритва

В последнее время меня увлекают книги по надёжности систем. Эта тема очень обширная, и её интересно изучать, потому что знания по надёжности постоянно пригождаются в работе. Поэтому я с большим удовольствием прочитал новую, недавно вышедшую книгу Брендана Бёрнса — «Распределённые системы». Мне было интересно узнать, какие такие паттерны распределённых систем на базе Kubernetes автор предлагает использовать. ⭐️ О чём книга Книга посвящена паттернам, которые можно применять при использовании Kubernetes для создания масштабируемых и удобных в эксплуатации распределённых систем. Автор адаптирует стандартные паттерны проектирования для применения в Кубере. В книге раскрываются следующие темы: ➡️ Паттерны для одного узла (пода) системы ➡️ Паттерны для обслуживающих систем ➡️ Паттерны систем пакетных вычислений ⭐️ 3 идеи из книги 🟡Один из самых простых и полезных паттернов — Sidecar. Суть его в том, что мы можем «подцепить» к поду ещё один контейнер, содержащий любую нужную нам функциональность. Например, этот контейнер может парсить логи другого контейнера и отправлять их в систему логирования. Некоторые другие паттерны в книге основаны на Sidecar. 🟡При проектировании контейнеров важно понимать, возможна ли ситуация множественной обработки. В частности, в системах пакетной обработки может возникнуть ситуация, когда один и тот же чанк данных возьмут в обработку несколько рабочих машин. Это нужно учитывать при проектировании системы. 🟡Добавление кэша в систему часто приводит к тому, что система оказывается намертво зависима от него. Часто это выглядит так: добавили кэш для ускорения, постепенно нагрузка растёт — и в какой-то момент система просто ляжет в случае отказа кэша. Я как-то в работе «развязывал» такой узелок и могу сказать, что это крайне нетривиальная задача. ⭐️ Мои впечатления Книга оказалась достаточно интересной. Местами я ехидно хихикал с того, как автор переизобретает названия паттернов банды четырёх и некоторые другие термины (например, retry storm он окрестил «грохочущим стадом»). Тем не менее, изложенные в книге паттерны и способы их применения полезны и применимы на практике. Отдельный плюс — спеки, которые можно скопировать себе и поиграться при желании. В книге есть и некоторые спорные моменты. Например, автор в одной главе рассказывает, как дорого стоят FaaS-вычисления при частом вызове, а в другой предлагает использовать их для сервиса аутентификации с немаленькой такой нагрузкой. Но в целом книга интересная и хорошо написана. Рекомендую к прочтению сильным инженерам и тем, кто хочет такими стать. Тимлидам тоже не повредит :) Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте. ➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog

Сегодня выступил на конференции E-Code от Ozon с докладом про лидерство в кризис. Спасибо слушателям за то, что пришли послушать доклад и задали отличные вопросы! Жаль, что не на все успел ответить, но некоторые вопросы были настолько хороши, что мне захотелось ответить на них в постах. Так что ожидайте новые интересные тексты и ходите на конфы 🔥 Отдельное спасибо организаторам за то, что пригласили. Такое мероприятие — это титанический труд и вы всё сделали невероятно круто, моё уважение 💪 Upd. Запись доклада уже есть по ссылке. Приятного просмотра ❤️

Опрос про работу с мотивацией для тимлидов Друзья, сегодня немного необычный пост. Этой осенью я выступлю на TeamLeadConf с докладом на тему «Как перестать демотивировать людей». Чтобы сделать доклад максимально полезным, я решил провести небольшое исследование — как тимлиды работают с мотивацией команды и с какими трудностями сталкиваются в этом процессе. Поэтому прошу вас пройти короткий опрос (всего 5 вопросов) и поделиться своей практикой работы с мотивацией. А если пошарите ссылку на опрос своим знакомым тимлидам — я вообще буду бесконечно вам благодарен 🫶 🧷Вот ссылка на опрос Опрос полностью анонимный, так что можете писать всё как есть. Ваш опыт поможет мне сделать действительно классный доклад (а может, и не один). Заранее спасибо и до встречи на TeamLeadConf 💛

Сушим работу: как разработка может перестать быть исполнителем В моём докладе про управление в кризис много эмоций вызвала тема «сушки» работы. Парадигма эта разработке непривычна, потому что стандартный процесс выглядит как: «Нате требования — пилите, Шура». «Сушка» работы же подразумевает, что требования можно видоизменять. То, что принёс бизнес-заказчик — не истина в последней инстанции, а просто предмет обсуждения. ⭐️ Философия «сушки» Для того чтобы успешно «сушить» работу, разработке в первую очередь нужно выйти из своего технологически-кодового пузыря и подумать о клиентах. Обычно мы так зациклены на коде, тестах и системах, что забываем: все продукты в первую очередь делаются для людей (которые платят за эти продукты деньги, из которых, в свою очередь, платятся наши зарплаты). Нельзя просто так взять и убрать требования из задачи. Чтобы грамотно «сушить» работу, нужно внимательно разобраться: ➡️Какую потребность клиента мы пытаемся закрыть этой задачей? ➡️Точно ли у клиента есть эта потребность, или это просто гипотеза? ➡️Можно ли закрыть эту потребность проще и дешевле? Только полное понимание ответов на эти вопросы покажет нам, какие части фичи нужно реализовывать в полном объёме, а какие можно упростить. ⭐️ Но это же работа продакта! Вообще этой философии я научился, запуская свои стартапы. Стартапы не взлетели, но опыт бережливого производства отпечатался на подкорке. Безусловно, это работа продакта. Но давайте не забывать, что средний продакт: ➡️тоже человек ➡️работает на несколько продуктов и не всегда успевает так заморочиться Я лично отношусь к этому как к возможности помочь продакту сделать фичу проще, быстрее и дешевле. И именно этот посыл я транслирую в коммуникации. Ни разу не было такого, чтобы продакт на меня обижался за мои вопросы — мы всегда находили общий язык. Давайте посмотрим с другой стороны. Одна из задач руководителя разработки — сделать стабильную и быструю поставку фич. Этого можно добиваться как классическим выстраиванием процессов, так и отсечением того, что не нужно делать. Выполняя работу по анализу фичи, вы тем самым можете ускорить поставку. В моём случае мы сокращали объём работы даже вдвое. А ещё это помогает разработке не забывать о том, что продукт они делают для людей. // Сушите ли вы работу в своей команде?