Telegram Group Search
Книги, по которым я прокачивал Go

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

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

📚 Михалис Цукалос, "Golang для профи"

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

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

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

📚 Джон Боднер, "Go. Идиомы и паттерны проектирования"

Книга Боднера мне понравилась гораздо больше. По сути, это углублённое руководство для новичков по Go. Автор рассматривает все базовые темы, но дополняет их особенностями и нюансами языка Go. Например, в главе про конкурентность Боднер объясняет, в каких случаях следует применять те или иные примитивы синхронизации.

Учтите, что в книге почти не рассматривается стандартная библиотека Go (stdlib), всё внимание автора сосредоточено на особенностях самого языка. Я не могу назвать это минусом — это просто особенность.

Если бы я сейчас начинал изучать Go с нуля, я бы порекомендовал пройти A Tour Of Go и дополнить его книгой Боднера. Такая связка даст очень хорошую базу для изучения языка.

📚 Тейва Харшани, "100 ошибок Go и как их избежать"

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

Для работы с материалом книги потребуются знания Go, поэтому она точно не должна быть первой книгой по языку. Более того, я не рекомендую её начинающим разработчикам — в книге довольно много нюансов и тонкостей. Однако при переходе с другого языка программирования (как в моём случае) книга очень полезна, так как показывает множество неочевидных особенностей поведения Go. Ошибки разбиты на несколько логических разделов, что делает чтение удобным — похожие ошибки идут друг за другом, и контексты не смешиваются.

Рекомендую к прочтению, если вы разработчик уровня middle и выше, или если вы переходите на Go с другого языка программирования.
Есть у меня одна мини-«традиция». Раз в несколько лет я в очередной раз от кого-то слышу, как ему «взорвала мозг» какая-то из книг Виктора Пелевина и принимаю решение в очередной раз дать шанс этому автору.

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

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

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

В этот раз я бросил на середине «Generation П». До встречи через несколько лет 😂

Читали Пелевина? Как вам?

#художественная_литература
Хорошо работать важнее работы мечты

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

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

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

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

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

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

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

Завтра в 18:00 по Москве я буду гостем на эфире Елены Логачевой, где мы обсудим эту непростую тему.

Елена Логачева - автор проекта «Эмоции успеха» и ментор IT-лидеров: переводит из мидлов в топы, развивая эмоциональный интеллект у людей с высоким IQ.
➡️ 9 лет работы старшим преподавателем в IT МВА ВШЭ
➡️ 10 лет управления HR-агентством, входившим в 5-ку лидеров, понимает HR задачи, стоящие перед топовыми IТ-компаниями, и знает, с каким проблемами в карьере сталкиваются IT-менеджеры.

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

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

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

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

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

Я заинтересовался и поднял скорость ещё немного. Результат оказался интересным: я стал играть ещё спокойнее и расслабленнее, хотя ошибок стало немного больше. Причём все ошибки были одного типа — играл не ту ноту или последовательность. Такие ошибки лечатся тренировкой мышечной памяти. Проще говоря, нужно просто «заиграть» грувы до автоматизма.

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

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

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

Возвращаясь к теме перфекционизма: доведение каждой мелочи до идеала требует огромного количества сил и времени. В результате скорость развития навыка падает: вместо решения всё более сложных задач я трачу энергию на ковыряние в том, что и так сделано достаточно неплохо. А развитие в первую очередь зависит от постоянного повышения уровня сложности деятельности.
Джеймс Стэньер "Карьера Software Engineering Manager"

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

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

О чём книга


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

Сама книга состоит из трёх больших частей.

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

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

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

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

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

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

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

#обзор_книги #management
А вот и запись подкаста про перфекционизм появилась! Всем приятного просмотра, если возникнут вопросы - можно задавать в комменты и личку.

#подкасты
Media is too big
VIEW IN TELEGRAM
⚠️ Практически 100% моих клиентов страдают ЭТИМ

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

Запись эфира на тему: «Перфекционизм в IT: как эмоциональный интеллект помогает справляться с желанием быть идеальным?» определённо будет полезна каждому из вас :)

Мой спикер – Никита Ульшин – руководитель команды разработки в Т-Банк, более 10 лет в IT, из них 5 лет – в управлении командами
с перфекционизмом прожил бок о бок много лет, и ему было, чем поделиться.

Мы обсудили, ПОЧЕМУ перфекционизм является частой проблемой в сфере IT, и ответили на ряд занимательных вопросов👇:

02:30 – стремиться сделать хорошо = перфекционизм?
Дьявол кроется в деталях: именно в этот момент перфекционизм обретает негативное трактование понятия
06:13 – лайфхак от Никиты, что делать, если всё-таки хочется «повылизывать» 😁
11:56 – откуда берётся желание достигать перфекционизма в работе и какие автоматические программы поведения этому способствуют?
16:54 – как методология Scrum помогает справляться с перфекционизмом?
18:00 – что именно стало самой первой таблеткой от перфекционизма у моего спикера? И еще парочку хитростей :)
23:10 – как ЭИ помогает использовать перфекционизм во благо и чем же можно заменить технику «битья морд» в порыве гнева (спойлер: это очень простая, но при этом эффективная техника быстрой самопомощи :)
36:13 – влияние перфекционизма на конфликты
38:53 – ЗДЕСЬ перфекционизм может помочь!
И вот такой мем под завершение нашего полезного эфира :)

Всем перфекционистам большой привет 🙂 и приятного просмотра!
Please open Telegram to view this post
VIEW IN TELEGRAM
Простой процесс постоянного роста

Я довольно активно занимаюсь менторингом как внутри компании, так и вне её. И в пятницу ко мне на менторинг пришёл коллега с очень интересным запросом: хочу развиваться в сторону техлида/архитектора.

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

Сосредоточились мы именно на "делать".

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

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

1. Найти точки, где что-то можно улучшить.
2. Предложить свои решения этих проблем тимлиду и команде.
3. Получить обратную связь и доработать свои предложения.
4. Реализовать улучшения.
5. GOTO 1

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

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

С моим менти мы решили проделать следующее упражнение:

1. Составить список того, что, на его взгляд, можно улучшить в команде.
2. Для каждой проблемы описать негативное влияние на команду.
3. Предложить альтернативные решения.
4. Описать положительное влияние, стоимость и процесс внедрения каждого решения.
4.1 Принести это всё на ревью ко мне :)
5. Презентовать результаты тимлиду и собрать обратную связь.
6. Сделать улучшения.

Упражнение очень простое, но при этом довольно просветляющее. Главное — выделить себе время и место, чтобы никто не отвлекал. Я стараюсь это упражнение выполнять раз в неделю-две, чтобы находить свежие идеи по улучшению процессов команды.

#mentoring #management #growth
SQL миграции в Postgres

Так уж вышло, что последние три месяца моя команда пилит runbook по шардированию красивых и толстых Postgres-ов. Мы узнали много всего интересного (в том числе и о себе местами), а в ходе этого приключения нам пришлось перелопатить уйму материалов по шардированию.

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

Сегодня я хочу поделиться двумя бесподобными статьями про особенности миграций в больших Postgres.

https://habr.com/ru/articles/540500/
https://habr.com/ru/articles/736458/

Первая часть посвящена достаточно простым миграциям, а вторая - более сложным вариантам типа разделения таблицы. Крайне рекомендую к ознакомлению всем работающим с Postgres, почерпнёте для себя много интересного.
Что делать, если эмоциональный диапазон как у зубочистки? Обзор книги Дэниела Гоулмана "Эмоциональный интеллект"

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

О чём книга

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

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

Топ-3 вывода из книги

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

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

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

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

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

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

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

#обзор_книги #management #психология
Как бесплатно повысить мотивацию членов команды?

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

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

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

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

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

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

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

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

В моей практике были следующие примеры:

- Тестировщица прошла курсы по UX и исправила множество недочётов в продукте.
- Бэкендер залез в автотесты, распараллелил их и ускорил прохождение джоба в три раза.
- Аналитик начал проводить потрясающие ретроспективы для команды.

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

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

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

#management
Иду в гости к Двум Иванам

Друзья, сегодня небольшой анонс. Два Ивана позвали меня к себе в подкаст гостем. Подкаст ведут Иван Елфимов и Иван Чернов - опытные инженеры из Ostrovok.ru. Ребята обсуждают разные интересные темы из мира IT: от языков программирования до архитектуры распределённых систем.

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

Запись конечно же будет :) До встречи!
Кэл Ньюпорт "В работу с головой"

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

О чём книга

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

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

В качестве примеров Ньюпорт приводит известных личностей: Карла Густава Юнга, Дональда Кнута, Адама Гранта. Также он много рассказывает о своём опыте глубокой работы и её влиянии на его жизнь и достижения.

Три вывода из книги

➡️ Глубокая работа — это работа в состоянии максимальной концентрации над важными задачами. В процессе глубокой работы растёт мастерство, и создаются значимые результаты.

➡️ Глубокая работа настолько важна, что имеет смысл планировать весь день вокруг неё (особенно учитывая, что много такой работы в день не сделать).

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

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

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

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

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

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

Книгу настоятельно рекомендую всем, кто в конце дня чувствует, что "занимался какой-то ерундой" или "опять ничего не сделал". Мне она помогла вернуть контроль над своим временем.

#обзор_книги
Как работать с отказами систем в BFF: основные паттерны отказоустойчивости

Появилась запись моего доклада "Как работать с отказами систем в BFF: основные паттерны отказоустойчивости", с которым я выступал на A?.Frontend Day.

В докладе я рассказал про следующие темы:
🔄 Как проекты проходят путь от монолитного API к BFF и каковы плюсы/минусы его внедрения.
🔄 Что может пойти не так в дивном мире распределённых систем? (Спойлер: вообще что угодно.)
🔄 Паттерн Timeout (он же Deadline) и его применение для ограничения времени выполнения запросов.
🔄 Паттерн Retry и его применение для сглаживания разовых/краткосрочных сбоев.
🔄 Паттерн Circuit Breaker и его применение для защиты сбоящего сервиса от перегрузки.
🔄 Плюсы, минусы и особенности каждого паттерна, а также их влияние на UX.
🔄 Примеры реализации вышеперечисленных паттернов на TypeScript.

Дополнительные материалы к докладу доступны по ссылке.

Приятного просмотра!

#публичные_выступления
Please open Telegram to view this post
VIEW IN TELEGRAM
Тимлид или чайка-менеджер? Управление без лишнего контроля

Знаете золотое правило инженеров? Работает — не трогай. Оно вполне применимо и для тимлидов: не стоит постоянно дёргать членов команды, если они заняты делом.

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

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

Что уж греха таить, я и сам страдал от чайка-менеджмента в начале своего управленческого пути. Мне казалось, что я делаю благое дело — постоянно нахожусь в курсе всех задач, всё контролирую, всё знаю и лихо жонглирую приоритетами. Спасибо моей дорогой команде, которая честно и откровенно рассказала мне, как же я их задолбал своим микро-контролем.

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

🔄 Всё хорошо, команда работает: "Ааа, я ничего не делаю, тимлид не нужен, меня уволят!"
🔄 Всё плохо, что-то идёт не так: "Ааа, всё пропало, меня уволят!"

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

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

Когда что-то идёт не так, то чаще всего нужно довериться своей команде и просто дать ей исправить ситуацию, расчищая для неё путь. Но чайка-менеджер так не может, поэтому он продолжает "летать и орать", нагнетая обстановку и усиливая стресс. Члены команды нервничают, совершают больше ошибок, устают. В итоге проблемы устраняются дольше, качество работы страдает, а настроение команды падает до нуля.

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

Что делать?

➡️ Учиться доверять людям и отпускать контроль. Для статус-чека у вас есть дейлики, где люди говорят о своих задачах и блокерах. Если к людям не приставать попусту, то они будут только благодарны.

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

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

➡️ Пользоваться услугами менторов и психотерапевтов, если совсем тревога не отпускает.

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

Сталкивались ли вы с чайка-менеджерами в своей жизни? Или, может, сами были чайкой?

Никита Ульшин про IT
Please open Telegram to view this post
VIEW IN TELEGRAM
🔖 Маршалл Розенберг, "Ненасильственное общение"

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

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

⭐️ О чём книга

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

В книге раскрываются следующие темы:
➡️ Что такое ненасильственное общение и чем оно отличается от обычного общения.
➡️ Какое общение мешает сопереживанию и эмпатии.
➡️ Наблюдение за другими без оценивания.
➡️ Принятие ответственности за свои чувства, их осознание и выражение.
➡️ Как здоровым образом выражать свои просьбы.
➡️ Эмпатия и её сила в общении.
➡️ Как конструктивно выражать гнев.
➡️ Разрешение конфликтов с применением ННО.

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

⭐️ Топ-3 вывода из книги

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

🟡Осуждение, оценки, сравнения и тому подобные вещи мешают установке контакта и сопереживанию между людьми.

🟡Каждый человек сам несёт ответственность за свои чувства, мысли и действия.

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

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

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

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

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

Читали книгу? Как вам?

Никита Ульшин про IT | #обзор_книги #менеджмент #soft_skills
Please open Telegram to view this post
VIEW IN TELEGRAM
Как я выжил при Иване Грозном. Гид для путешественников во времени

На одном из моих любимых исторических каналов "Файб" вышла просто невероятная по сложности и интересности работа - "Как я выжил при Иване Грозном".

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

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

Приятного просмотра!

Никита Ульшин про IT | #culture #history
Как говорить о техдолге с бизнесом

Техдолг — это не просто технические задачи, которые можно откладывать до лучших времен. Он охватывает кучу разных проблем: от устаревших библиотек и «спорных» архитектурных решений до сложного в поддержке кода и ручного тестирования. Как результат, техдолг рано или поздно затрагивает не только команду, но и бизнес. И объяснять необходимость работы над ним нужно так, чтобы бизнес видел, как это влияет на его показатели.

🔄 Почему техдолг вообще проблема?

Основные последствия техдолга — замедление разработки и ухудшение клиентского опыта. И пока код свежий, проблема не видна, но с ростом и усложнением проектов техдолг начинает мешать. Задачи делаются дольше, чем хотелось бы, планы меняются из-за необходимости «причесать» старый код или отложить нужные изменения из-за устаревших решений. Это тратит время, а значит, бизнес теряет возможности быстрее выводить продукт на рынок.

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

🔄 Как перевести техдолг на язык бизнеса?

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

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

🔄 Что важно помнить, разговаривая о техдолге

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

А как вы объясняете важность работы с техдолгом руководству?

Никита Ульшин про IT | #management #tech_debt
Please open Telegram to view this post
VIEW IN TELEGRAM
Как перестать беспокоиться и начать делегировать

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

Это нормально. Представьте вчерашнего технического специалиста, на которого внезапно свалилась огромная куча новых обязанностей: планирование, оценка, мотивация, переговоры. Первое, что обычно хочется делать в такой ситуации, — бегать по кругу и кричать: "Аааааа!"

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

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

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

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

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

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

🟡 Не забывайте благодарить и хвалить людей за проделанную работу и обратную связь. Это поможет им сохранять мотивацию для дальнейшей самостоятельной работы.

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

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

Никита Ульшин про IT | #management
Please open Telegram to view this post
VIEW IN TELEGRAM
2025/06/29 16:44:28
Back to Top
HTML Embed Code: