Хочу поделиться одним интересным примером, где "копирование не воровство" вышло на какой-то невероятный для меня уровень.

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

На мой субъективный взгляд данный концерт HYBRID THEORY Live @ Altice Arena 2023 (Full Show), в чем-то лучше чем оригинальные концерты, думаю что всем поклонникам linkinpark и nu-metal будет крайне интересно.

В общей сложности я писал на Python более 12 лет. Начинал я еще с Python 2.5, когда учился в вузе, а закончил уже на Python 3.10 в Magnit. Как Python-программист, я прошел через ряд классических задач, актуальных в 2010-х годов. Я полностью ощутил все сложности миграции большого Django-проекта с Python 2.7 на Python 3.5, внедрял MyPy на большом легаси-проекте, переписывал проект с синхронного кода на асинхронный. Не могу сказать, что у меня были высокие теоретические знания Python на тот момент, но как практик я мог реализовать любой коммерческий проект.

Мне довелось использовать множество популярных и не очень библиотек и фреймворков: Eventlet/Greenlet, Flask, Django, Starlette, FastAPI. Однако со временем, когда я уже работал в ostrovok.ru, мне пришлось начать писать немного на Golang. Не могу сказать, что Golang сразу же мне понравился, но мне очень понравился подход к обработке ошибок. Я настолько им проникся, что стал применять такой же подход к обработке ошибок на Python, то есть без использования исключений.

Как руководитель разработки в Magnit, я использовал свой административный ресурс, чтобы инвестировать свое время и время своих разработчиков в python-тулинг для backend разработки. Я понимал, что Python никогда не будет на одном уровне с Golang по производительности, но я верил, что огромное сообщество Python сможет предложить что-то, чтобы Python оставался хорошим выбором для backend разработки. Отличным примером работы сообщества стало появления pydantic и его последующее развитие в pydantic2. Я рассказывал о нашем опыте миграции на pydantic2 на Moscow Python Podcast.

Зачем я это все рассказываю? Мы, Magnit Online, начиная с первого квартала 2024 года, больше не пишем новые сервисы на Python для обработки пользовательских запросов с мобилки и веба, используем только Golang.

P.S.: Хочется верить, что производительность Python позитивно изменится после реализации subinterpreters, которые обещали представить в Python 3.13/Python 3.14.

Пост об удобстве.

Трехточечный ремень безопасности, изобретенный Нильсом Болином, впервые был применен в автомобиле Volvo PV 544 в 1959 году. В дальнейшем он стал широко использоваться в автомобилях, внесший значительный вклад в повышение безопасности на дорогах. Прежние типы ремней безопасности, такие как двухточечные или поясные, не были так удобными для пассажиров, поэтому трехточечный ремень считался более комфортным и эффективным средством предотвращения серьезных травм и снижения смертности при авариях.

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

Аналогично и в IT, все то, что неудобно или доставляет какой-то дискомфорт нам, как инженерам, или нашим клиентам, не проходит проверку временем и умирает. Помните телефоны с изогнутыми дисплеями от Samsung? Классная идея, верно? Но где они сейчас? Из-за высокой вероятности случайного нажатия на краях, их использование было крайне неудобным. А Touch Bar от Apple в MacBook помните? Я пишу данный текст как раз с такого MacBook и за 3 года владения ни разу не пользовался этой полоской.

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

У меня есть дети: одному 3 года, а второму - 8 лет. Иногда они говорят мне: "Папа, это нечестно". Это происходит по разным причинам - когда кому-то не хватает какой-то вкусняшки или когда речь идет о просмотре мультиков. В общем, причин много.

В прошлом году я прочитал книгу "45 татуировок менеджера". Книга не сильно связана с ИТ, но мысли из нее можно использовать в работе тимлида или СТО. Одна из ее татуировок гласит: "Справедливости не существует".

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

Алексей, RIP.

Вчера основателю лучшего банка в РФ был присвоен статус иногента. Я являюсь клиентом данного банка уже более 10 лет, и я еще помню времена, когда Тинькофф банк боролся за лучший клиентский сервис в онлайне с Рокетбанком.

Лично для меня господин Т. - это пример предпринимателя с большой буквы, с ним может посоперничать лишь какой-нибудь Галицкий. Да, сама его личность вызывает спорные мнения, но мы должны быть ему бесконечно благодарны за его вклад в развитие FinTech в России. Сейчас часто говорят, что банковские услуги в РФ опережают своим уровнем услуги в Европе или США на десятки шагов, это в первую очередь заслуга Олега.

Про performance review

Недавно услышал термин performance driven development. Это, когда сотрудники компании, где проводится периодический performance review, меняют свой подход к работе - с фокуса на достижение конечного результата на фокус получения высокой оценки во время review. Да, может случиться так, что высокая оценка в review может противоречить конечному результату.

История. Шел четвертый квартал 202x года: день холостяка, black friday, cyber monday, и тому подобные распродажи. В какой-то момент мобильное приложение, за которое я тогда отвечал, стало значительно медленнее работать. Экраны загружались медленно, и казалось, что проблема где-то в бэкэнде. Однако, метрики мобильного гейтвея оставались в пределах разумного - 200-500 мс на уровне 95-й перцентили. Спустя некоторое время выяснилось, что проблема заключалась в WAF, который стоял перед мобильным гейтвеем и пропускал через себя весь трафик. При резком скачке трафика нагрузка CPU на WAF была под 100%, что приводило к обработке всех запросов с задержкой до 3 секунд. Я принял решение и взял на себя ответственность направить трафик напрямую в наш мобильный гейтвей, те мимо WAF. И о чудо, проблема пропала. Наш CPO тогда сказал мне: "Антоха, приложение просто летает!".

Спас ли я тогда наши KPI от краха? 100%. Получил ли я потом за такое от ИБ по "шее"? Да. Думаю, что если бы у нас тогда был performance review, я бы не получил высокую оценку.

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

Очень субъективный пост о мотивации

Ради чего мы все работаем в IT? Ради славы? Власти? Признания? Денег?

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

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

Ура! Утвердили мою тему на TLConf 2024 в Питере.

О чем буду рассказывать

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

Смены работы пост

Самое продолжительное место моей работы была компания Ostrovok, где я проработал 5 лет. Пришел я в Ostrovok на роль Python разработчика, а увольнялся с должности руководителя разработки B2B-продукта. У меня были свои причины для увольнения, но сейчас это не так важно. Главное, что после смены работы мне было очень трудно влиться в новый коллектив. Все казалось неправильным, неоптимизированным, неэффективным и нелогичным. Позже я понял, что это были ложные мысли, потому что я пытался применить свой предыдущий опыт к новому месту работы, что, как минимум, было неправильным из-за различных предметных областей, а, как максимум, вредно, потому что не все практики Ostrovok были полезными. Например, нельзя приходить в MedTech c идеологией стартапа и принципом fail fast.

Со временем я осознал, что длительное время работать на одном месте без радикальных изменений, таких как смена должности или изменение бизнеса, негативно влияет как на меня самого, так и на компанию. Например, для разработчика я считаю вредным работать на одной должности в одной компании в течение ~10 лет, потому что твой кругозор будет ограничен кругом общения и контекстом, который окружает тебя в рамках только одного места работы. С другой стороны, я не люблю "джамперов", то есть кандидатов, которые меняют места работы каждые 6-9 месяцев.

Как часто надо менять работу? Ваши мысли.

Про важность стандартов и шаблонов

Практически все крупные автоконцерны перешли на производство автомобилей на базе автомобильных платформ. Ярким примером является MQB платформа от VW Group. На базе MQB VW Group выпустило около 40 автомобилей брендов VW/Audi/Skoda/Seat. В чем суть? Модульная платформа позволяет легко и быстро изменять колесную базу и ширину колеи автомобилей, а также адаптировать конвейер завода под выпуск моделей разных классов.

А что у нас в IT? Шаблоны CI/CD, шаблоны для запуска микросервисов, стандартизация метрик/логов/трейсов, дизайн системы, микрофронты, модуляризация мобильных приложений: все это проявления в той или иной степени платформизации. Все крупные IT-игроки уже поняли, что лучше один раз вложиться в свою платформу и потом выпускать новые продукты на базе перечисленных выше инструментов. Индустрия движется к стандартам и шаблонам, чтобы уменьшить (сделать быстрее) TTM и сократить TCO. Хороший свежий пример - это OpenTelemetry. Где бы я ни работал, везде инженеры изобретали свой стандарт по тому, как писать логи, собирать метрики и строить трейсы. Часто было так, что разные команды внутри одной компании делали эти вещи по-разному, и потом пытались соединить "ежа с ужом". Сам таким занимался. Надеюсь, что OpenTelemetry раз и навсегда решит эту задачу.

Пост про требовательность

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

Вводная Б
Одзиги – уникальное проявление японской вежливости: приветствие, прощание, поздравление, благодарность, извинения. Правильно и красиво поклониться – не так-то просто, это настоящее искусство, показатель хорошего воспитания, благородства. Высшая, а фактически, низшая форма уважения – сайкэйрэй (最敬礼) – «самый почтительный поклон». Его делают, опускаясь на колени и почти касаясь лбом пола.

Резюме
Если вы как руководитель не держите высокую планку требовательности к самому себе, то либо признайте это совершив условный сейкэйрэй, либо покиньте свой пост.

Субьективное мнение о важности личного бренда в IT.

Когда я учился в Бауманке, где-то на 4-м курсе, у нас был предмет, суть которого заключалась в том, чтобы научиться совместно с одногруппниками работать над общим проектом, как если бы мы работали над ним в коммерческой компании. Надо было использовать все инструменты для командной работы: таск-трекер, систему контроля версий и т.д. Этот предмет вел бывший выпускник Бауманки (далее Господин Н), который основал свою компанию и занимался коммерческой разработкой под заказ. Он на своем примере понимал, что студенты оканчивают ВУЗ и не понимают, как работать над проектом совместно в команде. Это был первый раз, когда я задумался о личном бренде.

Пару лет спустя, когда я закончил ВУЗ, попал на какую-то конференцию, кажется, это был Highload, где Господин Н рассказывал что-то про нагрузку в одном из его проектов. Про нагрузку тогда только начинали говорить, и его выступление было крайне актуальным. Это был второй раз, когда я задумался о личном бренде.

Ближе к концу 201x года, когда стали регулярно проходить TeamLeadConf, TechLeadConf и прочие хххLeadConf, Господин Н выступал там регулярно, и все его доклады всегда были на острие. Это был третий раз, когда я задумался о личном бренде.

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

Кстати, Господин Н - это CTO ivi.ru

На этой неделе проходит Podlodka TeamLead Crew #12, тема «Метрики».

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

В итоге мне понравилось, слушателям вроде бы тоже.

Саморефлексия на тему того, почему я до сих пор живу и работаю в РФ.

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

Почему же я остался? Копаясь глубоко внутри себя, понял, что основная причина крайне проста - это лень.

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

Плохо ли это? Непонятно. Стыдно ли мне за это? Точно нет. Каждому свое.

Пока Магнит 🧲, здравствуй Золотое Яблоко 🍏

Завтра, 12 апреля, у меня последний рабочий день в Магнит, а уже в понедельник, 15 апреля, я выхожу на роль СТО Ecom в Золотое Яблоко.

Мой путь от роли backend разработчика до роли СТО был крайне последовательным: 6 лет в разработке, 5 лет в тимлидстве, 3 года в роли руководителя отдела. Пора двигаться дальше, пора выйти из зоны комфорта и погрузиться во что-то новое.

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

Про networking

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

История 2. Когда я покидал ostrovok, я проходил собеседования в разные компании, одной из которых был банк Тинькофф. В банк я не пошел, но пошел в SoftPro, где меня собеседовал тот же человек, что и в Тинькофф.

История 3. Когда я уходил из SoftPro, я проходил собеседования в разные компании, одной из которых был DeliveryClub. С DeliveryClub у меня не сложилось, так как на позицию, на которую я претендовал, впоследствии был выбран внутренний кандидат, который спустя 3 года стал моим коллегой в Магнит.

Вывод - networking наше все.

Когда-то я был разработчиком и писал много кода.

Для саморефлекции использовал сервис wakatime, который показывает сколько, в каком проекте и на каком языке я в этот день писал код. Полезно и приятно, рекомендую, встраивается в любую IDE.

Жалко, что ничего подобного нет для самоанализа cвоей активности в confluence/jira/miro/почте. Или есть?

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

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

Когда-то давно в Магните я хотел нанять своего близкого знакомого, с которым ранее работал в 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 - не важно. Главное, что туда можно перенести свои или чужие мысли, визуализировать их и оценить их очевидность уже своими очами.