НГ праздники - время когда можно найти парковку на Патриках, да еще и бесплатно

С момента как мы сели на карантин прошло ровно 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 месяцев.

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