С понедельником, коллеги!

Нужны двое сильных ребят перенести ящики с реактивами в соседнюю лабораторию

Узнали?

Ну а если серьезно, всех с Днем Знаний!

Побольше сил, тем кто в школе, в университете и с усердием прокачивается в своих навыках💪🏿 ну и конечно же еще больше сил родителям😹

Что хочу напомнить вам и прежде всего себе:

▫️Учитесь для достижения конкретных целей
▫️Сразу применяйте знания на практике
▫️И создавайте комфортную для вас среду обучения!

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

Коллеги предложили разыграть одно место на тариф BASE среди вас. Что думаете? Делаем?

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

Погнали💪🏿

Техдолг платежом красен

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

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

Не пишите хреновый код, и не будет вам техдолга

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

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

При этом естественно техдолг не возникает на ровном месте:
▫️Могут быть жесткие дедлайны или сроки, либо сильная динамика требований (тяжело влиять на это - вдруг у вас сильнорастущий бизнес), вплоть до смены стратегии
▫️Классика в неоптимальных процессах: допустим, отсутствие автоматизации тестирования, ну или плохое проектирование (влиять чуть легче)
▫️Может быть и недостаток компетенций (влиять легче всего)

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

Что делать?

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

Далее классифицируем по сложности устранения и срочности, и обязательно проводим экономическую оценку (не только стоимость исправления, но и стоимость отказа от исправления!).

Далее процессная база к устранению техдолга:

1️⃣Техдолг превращается в задачу
2️⃣Задачи приоритизируются
3️⃣Выделяем X% от спринта на техдолг

ну и еще 😎 про предотвращение непреднамеренного долга:

▫️Глубокий анализ требований, с документированием и вовлечением команды в обсуждение (вспоминаем дизайн-док)
▫️Применение архитектурных принципов, документирование решений, архревью (снова вспоминаем дизайн-док)
▫️Единые стандарты разработки, тестирование и статический анализ
▫️Ну и естественно мониторинги

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

Кстати, на Хабре есть очень хорошая статья по этой теме.

#softskills #career

✍️ Михаил Шуфутинский

Вайбы работы в офисе в Москве-Сити примерно такие:

©️Еду в автобусе на работу
©️В это время нас обгоняет Lamborghini, что аж стекла дребезжат
©️Я такой: Ух бля как круто

P.S. На автобусе передвигаться люблю

#life

Интересное что-то от ребят, кого я читаю v0.31

Предыдущий пост тут
Интересное что-то тут

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

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

Погнали 💪

1. Анна поделилась любимым постом в любимом канале, где рассказывается про необычный термин, который, внимание!, хер прочитаешь, не сломав язык.

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

3. Третья Анна нашла необходимое и достаточное коичество бесплатных SQL-тренажеров, кстати среди которых есть и довольно популярные типа sql-ex. Когда я тоже собирал похожую подборку, возможно вам будет полезно

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

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

6. Паша вкинул сразу пару постов: первый пост про GRM от дип сик (где дипсики продолжают идею думания мат.задачами и рассказывают как можно обучить general reward model), ну и второй пост про разбор GSPO от квена и сравнение с GRPO от дипсика

7. Ну и конечно же коллеги с DevFM и пост про работу с ai-агентами. Это как процесссы с разными заходами, приемами и приседаниями с MCP-серверами и Rules. По классике не забываем про тесты и просто не сдаемся!

#interesting

MAPE, SMAPE, WAPE, WMAPE

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

Но бывают моменты, когда у нас адекватный MAE и улетающий MAPE

Го разбираться:

1️⃣MAPE (Mean Absolute Percentage Error) - средняя абсолютная процентная ошибка. По сути для каждого наблюдения берем модуль разницы ABS(Факт - Прогноз), делим на Факт, и усредняем по всем точкам. Ну и не забываем, что коллегам всегда понятно выражение "в среднем мы ошибаемся на 12%".

Проблемы начинаются в окрестностях нуля (допустим, было 0-1-2 транзакций, когда в среднем под 1000). Исключим очевидные моменты с делением на ноль, но при этом все же имеем неприятный момент с околонулевым знаменателем. Типа поделили (1000-1) на 1, и получили 99900% ошибки.

Кайф? Не особо

Ну и не забываем про несимметричность метрики - в кейсе с 1 вниз мы улетим максимум на 100%, ну а вверх неограничены.

2️⃣SMAPE (Symmetric Mean Absolute Percentage Error) - симметричная средняя абсолютная процентная ошибка. Здесь тот же мейп, но с немного другим знаменателем. ABS(Факт - Прогноз) / ((Фактом + Прогноз) / 2)

Здесь мы примерно стараемся избежать маленького знаменателя, но конечно же в некоторых кейсах деление на маленькие числа неизбежны. При этом имеем значение метрики от 0% до 200%, что решает проблему бесконечной ошибки MAPE.

Кстати, можете попробовать на обычных примерах оценить реальную симметричность метрики - можно заметить склонность сильнее штрафовать за занижение прогноза. Ну и стоит ли бизнесу говорить о симметричном MAPE?

Наверно не стоит

3️⃣WAPE (Weighted Absolute Percentage Error) - взвешенная абсолютная процентная ошибка. Тут все просто - суммируем все абсолютные ошибки ABS(Факт - Прогноз) и делим эту сумму на сумму факта, неявно взвешивая ошибку каждого товара по его объему продаж. Типа число транзакций около единицы уже не так сильно повлияют на итоговую метрику.

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

4️⃣WMAPE (Weighted Mean Absolute Percentage Error) - взвешенный MAPE (не путаем с WAPE). WMAPE - это среднее значение MAPE, где ошибка для каждого товара взвешивается по его важности (например, по доле в продажах). Для каждого товара считаем его MAPE. Затем умножаем MAPE каждого товара на его вес (например, долю в обороте) и суммируем. Sum(prop_i * MAPE_i).

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

Что в итоге?

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

Дополнительное чтиво: 1, 2, 3

#metrics

Откуда у нас такие хорошие метрики - мы просто правильно их считаем

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

Скорее про отсмотр правильных разрезов для правильных выводов

Допустим, команда прогнозирования спроса на своих дэшах видит MAPE порядка 5%, что ну супер круто в реалиях ритейла.

А по каким разрезам эта метрика считается?

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

На дэше Лев Толстой, а в реале …

Ну или если считаем конверсию в новую фичу - допустим, продуктовая команда запускает новую фичу в мобильном приложении и мы видим рост конверсии на 40%. Кейс на 4 плюса очевидно.

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

Ну вы поняли

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

Я не думаю, что это делается со злым умыслом. Причины обычно глубже:
1️⃣Иногда страшно признать, что что-то не работает
2️⃣Иногда мы можем не понимать связь между метрикой и реальной бизнес-ценностью.
3️⃣Ну и база: «Когда мера становится целью, она перестает быть хорошей мерой».

Что делать?

▫️Документируем расчеты
▫️Описываем глобальные цели: Какую бизнес-проблему мы решаем этой метрикой? Что мы будем делать, если она пойдет вверх или вниз?
▫️Смотрим другие метрики. Растёт скорость регистрации? Проверьте, не упала ли активация. Растёт число фичей? Убедитесь, что не падает производительность.
▫️Ну и конечно культура честности: красный график - это не провал, это сигнал. Это самая ценная информация, которую мы можем получить, это же точка роста!

Так что в следующий раз, когда увидите подозрительно идеальный дашборд, просто спросите как люди считали😹

#softskills #metrics

Интересное что-то от ребят, кого я читаю v0.32

Предыдущий пост тут
Интересное что-то тут

Половина сентября пройдена, а значит до следующего лета не так уж и далеко 👍

1. Макс обнаружил топовый курс с топовыми преподами (рисерчеры из разных топовых лаб) по Agentic AI. Говорят, что по прошлой итерации было неплохо с модельками и ризонингом, так что надеюсь курс будет годный.

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

3. Валера запилил свой поиск для агентов на SearXNG (open-source метапоисковик) + его адаптер = drop-in замена Tavily, где меняется base_url. API тот же, но приватный и условно-бесплатный.

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

5. Дмитрий нашел модели с длинным контекстом в 2M токенов - это Sonoma Dusk Alpha и Sonoma Sky Alpha, обе работают бесплатно на опенроутере. Ходят слухи, что это могут быть модельки от xAI.

На этом все! На следующей неделе вернусь еще с пятью полезными постами!

#interesting

Идеологическая составляющая работы

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

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

2️⃣Не менее сочный оффер от дерзких ребят со стартапа, где будет возможность делать то, что мы и сами делали бы бесплатно. Это по-настояшему двигает нас и интересно нам, а тут еще за это и деньги плотят. Оффер чуть ниже рынка, зато задачи, команда и сама атмосфера бешено заряжают. Есть даже некоторое ощущуение, что можно повлиять на индустрию

Сначала заработаю, а потом буду заниматься тем, что нравится

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

Каким будет наш внутренний ответ на вопрос "Зачем я это делаю?" Не страшно получить ответ про деньги в числе топовых. Важно не забывать про самого себя в устремлениях к этой цели. Именно здесь хочется вспомнить про видение идеологии в работе.

Я бы обозначил следующие моменты:
▫️Нам искренне любопытно решать поставленные задачи
▫️Мы видим, какую пользу приносит ваша работа людям, компании или миру
▫️Принципы компании совпадают с нашими личными
▫️Задачи способствуют нашему вектору развития

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

Я не хочу тратить треть своей жизни на то, что забирает энергию

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

Допустим:

1️⃣На старте можно проинвестировать в рост и интерес (при этом мы можем брать более высокие риски), даже если зарплата на 15-20% ниже рынка. То есть первые N лет карьеры мы стратегически прокачиваем навыки и опыт
2️⃣Экспертная ветка прокачивается быстрее, когда мы увлечены своим делом, учимся быстрее, легко погружаемся и по крупице становимся тру профессионалом. А крутым профессионалам всегда готовы платить. Очевидно, что наша экспертность повысит нашу ценность
3️⃣Рано или поздно, мы окажемся в той точке, где мы будем заниматься любимым делом за 300кк/сек (если не надоест)

С другой стороны, можно закрыть и краткосрочные цели, но например строго себя ограничить: "Я работаю на этом проекте ровно N лет, чтобы накопить X денег на Y и параллельно с работой изучаю то, что мне интересно (курсы, пет-проекты)". Кстати, возможно за эти N лет и появится желание работать на этом проекте.

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

Давайте сердечки за интерес и смысл в работе, а огонечки за деньги. Посмотрим, кто и как на это смотрит.

#career

Аналитесса-разработчица 🐰

Здесь в блоге мы с вами часто обсуждаем пути и роадмапы для быстрого вхождения в карьеру датасаентиста и вообще допустим любого аналитика. При этом традиционный путь никто не отменял. Топовые результаты в школе, затем топовый ВУЗ и топовые курсы, после сразу топовая стажировка и voila, можно залетать на любую вакансию с 300кк/сек

И вот вам пример:

Анна закончила Вышку и ШАД, до этого участвовала в олимпиадах, после сразу влетела на стажировку в Яндекс и сейчас поднимает аналитическую платформу в Авито и еще ведет свой канал @analytess 💪🏿

Из полезного я бы выделил:

▫️Синдром олимпиадного прошлого
▫️Work-life balance vs work-life blend
▫️Критический взгляд на исследования зп
▫️Плюсы работы в Авито
▫️Хороший пост про переработки руководителя

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

Всю самую топовую информацию вы найдете на канале, а я по классике рекомендую пробежаться, вытащить для себя все самое важное и подписаться на @analytess чтобы не пропустить экспертный контент 🌟