Про проверку СБ

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

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

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

Кстати, этот мой близкий знакомый в последствии основал одну из самых успешных онлайн-школ в России по обучению QA, а может и самую успешную.

Про ArchOps или, как я сегодня написал, 1424 строк архитектуры.

Помню, как лет пять назад первый раз услышал о возможности описывать инфраструктуру кодом, а спустя некоторое время DevOps-инженеры получили свой Terraform, и всё завертелось-закрутилось вокруг методологии GitOps (infrastructure as code).

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

Если вы ничего не поняли, вот топовая статья об этом, но я использую structurizr.

Пост скучания по MS Teams

Однажды коллега сказал мне: "Мы еще все пожалеем, когда потеряем Teams", и он оказался прав. Уже целый месяц я работаю без MS Teams и... о, ужас, как же я скучаю по нему.

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

Возможно, все это можно найти в других конфигурациях почты, мессенджеров, звонилок, например, Google+Slack+Zoom, но в MS Teams это все было доступно из коробки и работало очень удобно.

Пост об очевидности

Когда я учился в университете, у меня был преподаватель по физике, который часто говорил фразу "очевидно - когда очами видно". Он утверждал это, когда демонстрировал доказательство какой-либо формулы или теоремы. В конце, когда все было готово, а доказательство занимало 3-4 доски от края до края, и половина аудитории потеряла ход его мыслей уже на второй доске, он отходил в сторону, осматривал все взглядом, вздыхал и говорил: "Вот теперь очевидно, потому что очевидно - когда очами видно".

Сейчас, когда мне приходится сталкиваться с высоким уровнем неопределенности, непрозрачности, ограниченной информацией, я не могу сказать, насколько очевидным является решение, пока не визуализирую его где-то. Это может быть записная книжка, wiki, confluence, miro, drawio - не важно. Главное, что туда можно перенести свои или чужие мысли, визуализировать их и оценить их очевидность уже своими очами.

Пост про устойчивость.

Мой предыдущий руководитель в последний раз поставил мне цель на квартал - стать более устойчивым. Что означает устойчивость? По его словам, основные факторы устойчивости это:
- личные - в основном это семья;
- ИПР - наличие сильного руководителя, у которого есть чему учиться;
- наличие наставника;
- обратная связь с рынком (расширение сети контактов, участие в конференциях, ...).

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

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

Про монорепо vs полирепы

Что лучше микросервисы на базе монорепы или на база множестве репозиториев?

Я никогда не имел опыта работы разработчиком с монорепой, но слышал о таком подходе в Yandex/Facebook и еще ряде известных мест. Всегда этот рассказ или статья сопровождались каким-то набором дополнительного тулинга вокруг монорепы, который фактически ограничивает скоуп, с которым разработчику придется непосредственно вести работу. Один из аспектов, который мне точно нравится в монорепе, это возможность хранить техническую документацию, соглашения по разработке, API контракты, различные диаграммы взаимодействия и артефакты архитектуры непосредственно в самом монорепозитории. Я искренне верю, что чем ближе документация к коду, тем она более качественная, идеально когда она вообще генерируется из кода или наоборот.

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

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

Пост о маленьких победах каждый день

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

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

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

Из известных исследований на эту тему - это исследование Мартина Селигмана "The Effectiveness of Psychosocial Intervention for the Treatment of Unipolar Depression" в журнале "Journal of Abnormal Psychology" опубликованое в 1990 году. Один из выводов звучит примерно так:

Постепенное достижение маленьких успехов и поощрение позитивных результатов способствует формированию позитивной жизненной позиции у индивидуума.

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

Что такое senior инженер?

Несколько лет я наблюдаю тенденцию снижения уровня оценки senior инженера. Это проявляется в том, что кандидаты в возрасте 20-25 лет с опытом работы всего 2-3 года начинают самоопределять себя senior'ами. Конечно, возможно все, и если начать работать и писать код в, скажем, 16 лет, то к 20-25 годам действительно можно достичь уровня senior. Однако это скорее исключение из правил. Обычно видишь резюме с опытом работы всего 2-3 года, где кандидат сам оценивает себя как senior. Понятно, что сейчас рынок очень "голодный", и в свете оттока специалистов в период пандемии и после 2022 года общий уровень, по моему субъективному мнению, senior'ов существенно снизился. Раньше senior-инженер был таким "решалой" - сотрудником, который мог решить любую задачу без лишних вопросов, потребности в точном ТЗ/БТ, помощи от другого специалиста и т.д. и т.п. Ему можно было поручить задачу, забыть о ней, и вспомнить уже только тогда, когда он вернется с готовыми вариантами решения.

Как-то с бывшими коллегами из Магнит мы написали свое представление о senior инженере. Если интересно - welcome по ссылке.

"Люди, которые наиболее успешны в IT-индустрии, это те, кто приветствует перемены и готов признавать, что их знания устарели." - Стивен Хоффман, сооснователь LinkedIn

Может просто мои знания (понимание) о senior инженере устарели?

Последние две недели освежаю свои знания в подходах к построению организационной структуры.

Вопрос достаточно холиварный, или, как говорят в ЗЯ, лоливарный. Если объяснять на примерах, то есть две модели: модель Spotify и модель Avito. Я не утверждаю, что именно эти компании эти модели создали, просто их примеры самые яркие и имеют разные публичные документы и манифесты. Весь мой опыт до ЗЯ был, так или иначе, связан с моделью Avito и я был, и наверное все ещё являюсь, амбассадором этой модели при построении команд. Она мне кажется вполне логичной и, что более важно лично для меня, она крайне требовательна к роли тимлида команды. В ЗЯ модель построения команд похожа на Spotify. Для меня это с одной стороны тяжело, с другой стороны я чувствую, что получаю ответы на вопросы, на которые раньше не мог найти ответов. Понятно, что дьявол всегда кроется в деталях реализации и они у каждой компании свои, но тот факт, что в Spotify модели нет роли тимлида команды не даёт мне покоя.

Мне, как СТО, хочется опираться на руководителей, у которых за плечами есть большой инженерный опыт. В классической Spotify модели у продуктовых команд нет тимлидов. Как быть?

P.S.: как по мне, то роль тимлида отлично описана в https://tlroadmap.io/

Инженерная культура. Что это и почему она важна?

Уже в следующую пятницу в Питере, 12:40, «00 Зал Башня».

SaintTeamleadConf2024, это было круто.

Ходите в отпуск - точите свой топор!

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

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

Если лень читать, то вот выступление Дорофеева на HighLoad.

Пост про вторичность инструмента (нет)

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

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

Можно ли сказать, что инструмент первичен? Тоже нет. Я бы сказал, что инструмент не первичен и не вторичен. Выбор инструмента идет параллельно с постановкой цели. Возможно, надо определиться с некой этапностью, где этапом номер 0 будет стоять задача выбора правильного инструмента для достижения следующей цели. Иными словами, прежде чем начать копать яму, надо понять, чем и как вы будете ее копать: руками, лопатой, экскаватором.

Выложили запись моего доклада.

Про платформенные команды.

За 2 года, пока я был руководителем платформы в Магнит, у меня 3 раза менялось представление о том, чем должна и не должна заниматься платформа в большой компании. Понятно, что есть TeamTopologies, и в ней все написано, но, как часто бывает, применение каких-то академических знаний разбивается о суровые реалии конкретной компании и её процессов.

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

#playbook

Про парадокс opensource vs innersource.

На прошлом и текущем месте работы, да и на собственном опыте, заметил интересный парадокс. Как правило, все инженеры знают и понимают общую пользу и благо от практики opensource. Многие крупные проекты живут исключительно благодаря сообществу, которое готово принимать свежие идеи и новых людей. Я думаю, что многие из нас, может, и не контрибьютили в opensource, но очень хотели этого и были к этому готовы. Но почему же, когда речь идет про innersource внутри компании, то все переворачивается с ног на голову, начинается дележка "мое" vs "чужое" и т.д., и т.п. Даже когда идет речь про две команды, которые работают очень плотно друг с другом, речь про innersource встает в самый последний момент, когда других вариантов уже нет, а сделать очень надо. Откуда это? Почему написать код в чужом внешнем репозитории ментально проще, чем в соседнем репозитории соседней команды, с тимлидом которой ты ходишь ежедневно на обед?

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

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

Ностальгический пост о прошлом и мысли о будущем.

10 лет назад я, будучи обычным разработчиком, пришел в "Островок" делать backend для B2B-направления. Тогда еще особо никто не умел в скрам, а все просто писали код, роль тимлида только зарождалась, а в продукте шли споры о том, как правильно называть владельца продукта: Product Owner или Product Manager. Это были дикие времена, и мы выживали как могли.

Но было классно! Можно было просто подойти к кому угодно в офисе и что-то у него спросить. Можно было после работы пойти с командой в бар, а все встречи проходили в переговорках или рядом с чьим-то рабочим столом, и не нужно было беспокоиться о камере, качестве микрофона, шаринге экрана и актуализации своего календаря. Сейчас, после ковида и геополитических изменений, это звучит как какой-то "каменный век", но это был чертовски приятный "век". Никто не заботился о метриках эффективности, так как их никто не умел считать. Никто не думал об импортозамещении, так как не было повода и смысла об этом думать. Никто не спорил, какой корпоративный мессенджер лучше, потому что ни Slack, ни MS Teams еще не вышли в свет. Никто не ломал голову о выборе облачного провайдера, так как из нормальных был только AWS.

Что будет еще через 10 лет? Все перейдут с Jira на какой-нибудь TeamStorm? gitverse заменит GitHub? А backend будем писать на Rust? Или же профессия разработчика вообще умрет и останутся операторы AI? Поглядим!

Кстати, частично эту тему затронули на последнем TechLeadConf в рамках доклада Как техлиду выжать максимум из ChatGPT.

Пост размышления о лидерстве.

Лидерство — это когда где-то внутри есть большое НАДО и яркое ХОЧУ.

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

Пример.
Я знаю, что мне сейчас НАДО инвестировать своё время в подготовку к высокому сезону. Моё НАДО говорит мне: «Антон, иди разберись, как обстоят дела в командах по подготовке к сезону, проверь, что все всё сделали. Проконтролируй! Проверь! Помикроменеджь!»
При этом есть ХОЧУ. ХОЧУ хочет, чтобы я выстраивал культуру, процессы и роли в командах, чтобы достичь такого уровня зрелости и осознанности, при котором о подготовке к сезону не нужно было бы говорить, чтобы это было базовой гигиеной.

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

P.S.: данный пост написан под влиянием яркого ХОЧУ =)

Возвращаюсь к истокам данного канала.

вот же пи....

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

Не потому что мне было лень это изучать, я просто искренне не понимал, зачем нужны все эти rebase, revoke и прочие непонятные команды, когда фактически все, что мне нужно, это:
- git checkout -b
- git push
- git pull
- влить изменения (merge в интерфейсе gitlab)

Крайне-крайне редко я мог воспользоваться cherry-pick и diff/apply.

Всё. Я никогда не понимал, зачем нужны dev-ветки, если всё, что мне нужно, — это отвести ветку от master, а потом вмержить её в master.

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

На последнем TLConf был, на мой взгляд, эталонный доклад про TBD. Ничего аналогичного на просторах Рунета в видеоформате нет. Автору респект. Максимально рекомендую всем!

P.S.: этот доклад получил самую высокую оценку среди докладов ветки TechLead

Пост про использование консоли.

Я четко помню тот момент, когда я, еще будучи в вузе, перешел с Windows на Ubuntu. Момент я помню, но что послужило причиной этому - уже нет. То ли потому, что мне надо было что-то запускать из-под Unix, то ли просто потому, что все окружение вокруг работало под Unix-системами. Не суть. Суть в том, что я четко помню тот восторг, который я ощутил, когда смог пользоваться нормальной консолью. А tiling window manager типа awesome, ммм, сказка. Конечно, уже потом я перешел на Mac, так как консоль - это, конечно, хорошо, но вот собирать драйвера и разбираться с прочими приколами дистрибутивов Linux желания не было.

К чему это я? К тому, что удивлен, насколько современное молодое поколение разработчиков то ли не умеет пользоваться консолью, то ли она им просто не нужна. Вокруг одни интерфейсы типа продуктов JetBrains, а я как дурачок радуюсь тому, что открыл для себя консоль нового поколения Warp, которая собрала в себе уже из коробки все нужные мне плагины.

Раньше, при собеседовании разработчиков, я приятно удивлялся, что оставались еще те, кто умеет работать с vim. Видимо, через какое-то время можно будет удивляться тем, кто все еще умеет в grep / awk / cat в командной строке.

Кстати. Как выйти из vim? =)