С момента как мы сели на карантин прошло ровно 2 года, но по ощущениям прошла вечность.

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

11го октября, ночью, произошло интересное событие, которое навело меня на некоторые размышления. Гильдия Frontier первая убила Лича на официальном сервере World of Warcraft в режиме hardcore.

Предыстория
Коротко о World of Warcraft в режиме hardcore. Я думаю, что все так или иначе играли в разные компьютерные игры - на ПК, на PlayStation, на телефоне, это не важно. Во всех играх есть возможность умереть и воскреснуть или загрузить прошлое сохранение, чтобы попробовать пройти сложный уровень еще раз. Обычно в играх всегда есть право на ошибку, а зачастую оно еще и имеет бесконечное количество повторений. Суть World of Warcraft в режиме hardcore в том, что права на ошибку нет, вообще нет, совсем нет. Если ты играл 1/2/3 месяца, прокачивая своего персонажа и получая какие-то вещи для его экипировки, то в случае его смерти ты теряешь все. Ты теряешь все эти месяцы игры, и тебе придется начинать заново, с чистого листа.

История
Интерес данной новости в том, что гильдия в 40 человек смогла за 1.5 месяца (сервера открылись в сентябре) убить всех боссов в игре и закрыть весь контент, практически не совершая ошибок, то есть не теряя своих участников. Повторяюсь - любая ошибка в режиме hardcore при походе на боссов в WOW ведет к смерти персонажа и полной потере всего, что ты, как игрок, нафармил за 1.5 месяца. Также стоит учесть, что в походе на боссов смерть одного члена рейда может привести к гибели всего рейда. Потеря одного члена может вызвать дисбаланс, который в свою очередь может привести к гибели всего рейда.

Размышления
Так как гильдия Frontier смогла этого достичь? На мой взгляд это:
-- постановка амбициозной цели
-- ультра высокий уровень работы в команде, в том числе доверия
-- невероятные навыки коммуникации их рейд-лидера

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

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

Кстати, одним из источников вдохновения при написании наших принципов была книга автора Рэя Далио - "Принципы". Советую прочитать ее.

Из внутреннего корпоративного мессенджера.

Культура не стоит на месте — она развивается и растет. Вот и у нас, как зернышко, вырос новый инженерный принцип.

📖📖📖 Предыстория 📖📖📖
У кого был или есть швейцарский нож? У меня был в детстве. Помню, как мой отец подарил его мне, сказав: "Вот теперь у тебя есть всё, что нужно для похода в лес". Нож, конечно, был крутым, но в 90% случаев я пользовался только его основным лезвием, а остальными инструментами - лишь изредка. Например, открывашка для пива была крайне полезной в те моменты, когда возникало желание что-то попить 🍻🍻🍻.

📋📋📋 История 📋📋📋
В работе инженера также, примерно 90% рабочего времени мы занимаемся своими основными задачами и обязанностями, но иногда приходится воспользоваться навыками, которые не являются основными и требуют дополнительного обучения или самообразования. Это нормально, это позволяет нам быть более самостоятельными и не обращаться за помощью вне команды, в рамках здравого смысла, конечно же.

Принцип «Швейцарского ножа»

Кто понимает разницу между кодером и разработчиком? Я для себя ее четко осознал, когда начал работать в Магнит и провел 100+ собеседований.

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

Разработчик
На другой стороне находится разработчик, который создает архитектуру, самостоятельно уточняет требования, пишет код с тестами, умеет в DevOps и следит за работой своего продукта (сервиса) в prod окружении. Мое почтение таким инженерам. Именно разработчики создает что-то новое, что-то выдающееся, именно разработчиков ждут в стартапах, где нет четких правил и понятного плана работ, именно разработчики могут заложить правильную инженерную культуру в компании. Однако, иногда они могут быть занозой в том самом месте, так как, как правило, обладают своей сильной точкой зрения, и если она не совпадает с вашей, могут возникать конфликты.

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

Интересные размышления по этогу вопросу есть в этой статье.

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

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

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

1. Теперь в Москве две улицы Мира. Что делать?
2. Теперь в городе две мэрии. Куда отправлять работать депутатов?
3. Что делать с мэром города, которого влили в Москву? По ходу оказалось, что он указами от правительства нафигачил объектов, которых нет ни в одном кадастровом реестре. Что делать с этими объектами?
4. Плитка в Красногорске была вертикальная, а стандарт в Москве - горизонтальная. Когда и главное, кем, всё нужно переложить?
И так далее.

Самое сложное в объединении инфраструктуры - это правильно объединить сети и общую адресацию. Обычно приходится вносить изменения в текущую инфраструктуру, чтобы не сломалось приложение. Сложность растет линейно с количеством инфраструктурных компонентов. У нас есть 160 микросервисов, а у КЕ уже насчитали 110. Так что это довольно большой кусок работы.

На прошлой неделе я побывал в гостях у ребят из завтракаст. Поговорили о PaaS, выборе языка разработки для backend, джунах и еще о многом другом. Например, cможете узнать как я чуть не бросил ВУЗ.

Видеозапись доступна по этой ссылке, а yandex подкаст по этой.

Какой у вас в компании freeze? code freeze? release freeze? feature release freeze?

Каждый год вокруг этого вопроса разгораются споры. Как внутри IT, так и между IT и бизнесом.

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

Хотя, у той же Apple бывают задержки при ревью в сторе в период рождественских праздников.

Несколько красивых графиков и чисел наших DORA-метрик.

Lead Time for Changes (LTFC) - весь Q3/Q4 активно работали над этим вопросом. Обнаружили множество проблем в наших процессах разработки и фиксили их. Одной из стандартных проблем являются большие Merge Request'ы, которые проходят через долгие этапы ревью, тестирования и интеграции. Это следствие плохой декомпозиции задач.

Deployment Frequency (DF) - у нас все в порядке, мы еще не достигли уровня elite, но все равно показатели не плохие.

Change Failure Rate (CFR) - исходя из стандарта, мы уже находимся в elite зоне, но нашей внутренней целью является снижение CFR до уровня не более 3%.

Кто не понимает, о чём вообще речь, бегите читать книгу "Accelerate".

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

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

На мой субъективный взгляд данный концерт 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 раз и навсегда решит эту задачу.