Ворчливый IT-дед

Про олимпиадное программирование

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

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

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

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

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

Кстати, до 29 октября открыта регистрация на международный чемпионат по программированию Yandex Cup. Финал впервые пройдёт в Стамбуле — 5–7 декабря, соберёт 180 лучших участников. Два международных трека: к традиционным алгоритмам добавилось машинное обучение. Доступно 6 направлений: аналитика, фронтенд, бэкенд, мобильная разработка, ML и спортивное программирование («Алгоритм»). Лучшие участники смогут пройти собеседование в Яндексе по упрощённой схеме. Подробности тут - https://yandex.ru/cup/. Если вы любите и умеете в олимпиадное программирование, или просто любопытно поучаствовать - пропускать нельзя.

Первый пункт плана ...

... - составить план (done). Это понедельничная рубрика #лёха_строит_бэху, и за эти выходные мы успели следующее:
- Примерить рабочие комбинезоны (у сына - картинговый, потому что детский рабочий комбез я найти не смог).
- Распаковать покупки - домкрат, подставки, лежаки, динамометрические ключи, свет и многое другое.
- Выяснить, что пока решительно непонятно, как использовать рампы на гладком полу паркинга - при попытке въехать они вылетают из-под машины.
- Провести диагностический осмотр машины, чтобы на его основе начать составлять план действий.
- Наклеить на дверь кладовки маркерную пленку и зафиксировать на ней тот самый план.
- Демонтировать колхозные будильники показателей смесеобразования и вольтажа со стойки крыши.
- Демонтировать нештатный фаркоп и насадку на глушитель.
- Записаться в гаи на постановку на учет, сделать страховку и диагностическую карту.
- Вытащить из-за спинки заднего дивана ремни безопасности, которыми в этой машине явно никто не пользовался.
И еще по мелочи. Пока ничего не понятно, но очень интересно. Хотя нет, понятно, что работы там - мама дорогая! Результатов пока немного, но база есть - на следующих выходных будет чем заняться более предметно. А что именно мы будем делать - узнаем через неделю. Stay tuned.

Превозмогаем

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

Воспитатели воспитателей

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

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

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

Руководитель отдела, в свою очередь, работает чиновником в департаменте дошкольного образования. Тут работа уже совсем другая. Тут важно выстраивать целостность системы, контролировать методологическую составляющую, решать вопросы уровня города, назначать толковых заведующих. И не надо лезть к детям! Хотя самому понимать в педагогике, все же, обязательно.

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

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

Пирамида потребностей вашего сервиса

Несколько дней назад на одной из встреч коллега Андрей говорил о стратегии своего направления. Одна мысль мне так зашла, что не могу ей не поделиться. В целом, идея не нова, но для кого-то может стать eye-opening.

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

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

Следующий слой - стабильность и масштабируемость. Если система частенько рушится, или вы не знаете как вывезти рост х2 - руки прочь от всяких свистелок и бантиков! Иначе у вас будет стабильно не работающая по пятницам свистелка с бантиком, которая показывает время лишь через раз, и то неправильное.

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

И лишь когда у вас уже все хорошо, можно переходить к более развесистому ML/AI (в том числе в процессах) - в наших часах это будет голосовой аи-помощник и фитнес-трекинг.

А еще важно, чтобы пользователи вашего сервиса тоже помнили его основное предназначение. В воскресенье были с коллегами на ивенте, и Рома забыл телефон в машине. А без телефона он даже время не мог посмотреть, чтобы понять, сколько осталось до начала ивента. Впрочем, через пару вопросов к нам "сколько времени?" он все же вспомнил, что часы на его руке еще и время показывают, даже без синка с телефоном в кармане.

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

Новая глава

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

В связи с этим был приобретен учебно-тренировочный кадавр в лице BMW 3er E30 1984 года выпуска на трамблерном M20B20 с ле-джетроником. Теперь мы можем по выходным на паркинге с ним ковыряться. Цель - сделать к лету конфетку. Хотя, цель тут - не главное, главное - процесс. Буду рассказывать сыну, как оно устроено, на практике. Будем учиться крутить гайки, чинить, улучшать, разбирать и собирать.

Почему E30? Во-первых, это красиво. Выдержанный признанный янгтаймер в классическом строгом стиле не оставляет равнодушным никого вокруг. Ну как минимум в хорошем состоянии, а это уже - наша забота. Во-вторых, максимальная ремонтопригодность. Купить машину и загнать ее в сервак на полгода - не интересно, а ковырять более современные машины в домашних условиях - дохлый номер. Мы даже отмели вариант с 2.5-мотором, потому что с ним подкапотка очень тесная, не подлезть.

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

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

#лёха_строит_бэху

Новый виток истории

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

И вот на днях я узнаю, что один знакомый топ-менеджер пересел со своего зикра на порше 911. А что случилось?)) Неужели с зикром что-то не так? Конечно, в разговоре на парковке он уверял, что просто нужно было отдать более практичный зикр жене, и все с ним хорошо, и он ему все еще нравится, просто поддался нашему давлению в сторону более железных машин. Но мы-то все понимаем. Мужчинский поступок, все правильно сделал.

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

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

Why so serious?

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

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

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

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

Цените своих коллег, дорожите отношениями, общайтесь свободно. Тогда и работа будет легче работаться.

Больше пикселей!

Обновился тут до ios26. Весь этот стеклянный дизайн, конечно, полная шляпа. Зато картинка стала намного более четкая, резкая, красочная! Как будто пикселей прибавилось. Аж глаза режет. Тексты стали контрастнее, графика четче. Как они этого добились чисто программно?

Хотя, возможно, дело в том, что через несколько часов после обновления я сделал лазерную коррекцию зрения. Штука, кстати, классная, и не такая страшная и ужасная, как многие думают. Рекомендую. Если вы давно ждали знак, чтобы решиться - считайте, что это он. А я теперь вижу больше деталей, на которые можно поворчать.

Все, что нужно знать о поиске через чатгпт

Подбирали с коллегой вариант для командообразующего выезда на природу.
Он, по привычке, доверился чатгпт. А я не перепроверил.
Дабл-чекайте все за ллмками! А то они бог знает куда вас заведут.

Продам Mazda MX-5

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

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

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

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

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

Немного скучных ТТХ:
Mazda MX-5 ND soft-top 2019, пробег 36 000.
Куплена мной в апреле, я наездил 2500км и 1 трек-день.
Покупал ее свежеобслуженной, и сам даже ни разу не ездил в сервис, не было повода.
Состояние - околоидеальное (повторюсь - диагностику не делал, но сам неисправностей никаких в ней не вижу).
Мотор 2.0л, 184 л.с., МКПП шестиступка.
Салон - двухместный, я с ростом 192см нормально сижу. Багажник - ну, он есть.
Привезена пару лет назад из Германии (не американский биток!).
Два комплекта резины (летняя - держаковая адван спорт с пробегом 1 сезон, зимняя - ну, она есть).

Цена - 3.3млн (на сколько взял, за столько же и отдам).
Посмотреть можно в БЦ Нева (Сити) или в Хорошёво-Мнёвниках. Пишите в личку @jkennedy

Найм зумеров в эпоху вайб-кодинга

Разгоняли тут с Женей Кадомец про трудности найма в наше неспокойное время перегретого рынка, необоснованных зарплатных ожиданий и злоупотребления ИИшкой.
(https://t.me/jeny_ka - подпишитесь! Там про рекрутмент, карьеру, тренды и котиков)
Женя была рекрутером моей команды уже почти 10 лет назад (страшно подумать), а сейчас она руководит рекрутментом в Финтехе Яндекса.

Решили тут с ней посмотреть с разных сторон на один вопрос.
Я - со стороны нанимающего менеджера, Женя - со стороны рекрутмента.
Моя точка зрения, конечно, важнее ;) Ей-то надо лишь найти человека, а мне с ним еще годами работать.

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

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

Раньше, без гпт, да к тому же на очных собесах с написанием кода на листочке, было сразу понятно, что человек может. Но я не хочу нанимать того, кто без гпт ничего не может. И пусть он потом в работе этот гпт использует в хвост и в гриву (лишь бы не в ущерб качеству), но важно, чтобы он и без гпт мог все то же самое.

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

Я считаю, что искать нужно в первую очередь мотивированных инженеров. Тех, для кого программирование - не только способ заработка, но и страсть. Тех, кто получает удовольствие от процесса, а не только по 5-м и 20-м. Кто любит технологии и готов много учиться. Кому интересно развивать инструменты, а не просто использовать их.

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

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

Надежность: импакт

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

В предыдущих сериях:
- повышение надежности релизов
- предотвращение инцидентов из-за потенциально известных проблем
- реагирование

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

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

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

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

Ну и, наконец, упомяну всевозможные "тыквы" - режимы продуктовой или технической деградации, которые активируются в случае проблем, и позволяют сохранить хотя бы какую-то работоспособность (или даже видимость работоспособности) сервиса. Грубо говоря, если в выдаче Еды будут не все сотни/тысячи ресторанов, которые штатно могут привезти вам покушать, а хотя бы 50 более-менее высоко-ранжируемых, почти никто ничего не заметит. А половина аудитории останется сыта и довольна, если хотя бы показать мак и тануки. Какие именно режимы деградации реализовать, зависит исключительно от вашей фантазии (и одобрения от продукта и бизнеса). Но чаще всего лучше работать как-то, чем никак.

Вывод - купируйтесь и деградируйте. Хотя странно звучит, забейте.

big tech night

Кстати, сегодня конфа big tech night. Программа довольно интересная.

Там и онлайн будет https://bigtechnight.ru/online/ - если не попали на оффлайн. Если еще не решили, чем занять вечер пятницы - вариант.

Кто будет в Красной Розе - при желании можем увидеться, я буду там нетворкаться где-то в районе стенда Городских Сервисов Яндекса.

Лидеры компетенций

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

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

Далее мы трансформируем команды. Теперь в каждой группе есть, например, 2 бекендера, 1 ios-разработчик, 1 андроид, 1 веб, 1 куа. И тимлид. Предположим, тимлид в прошлом - бекендер. Возникает вопрос - а как он может быть техническим наставникам тем четверым, чьих профессий у него в анамнезе нет? Кто будет технически развивать этих ребят? Как он будет оценивать их работу? Кто поревьювит самый сложный пулл-реквест?

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

Что же именно делают лидеры компетенций?
- работают с подопечными 1 на 1 и помогают им расти и развиваться профессионально
- участвуют в найме и оценке сотрудников на перформанс-ревью
- ставят и ведут техноцели, распределяют их на подопечных, развивают архитектуру, внедряют новое
- реализуют принципы technical excellence в своей зоне ответственности
- обеспечивают обмен знаниями по платформе и продукту
и многое другое.

Для пущей структурности и организованности есть также некоторая иерархия - существуют шеф-лиды компетенций (chief competence lead, CSL), по одному на каждую функцию. Они консолидируют экспертизу и ведут комплексные, сквозные проекты. Координируют лидеров компетенций разных частей компании. Формируют повестку и направляют стратегию технологического развития своей функции. В общем, главные по своим областям.

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

Буткемп, или как не толкаться локтями при найме

Предположим, есть 5 смежных команд. И в каждой есть вакансия C++-разработчика (или ios/android/web/qa - не суть, лишь бы одинаковые). Команды в целом схожи, просто за разные части системы отвечают. А значит, требования к кандидатам у них тоже плюс-минус одинаковые - стек, опыт, профиль.

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

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

Найм ведет какой-то один НМ (достаточно опытный и взрослый) при содействии лидеров соответствующих компетенций (о том, что это за зверь - расскажу отдельно). Мы предлагаем кандидату просто прийти в Еду, и за первые пару месяцев поработать по паре недель в нескольких командах (3-4, команды в графике ротируются для равномерности получения буткемперов). За это время новичок точно сможет понять, в какой команде ему больше понравилось. А команды смогут понять, где у кандидата лучше пошел процесс. Где больше фит.

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

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

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

Можете сделать так же у себя. А можете попробовать у нас - https://yandex.ru/jobs/services/eda или пишите в предложку (или личку @jkennedy)

Игра с ненулевой суммой

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

Простой пример: вам предлагают подбросить монетку. Орел - вам дают 2000 рублей. Решка - у вас забирают 1000. Вроде бы, статистически, надо играть. Но перспектива расстаться с тысячей рублей как-то не радует, и вы, скорее всего, откажетесь. Дело в неприятии потерь - мы склонны интуитивно увеличивать вес потерь относительно выгоды.

Однако, если предложить вам 20 раз подряд сыграть в эту игру, вы наверняка согласитесь. Потому что вероятность остаться в минусе сокращается до морально-приемлемых ~13%, что перекрывается средним ожидаемым выигрышем в 10 000 рублей. Хотя броски монетки независимы, и каждая итерация игры осталась та же. Но вы расширили рамки и оперируете рисками в более широких рамках.

Так же и с инвестициями в ценные бумаги - если заглядывать в котировки каждый день, вы будете расстраиваться от мелких просадок, а умеренному росту будете радоваться меньше. И будет больше зуда перетряхнуть свой портфель. А если открывать брокера пореже - колебания сгладятся и вы будете видеть более объективную картину.

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

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

Не нужно обдумывать каждое решение как единственное - расширяйте рамки и оперируйте портфелем в целом и на дистанции.

(Не является инвестиционной рекомендацией. Автор не поощряет азартные игры. Мотивационный питч, направленный на построение аналогий с принятием профессиональных или бытовых решений. Инспирировано книгой Даниэля Канемана.)

Надежность: реагирование

Продолжаем разбор стратегии надежности .
Ранее уже писал про
повышение надежности релизов и про
предотвращение инцидентов из-за потенциально известных проблем.

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

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

А не надо так. Привычное игнорирование некритичных алертов приводит к слепоте - вы не отличите крит от не-крита. Уже горящий алерт ярче не загорится, если системе станет реально хуже. Замьюченный - тем более. Вы летите без приборов и узнаете об инциденте из газет. Поэтому нужно держать высокий alerts uptime (доля времени, когда не горит ни один алерт, должна приближаться к желаемому аптайму системы в целом - 99.??). А еще полезно визуализировать это в виде полотна с плитками, где каждый не-зеленый кусочек должен вас искренне триггерить. Некритичные алерты нужно перенаправить куда-то в отдельный диагностический канал, а реально критичные - настроить так, чтобы их невозможно было не заметить.

Аналогия из автомобильного мира - лампочка check-engine (она же джеки-чан, она же мясорубка). Не понимаю людей, которые ездят с ней годами. Даже если зажглась она из-за ерунды, вы пропустите индикацию реально важной поломки. А заклеивают чек только перекупы. Я же на некоторых авто каждое утро начинал с подключения обд-сканера (elm) и сброса некритичных ошибок.

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

И про клиенты. У вас было такое, что по сигналам бекенда все хорошо, а фича не работает? Либо бек отдает 200 OK с пустым телом, либо схема ответа не соответствует контракту, причин масса. А приложению что-то не нравится. Тут главное - чтобы на клиенте это была не одна ошибка вида "ой, что-то пошло не так", а что-то осмысленное, с отправкой метрик и алертингом на них. Также стоит следить не только за синтаксическими, но и за семантическими ошибками. Например, синтаксически корректная, но пустая выдача - тоже сигнал.

Здоровья вашим сервисам, а если что-то все же бомбанет - не проморгайте. И не слепните.

55.973146, 37.414863: Как починить "перебрасывание" геопозиции в iOS без регистрации и смс

Жители крупных городов России в последнее время частенько страдают от "перебрасывания" геопозиции в различных приложениях. Например, в Шереметьево. Это сильно мешает - навигатор бессилен, погоду ты видишь в Химках, даже еду заказать сложнее.

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

Достаточно лишь
.
.
.
поехать в Шереметьево. (фьюить-ха!)

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

Зато на гарантии

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

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

Во-вторых, оказалось, что бампер на заводе был собран неправильно. Пересобрали по гарантии - ура!

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

И самый кек. Я, как известный душнила, проинструктировал друга, что нужно проверять во время приемки (15 пунктов контроля), включая толщину лако-красочного покрытия. Известны случаи, когда авто при логистике повреждали, покоцанную деталь красили, и выдавали новый авто со вторичным окрасом. Одолжил ему свой толщиномер. Друг вернулся в замешательстве - вся машина покрашена нормально (120-150 мкм), а одно крыло - под 300! Налицо вторичный окрас. Пошел он с продавцом по парковке смотреть другие экземпляры. И вы не поверите - у всех машин этой модели переднее левое крыло бьется в 300 микрон. Это вообще как? Науке сие пока неизвестно. Китайские нано-технологии, не иначе.

Мораль. Гарантия - хорошо. Повод ей воспользоваться - уже не очень хорошо. Китайский автопром - совсем плохо.

Надежность: предотвращение инцидентов из-за потенциально известных проблем

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

Инциденты неизбежно случаются. Но нет ничего хуже, чем наступить на те же грабли. Поэтому каждый инцидент проходит процедуру разбора и выявления экшн-айтемов. Но их еще надо сделать. И чем раньше - тем меньше вероятность рецидива. Поэтому мы постепенно сокращаем SLA на выполнение экшн-айтемов. Тут важно не пережестить - не нужно вешать SLA на всевозможные nice-to-have идеи по мотивам. Только на задачи, "в лоб" предотвращающие повторное падение, или драматически снижающие импакт от оного.

А еще иногда бывают первые звоночки перед инцидентом. Точечная жалоба пользователя, попавшего в эксперимент. Багрепорт уровня блокер из релиза, который только начал раскатку в сторах. Обращение коллеги, который открывает приложение каждые 10 минут. Если на них не обращать внимание, можно упустить ситуацию. Поэтому соблюдение SLA на обработку обращений тоже в ряде случаев помогает заметить инцидент на ранней стадии и купировать эффект.

Очень важно регулярно проводить разного рода учения. Например, по имитации потери одного из дата-центров. Это поможет в условиях сохранения контроля найти те проблемы, которые нас похоронят в случае реальной потери ДЦ. И речь не только о запасе прочности - само изменение топологии может вызвать "бум" - от автофейловера БД до metastable failure.

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

Архитектурное ревью

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

Это список из ~30 вопросов, на которые должен ответить автор изменений, чтобы убедиться, что он не забыл подумать про важные аспекты проектирования. Какую задачу решает сервис? Почему нельзя обойтись имеющимися? Альтернативы. Сиквенс-диаграмма взаимодействия. Отказоустойчивость, масштабируемость, точки отказа, фолбеки, план внедрения, хранилище, схема данных, периодики, ожидаемая нагрузка - вот лишь часть аспектов, которые нужно осветить в rfc. Потому что если про что-то из этого не подумать, с большой вероятностью случится "ой".

Если хотите послушать про архревью подробнее, приходите на ArchDays или HighLoad++ этой осенью в Москве - мы там будем про это рассказывать.
На ArchDays мой коллега Рома Юрасов расскажет про выстраивание процессов, историю и развитие архревью в Еде, нашу гильдию архитектуры, технологическую культуру.
На Highload++ я в своем докладе больше сделаю упор на выбор технологий под нагрузку, работу с рисками, автоматизацию процедуры, метрики.
В обоих докладах будет про проблематику, технологическую стратегию, а также - разбор шаблона-опросника.

Энциклопедические знания

Раз уж сегодня день знаний, поздравлю вас с ним следующей аллюзией.

Из недавнего разговора с коллегами:
- А от Тунгусского метеорита кто вымер - динозавры или мамонты?
- Можно глянуть в Википедии
- Не, спрошу у чат-гпт

Вот раньше как говорили - "человек с энциклопедическими знаниями". Значит, у него широкий кругозор, много фактов в памяти, человек начитанный и образованный. Логично - читая энциклопедии, можно обогатить свои познания множеством фактов - никогда не знаешь, в какой момент они пригодятся. Я люблю дум-скроллить википедию. Искал одно, а там - ссылка за ссылкой - и вот ты уже упоенно читаешь биографию Черчилля.

А теперь что - "человек с чат-гпт-шными знаниями"? Это значит, вообще без оных? Нет, удобно, конечно - задал конкретный вопрос, получил какой-то ответ (хотя я бы дабл-чекнул). Но это убивает романтику получения знаний. Полученные таким образом сведения менее ценны и быстрее забудутся. Да еще и контекста не будет.

Сила - в знаниях. Читайте энциклопедии.

Автор колонки уходит в отпуск до сентября, не теряйте.
Но на случай, если вы что-то пропустили, вот дайджест прошлых постов:

Важный дисклеймер (есть в закрепе)

Рабочее, серьезное:
И снова про алгоритмы
Стратегия надежности 1 2 3
Надежность: качество релизов
Про BDUI
Вредные советы для продактов, ставящих задачи разработке
Должен ли тимлид писать код?

Околорабочее, несерьезное:
О дипломированных специалистах
Зирвак как платформа надежности
Доверьте работу профессионалам
Трудности перевода
Командный дух

Про тачки:
Автопуть
Mercedes-Benz Panamera WRX
Trust issues
Обратная связь

В порядке бреда:
О пользе караоке
Бизнес-план
Распределенный бог

Предыдущий дайджест

А если вам нравятся мои тексты, поделитесь ими по-братски с друзьями/коллегами. Только так канал будет расти и развиваться, а я ценю релевантную и читающую аудиторию (потому не прибегаю ко всяким мутным схемам накрутки подписчиков). Спасибо)

Обратная связь

Нет ничего важнее умения работать с обратной связью. Что в случае с сервисом/бизнесом, что с личным фидбеком. Любую обратную связь нужно уметь отработать - вынести из нее уроки, запланировать улучшения, пойти навстречу фидбекодателю. Худшее, что можно сделать - встать в защитную стойку и начать прикрываться оправданиями.

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

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

Со стороны пользователя все выглядит чуть иначе. Услуга оказана некачественно. Диагностика авто после покупки выявила существенные недостатки, которые эксперт-диагност не заметил. Впрочем, не очень-то и старался, судя по косвенным признакам, включающим записи видеонаблюдения у продавца. Что ж, бывает, донесу обратную связь.

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

Должен ли тимлид писать код?

Я считаю, что да. Хотя частенько слышу иное мнение.

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

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

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

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

В-третьих, перестав ожидать от тимлидов хоть какой-то код, мы скоро поддадимся соблазну начать нанимать тимлидов, которые заведомо не будут писать код. Либо тех, кто уже давно разучился и стал менеджером, либо тех, кто ранее писал на других языках/стеке и не планирует переучиваться. И такому руководителю будет кратно сложнее разобраться в том, чем же занимается его команда. Он не будет чувствовать их жизнь на кончиках пальцев, будет хуже понимать их проблемы, будет менее объективно их оценивать. Да и доверять команда ему будет меньше, авторитет проще заслужить, засучив рукава и поработав с парнями бок о бок.

Как же он успеет и лидить хорошо, и код писать - спросите вы. Если мы говорим о руководителе небольшой (5-7 человек) команды, то руководство ей не должно занимать фулл-тайм. А если занимает - это тоже звоночек. Возможно, лиду приходится с людьми нянчиться, и тогда нужно вложиться в их самостоятельность, укомплектоваться ребятами посильнее, делегировать что-то и высвободить себе время. Если команда большая (10-15 человек), то либо можно кодить поменьше (условно, 10% времени вместо 40), либо попилить команду на две, либо вырастить себе зама.

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

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

Вредные советы для продактов, ставящих задачи разработке

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

Сабджект: Та фича, про которую я тебе говорил в коридоре
Описание: <отсутствует>
А на самом деле: и как это понимать? Когда ты что кому говорил? "Нет времени объяснять"? А ты уверен, что я тебя правильно услышал и запомнил? А когда я сделаю что-то по-другому, опять я буду виноват?

Сабджект: Новая фича
Описание: <скриншот макета из фигмы>
А на самом деле: А что именно из этого, простите, надо делать? А как оно сейчас выглядит с учетом вариативности экспериментов? Как оно должно работать? Кто это вообще рисовал??

Сабджект: Сделать ручку (endpoint - прим.ред.)
Описание: Нужна ручка, которая принимает id юзера и возвращает жсон со статусом и eta текущего заказа.
А на самом деле: А какую задачу ты решаешь? Можно хоть какой-то контекст и цель? Все же разделение труда придумали не просто так, оставь нам решать, как именно технически решить эту задачу и какой контракт будет у ручки, пожалуйста.

Сабджект: Вырастить GMV на 3%
Описание: Мы отстаем от бюджета 6+6, нужно догнать GMV. Поэтому нужно повысить конверсию с главной в заказ на 2% и средний чек на 6%.
А на самом деле: Спасибо, тут есть какой-то контекст "зачем". Но не хватает "как", а вот это уже, в продуктовом смысле - твоя вотчина.

Сабджект: Писать на трекинге "доставили раньше на Х минут".
Описание: Если заказ завершается раньше промиса, писать об этом на экране трекинга.
А на самом деле: А если раньше на 1 минуту, все равно писать? А если заказ отменился? А считать от прибытия курьера или от передачи заказа? Кто должен продумывать корнер-кейсы, ты или я?

Сабджект: Трансляция на трекинге, чтобы клиент не скучал
Описание: Если курьер опаздывает более, чем на 10 минут, клиент скучает и злится. Чтобы его развлечь, будем показывать на экране трансляцию с фронтальной камеры марсохода Curiosity с задежкой не более 3с - покорение космоса это круто. Срок - до пятницы хард, заказана реклама на ТВ.
А на самом деле: Ммм, а у нас нет sdk для потокового видео, нужно затаскивать. Еще с NASA надо договориться об API. Доступы проковырять. А задержка в 3с немножко невозможна - расстояние до Марса колеблется в диапазоне от 3 до 22 световых минут. Может, стоило обсудить техническую возможность до того, как ставить задачу и прибивать гвоздями сроки?

Сабджект: Пофиксить краш на корзине
Описание: BLOCKER ASAP (проявляется у Ромы!!!)
А на самом деле: По приборам этих крашей было 8. На двух униках. Три - у Ромы, 5 - у нашего qa. Это точно достаточно критичная задача, чтобы отложить ради нее все остальное? Давайте реже следовать методологии RDD (Roma-Driven-Development) и опираться на цифры и риски?

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

Командный дух

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

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

Одна из уже сложившихся традиций у нас - раз в год ездить на какой-то не-московский этап RDS GP, притом заодно делать из уикенда какую-то запоминающуюся тусовку. Поначалу я знал лишь одного коллегу, кто тоже болеет за дрифт. Сейчас мы второй год ездим всемером. У нас в тусовке есть тимлид (и практикующий бекендер), три продакта, проджект (ex-qa), рукль разработки и CEO. Нужно завербовать еще хотя бы одного фронта и сможем за выходные под пиво запускать проекты! (Чрезмерное употребление алкоголя вредит вашему здоровью)

В прошлом году ездили на питерский этап. Сняли на Игора-драйв домик с сауной, пожарили шашлыки под корону (салют ми фамилия!), поиграли в коднеймс, посмотрели этап. Было офигенно! Заодно притащили в офис мерчовый ковер Forward racing, чтобы напоминал о поездке. И весь год ждали новый сезон.

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

Fresco - очень хорошо.
Тунгуска - невероятно хорошо. Настолько, что, пожалуй, это самый вкусный ресторан, где я был.
Hello wine - классные завтраки (со слов ребят, я пораньше уехал на кольцо).
Formagio - пойти туда на завтрак было ошибкой - это оказался шведский стол...
Brisket boys на фудкорте RDS - как обычно, ван лав. Верните похлебку!
Spaten в аэропорту - вполне неплохо по аэропортовым меркам.
Общественная баня №6 на речном - если вы ностальгируете по совку. Попариться можно, Нарзан имеется.

Сам этап выдался мокрым, но интересным. Суббота - квалификация и топ-32 - шли по сухо-мокро (нестабильное покрытие в пятнышку - ад дрифтера), что добавило много непредсказуемости. Было валидольно, но заезды не самые жирные. В воскресенье лил сильный дождь весь день. На трассе было столько воды, что организаторы рыли дренажные канавы, а пилоты снимали передние бампера, иначе их отрывало потоками воды. Но то, как в этих условиях показали себя пилоты - это просто восторг! Такого коммитмента по сухому-то редко увидишь.

Отдельно зацепила мудрость от комментаторов: "В первом повороте гонка не выигрывается, но очень легко проигрывается".

Это снова было незабываемо. Спасибо вам, дорогие! Люблю вас) В следующем году повторим.

Trust issues

Для меня важно доверять своему автомобилю. Быть уверенным, что он довезет. Знать, что на ходу ничего критичного не отвалится. Я после покупки очередного авто не езжу быстро и агрессивно, пока тщательно не обслужу его (и пока не "вкачусь" в машину, чтобы хорошо ее знать и чувствовать, но это другая тема). Но это вопрос не только надежности машины "в лоб", но и ее характера.

У меня было много машин, которые частенько просили ремонта (с моей любовью к некрухам - немудрено). Но некоторые из них всегда сначала довозили, а потом просились в сервис (например, mercedes s-klasse w220). Некоторые сразу никуда не ехали, оставаясь у дома в духе "мам, мне ко второй паре" (например, bmw 325 e90). Но хуже всего - те, которые подводили меня в самые неподходящие моменты. Например, Cadillac Escalade GMT900. Как вы просили в комментах к прошлому авто-посту, пилю прохладные.

Но сначала обрисую персонажа. Что же из себя представляет эскалейд? Бешенный белый носорог, готовый с ревом броситься на любую газель. Слабоадекватное трехтонное жывотное, которое послушно следует за педалью газа примерно в направлении поворота руля. Мотор V8 6.2л, 409 л.с. прям тащит. Настоящее американское лакшери (но только в комплектации platinum), притягивает взгляды. Однако, на ходу она не такая плавная и мягкая, как ожидаешь (как минимум на 20-х тапочках). Очень просторный салон и огромный багажник. В целом-то, машина кайфовая. Но не лояльная, а я этого не прощаю.

Конец августа 2020, заканчивается дачный сезон. С дачи надо вывезти жену, ребенка, кошку, тёщу и несколько кубометров скарба. Даже в эскалейд все это за один раз не влезет. Принимаю решение сделать две ходки. В первый заход гружу тёщу и часть вещей, еду в город. Ливень, на дороге много воды. И вот этими потоками отрывает трубку маслообменника коробки. Заметить это сразу - трудно. Зато, когда через 80км коробка без масла сплавилась в один чугунок, проблема становится весьма заметна. Становится ясно, что не то что вернуться на дачу за второй партией - до сервиса то доехать затруднительно! А надо вывозить семью. Тачка - в сервис, я - за грузовым каршерингом.

Октябрьское воскресное утро. Через полчаса начнется трансляция финального этапа RDS GP в Сочи. Все настроено, чипари закуплены, я предвкушаю жирные заезды. Но тут вспоминаю, что в эскалейде бак почти пустой (с расходом 25л это довольно частое явление), а утром везти сына в садик, заправка не по пути. Ладно, еще же полчаса есть, заправка в 5 минутах, успею! Однако, с АЗС уехать уже не смог - не двигается рычаг КПП. Как позже выяснилось, сдохла лягушка под педалью тормоза, разблокирующая рычаг кпп, а режима принудительного перевода рычага у машины просто нет. Отдельный прикол - машина под навесом заправки, и эвакуатору-манипулятору не хватает высоты навеса, чтобы поднять авто. Поэтому он сначала меня зацепил за переднюю ось, приподнял и вытянул за заблокированных задних колесах из-под козырька, после чего уже грузил целиком. Половину этапа RDS пропустил.

Морозный январь 2021. Зачем-то поехал в командировку в Питер на машине. Приехал, оставил машину у отеля, пару дней поработал. В день отъезда планировал доехать на тачке от отеля до офиса, поработать, и вечером стартовать домой. Но у машины были другие планы - она не завелась. А мне в этот день как бы домой надо. Да и не планировал я в СПб задерживаться. Чужой город, эвакуатор, сервис. Хорошо хоть мастер к концу дня справился с проблемой, которая оказалась в растрескавшихся от мороза бронепроводах зажигания.

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

Про BDUI

Не будем уходить далеко от темы backend-driven-UI и попробуем разобраться, хорошо это или плохо. Но сначала - краткий исторический экскурс в бдуй Яндекс Еды.

Когда я пришел в Еду в начале 2021 года, BDUI уже был. Но простенький такой, на минималках. Можно было через так называемый Layout Constructor задавать с бекенда вид некоторых экранов (в первую очередь - главной страницы с каталогом). Было понятие блоков/виджетов. Это было нужно для того, чтобы продакт мог сам немного поменять вид главной в поисках оптимального сетапа. Мог запустить эксперимент с альтернативной главной на сегмент аудитории без кода. Мог развести фичи по сегментам или географиям. Но вот незадача - админка была написана чужими для хищников, и пользоваться ей умело 2-3 человека.

Поэтому появилась вторая генерация - с Layout Configurator-ом и виджетами-без-кода. Тут уже все было по-людски, плюс реализация логики виджетов стала выезжать из LC, в котором можно было через админку задать правила обхода источников и формирования выдачи из их ответов. Хорошее проявление лоу-код/ноу-код подхода. Без всякого там богомерзкого ИИ.

Но вскоре подоспела третья генерация на основе решения "FLEX", зародившегося в Маркете. Тут уже совсем другие пироги - с бекенда можно задавать не только сетку виджетов, но и сами виджеты, включая верстку, экшны, навигацию. Клиент становится тоньше - по сути для отрисовки экрана достаточно SDK, а логика и верстка пишутся на бекенде на Котлине (впрочем, как я понимаю, от котлина там по сути только синтаксис, потому что все равно все примитивы там от фреймворка).

Чем это хорошо?
Во-первых, вы пишете фичу 1 раз на обе платформы (а будет вебная реализация - так вообще под все 3). Значит, команда сможет выдавать в полтора-два раза больше фичей в единицу времени тем же составом. Еще и поведение продукта будет консистентным между платформами.
Во-вторых, для доставки фичи до юзеров достаточно релиза бекенда. Никакого релизного цикла, никакого хвоста старых версий. Это ли не то, почему фронты всегда завидовали бекендерам? Фиксы, кстати, тоже доезжают сразу и до всех.

А минусы будут? Куда без них.
Во-первых, сокращается гибкость, особенно в вопросах сложных визуалов. Не может такой фреймворк уметь во все те фишечки, что заложены в натив вендором платформы. Всякие красивости-анимации, всякие глубоко-платформенные look&feel особенности (в большей степени характерные для ios) в таких SDK по большей части недоступны. Но не беда - всегда же можно оставить какие-то части, где это важно, нативными. Или допилить SDK.
Во-вторых, некоторые разработчики слишком сильно любят те самые нативные фишечки и не хотят уходить в бекендно-фреймворковую разработку. Типа это не то. Ну камон, если ты - в первую очередь, инженер, то ты должен понимать, что это более эффективный способ достигать целей. Это инструмент, который про make things done, про результат. Кому важнее процесс - такая работа тоже никуда не денется. Или пилить сам SDK.

Есть и другие плюсы-минусы, можете дополнять меня в комментариях. Но конъюнктура момента такова, что бизнесу нужен bdui, а мы тут как бы зарплату за это все получаем. Так что не ворчим и пилим фичи!