🤑 yet another zarplaty

классный пример коллаборации:

Саша Варламов собрал парсер и визуализацию
https://t.me/data_bar/60

а Никита это дело автоматизировал
https://t.me/joni_in_web/21

в результате получаем работающий проект и возможность посмотреть живую аналитику зарплат — на скрин вынес кусочек деша с фильтром по аналитике.

что мне нравится в подобных проектах:

1. проактивность — сам придумал, сам спроектировал, сам затащил, сам отчитался в блог

2. коллаборация — организоваться вдвоём гораздо сложнее, чем сделать одному, но эффект может быть круче

3. полезность, направленная наружу: когда решал свою задачу, а польза — всем

в общем, смотрите деш и ставьте лайки Саше с Никитой)

🐤 джуны, LLM и Shopify

в интернетах есть тезис, что с внедрением LLM джуны будут не нужны: мол, llm-агент сам как крайне усердный и очень производительный джун

→ и тогда со временем всю базовую джуновскую работу будут делать llm-агенты

⌘⌘⌘

противоположный тезис высказывает Farhan Thawar, Head of Engineering в Shopify (всё время читаю как Spotify, приходится себя одёргивать и перепроверять)

Shopify среди меня известен своим мега-крутым фаундером — Tobias Lütke; слушал его в Lenny's Podcast — создаёт впечатление очень здравого и продвинутого человека

кроме того, про него неоднократно упоминал Lex Fridman, что даёт ещё сколько-то очков этому джентельмену и культуре в его компании

⌘⌘⌘

ещё добавляет веса этой дискуссии фигура ведущего. Gergely Orosz — автор рассылки The Pragmatic Engineer (а теперь ещё и одноимённого подкаста)

Gergely каждый раз глубоко копает тему, проводит предварительный ресёрч и «наводит справки». многие вопросы он задаёт «а вот твои коллеги, говорят… ».

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

⌘⌘⌘

про адоптинг аи-тулзов

господин Farhan замечает, что Шопифай был первым пользователем Copilot за пределами GitHub — для этого просто надо было написать письмо напрямую СЕО и просто попросить.

сразу после того, как Томас Домк стал генеральным директором GitHub, он отправил ему электронное письмо с просьбой предоставить доступ к Copilot для инженеров Shopify.

хотя на тот момент инструмент не был доступен для коммерческого использования, Shopify всё равно получила к нему доступ. Компания пользовалась Copilot около двух лет без оплаты и в обмен предоставляла разработчикам GitHub обширные отзывы о работе инструмента.

⌘

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

почти для каждого инструмента внутри Шопифай есть MCP сервер и инструкция как его подключить к своему Курсору.

⌘

про найм стажёров

- в прошлый семестр (?) Шопифай нанял 25 стажёров

- Farhan уговорил своего СЕО в следующий семестр нанять ноль 1000 (!) стажёров

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

логика для такого найма простая — Farhan видит, что новое поколение думает по-другому. они уже буквально ai-native, они учатся и заканчивают вузы, когда chatgpt уже стал нормой, поэтому могут предложить нестандартные решения для задач.

и само наличие таких людей в командах помогает «старичкам» узнавать новое и где-то по-другому смотреть на свой опыт.

в общем, Шопифай делает ставку на ai-стажёров

подкаст есть на ютубе
https://youtu.be/u-3IILWQPRM

@data_days

NewHR в очередной — уже шестой! — раз проводит опрос про работу аналитиков

я бы тоже прошёл, но я, к сожалению, я не аналитик

если тоже любите читать результаты таких исследований, можно инвестировать 20 минут в опрос

новый опрос за 2025 год тут

а освежить в голове
результаты опроса 2024 можно тут
https://newhr.org/data/research-analysts-2024

🎧 Data Platform T-Bank

послушал подкаст с СТО платформы данных Т-Банка
https://t.me/book_cube/3766

для понимания масштаба

→ 15К MAU пользователей платформы (при условных 18К всех сотрудниках инхаус — это довольно большое проникновение)

→ всю платформу поддерживает ~230 человек

→ сторадж — около 15–20 петабайт;

→ компьют — порядка 100К ядер

→ внутри ~20 тысяч объектов

основная аналитическая СУБД — Greenplum: около 10 кластеров от 30 до 72 нод в каждом


проблемы с текущей архитектурой

⌘ Greenplum имеет ограничение на количество параллельных запросов, которые он может обработать эффективно; считается, что это около ста запросов.

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

⌘ архитектура с Greenplum оказалась сложной и нестабильной; даже небольшие сбои могут привести к необходимости переключения пользователей на резервные кластеры, что не всегда проходит гладко и может вызывать негативный опыт

⌘ несмотря на то, что данные распределяются по сегментам, возникают проблемы с их равномерным распределением и обработкой, особенно при больших объёмах и высокой нагрузке


планы дальше

со временем стало понятно, что текущая архитектура не выдерживает всё возрастающий масштаб платформы

теперь задача — рядом с уже летящим самолётом построить ещё один, новый; и как-то аккуратно пересадить «пассажиров» с одного борта на другой

в качестве новой целевой архитектуры выбрали стандартный набор:
iceberg + s3 + spark + trino

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


@data_days

🤓 Martin Fowler в гостях Pragmatic Engineer

https://youtu.be/CQmI4XKTa0U

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

⌘⌘⌘

по своему масштабу Мартин сравнивает нынешний скачок с переходом программистов с ассемблера на языки более высокого уровня

сам Мартин не имеет ничего против вайбкодинга как такового (тут он понимает «вайбкодинга» именно как безоглядное принятие любого результата ллм-ки без глубокого осознания написанного), однако чётко ограничивает зону его возможностей: небольшие проекты, прототипы на выброс и т.д.

главный недостаток слепого вайбкодинга — отсутствие цикла обратной связи. не пропуская через себя этот код, нет процесса обучения. новые знания не налипают и не копятся

получается вайбкодер через год останется ровно с таким же уровнем и потом его сменит просто другой вайбкодер (помоложе); или просто следующее поколение агентов, которым не нужна будет «простилка» между клавиатурой и креслом

⌘⌘⌘

при этом в прототипировании аи-помощник показывает небывалые приросты в продуктивности. приводят пример инженера из Антропика, который за 2 дня собрал 20 прототипов, итеративно проверяя и валидируя их об команду.

здесь быстрый цикл обратной связи помог им сразу на практике осознать простанство потенциальных вариантов и найти подходящие векторы для развития, отбросив остальные

⌘⌘⌘

ещё одна проблема ллм-ок — полная неспособность решить задачу «переименования класса»; по своему дизайну она скорее перепишет половину кодовой базы, чем поправит в трёх местах нужное название

при этом современные иде уже давно научились это делать, правда со своей подкапотной магией (которой, видимо, и не хватает ллм-кам)

⌘⌘⌘

общий подход к результатам работы моделей — ничему не верить, всё проверять; вдумчиво читать, внимательно вникать, нещадно тестировать, чтобы добавить чуток детерменированности их безудержной креативности.

и тогда действительно можно получать какой-то профит от совместной работы

✍️ о код-ревью

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


⌘ зачем вообще нужно код-ревью

+ это вторая пара глаз с иным контекстом и уровнем погружения: автор и ревьюер смотрят на код в разных когнитивных режимах → ловятся разные ошибки

+ передача знаний в рамках команды: «применяем вот такие паттерны, а вот так не делаем» → в среднем качестве кода постепенно улучшается

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


⌘ как бывает без код ревью

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


⌘ как задавать вопросы на код-ревью

+ открытые вопросы лучше чётких предложений — во-первых, ревьюер сам можем не осознать что здесь происходит, а, во-вторых,

+ любой код может быть написан множеством способов — прежде чем предложить что-то поправить, надо понять а точно ли оно будет объективно лучше? или просто «ревьюер привык писать по-другому»

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


⌘ эффект от код ревью

− растёт время на разработку: уходит время на найти ревьюеров и иногда пройти несколько итераций над кодом

+ твои типичные вопросы на код-ревью возвращаются в твои пулл-реквесты — нарабатывается паттерны и начинаешь думать про типовые кейсы заранее

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

📢 ищем дата-коллег к себе в Яндекс Финтех

→ дата инженеры
https://yandex.ru/jobs/vacancies/inzhener-dannih-v-finteh-36637

→ дата-партнёры (они же системные аналитики двх)
https://yandex.ru/jobs/vacancies/analitik-dwh-v-finteh-27815

это прям в нашу команду, то есть будем работать вместе)

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

хотим и дальше нести свет в массы, поэтому активно ищем новых коллег


что у нас есть интересного:
→ есть полная документация — наши объекты не идут в прод без описания каждого атрибута
→ на нанейминг полей и объектов — есть конвенция
→ на YQL — есть линтеры
→ на пулл-реквесты — тесты в си-сд (и 4 глаза ревьюеров)

из технологии — почти всё яндексовое:
+ YTsaurus как основная система хранения
+ смотрим в сторону ClickHouse рядом
+ придерживаемся подхода инфра-как-код через Terraform
+ логброкер как шина данных для стриминга и дата-трансфер как коннектор (если вам это о чём-то говорит)

любим процессы (но без карго культов)
→ есть дежурство и инцидент-менеджмент с пост-мортемами
→ есть удобный процесс мониторинга и алертов
→ подробный онбординг и прочие документы о процессах команды


чем предстоит заниматься:
§ перекладывать джейсоны ысоны слева направо — разобраться где найти, откуда они там появляются, почему в таком формате, и как лучше их разложить, чтобы дорогим пользователям было удобнее их селектить;

$ работать над доступностью сервиса и данных: как валидировать данные и мониторить корректность на потоке, чтобы не пробивать общие сла;

$ выяснять, спрашивать, изучать у источников почему данных не было, почему поздние долёты, почему внутри полная шляпа, и вообще где ещё три нужных поля;

$ спорить с дорогими коллегами как оптимальнее перелопатить теробайты в секунду, как лучше описать новый домен, какой кусок вынести в общую либу, голосовать какие фичи больше всего нужны в общей платформе

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


понимаю, что процесс найма долгий, поэтому планирую постепенно накидывать заметок о буднях команды; ссылки буду появляться ниже
→ о код ревью
→ ещё о код ревью
→ про культуру ведения тикетов
→ …

можно откликаться на вакансия выше или присылать CV с кратким интро мне в личку @SashaMikhailov

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

📝 о код-ревью (часть 2)

вижу тема ↑ код-ревью хорошо зашла — продолжаю накидывать


⌘ разные авторы — разные вопросы на ревью

+ во время онбордина на первые ревью обычно приходит тьма комментариев; чтобы проверить, что автор достаточно погрузился в новый проект, приходится спрашивать с самых банальностей: «почему тут за Т-2», «почему тут снепшото, а не апсёрт?» и т.д.

+ со временем у авторов набирается «репутация» — вопросы переходят на следующий уровень абстракций (или вовсе пропадают с типовых решений)


⌘ размер имеет значение

− гигантский ПР на 500+ строк кода, затрагивающий множество модулей, имеет шанс погрязнуть в процессе ревью (не говоря уже про увеличенную вероятность пропустить багульку в прод)

+ а вот маленький атомарный ПР легко читать и требует адекватного количества когнитивной энергии ревьюера — а значит не вызывает сопротивления и обычно сходится предсказуемо быстро


⌘ не всегда есть «правильный» ответ

+ иногда вопрос — это предложение к дискуссии или просто любопытство почему выбран именно такой подход

+ хочется проверить, что автор продумал основные кейсы в предлагаемом решении


⌘ проблемы код-ревью

− неконсистентность от ревью к ревью: даже один ревьюер может спросить разное, не говоря уже о нескольких

− код-ревью не случается само — оно занимает время и тратит когнитивную энергию; это буквально конвейер и его надо явно планировать в своём календаре (получается всем в команде)

− ну и в целом — растёт тайм-ту-маркет, в задачу надо закладывать время на схождение код-ревью


⌘ ожидания от код-ревью

+ код-ревью не должно быть узким горлышком — положительные эффекты складываются, когда вся команда ревьюит друг-друга (не только один тимлид по ночам и выходным)

+ LGTM — это тоже ответственность; если код падает прям сразу после релиза — вопросики будут как к автору, так и к ревьюеру;

+ всем в команде (включая ревьюера) потом поддерживать этот код — в общих интересах поддерживать кодовую базу в хорошем виде


⌘ пускай потеет машина

+ проверять синтаксис и опечатки должны машины, а не белковые мешки; поэтому эффективнее настроить линтеры, тесты, вот это всё

+ если команда уже сформировала код-стайл и обсудила архитектурные подходы, то будет проще формализовать и базовые проверки

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


---

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

🦀 Clawdbot / Moltbot / OpenClaw

там похоже намечается очередной качественный скачок аи-строения: австрийский программист написал автономного (?) ии-агента… и понеслось

формат горячих новостей не мой любимый жанр, но это залетело в моё инфополе с трёх разных сторон:

+ Самат Галимов накидал ссылок для понимания контекста
https://t.me/ctodaily/1995

+ Pragmatic Engineer выпустил интервью с автором
https://youtu.be/8lF7HmQ_RgY

+ ребята из Шмит16 собрались вместе где-то на Бали и скупают все доступные мак-мини, чтобы устроить ферму из таких аи-агентов

сам автор бота не случайный мамкин вайбкодер — он начинал ещё с веб-приложений в начале 2000-х и потом перешёл на приложения айос для первого айфона.

потом запилил как побочный продукт PSPDFKit — низкоуровневый парсер и рендере пдф-ок; продукт быстро стал приносить денег больше, чем основная работа и он переключился на него фултайм. потихоньку стартап разросся до 70 человек.

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

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

⌘⌘⌘

потом он (традиционно) выгорел и ушёл с радаров на три года, ничего не делал, ничем не занимался; и всё, чтобы «вернуться в интернет» в 2025-м —прямо на рассвете ии-агентов

тут он офигел от новой технологии и по первым ощущениям от продукта он вспомнил все хорошие впечатления от программирования

в итоге к осени он врубился в технологию настолько, что она стала для него «запойной»: работает на десятью пет-проектами сразу и 10 разных агентах / терминалах

⌘⌘⌘

поинты автора про подход к агентам:

⌘ замкнуть цикл обратной связи: задача → план → исполнение → отладка → тестирование → сверка с исходной задачей — всё это агент делает сам в бесконечной итерации, пока результат не достигнут

⌘ «новое» программирование — это верхнеуровневый дизайн, а не написание кода

⌘ из аи-агенты можно собирать локальные мини-команды (и не отдельные тулзы)

⌘ а синьорные инженеры — это теперь аи-менеджеры таких локальных команд для разработки

⌘⌘⌘

сам Moltbot / OpenClaw выглядит как проект на стыке аи- и арт-перфоманса

автономный агент, которому явно дают доступ к локальной системе — это что-то за гранью привычного

причём не каждый догадывается или может позволить себе отдельный мак-мини для инстанса бота — и они грузят их прям на своей основной тачке

с другой стороны, эти эмерджентный и удивительные свойства агента проявляются как раз на богатой почве развитого локального окружения; на стерильной системе у него не будет истории переписки в мессенджер и почте, не на что смотреть)

⌘⌘⌘

агент имеет доступ к своим настройкам и исходному коду

может менять свою конфигурацию, дописывать новые модули

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

🤯

📁 про культуру ведения тикетов

продолжаю рассказывать про внутрянку нашей команды, привлекая ваше внимание к активным вакансиям >_>

> важный дисклеймер: это не я, это всё наш техлид Кирилл (я тут только документирую и выношу)

думаю, все видели тикеты, прочитав которые, осталось непонятным что́ надо сделать; или задачи, где ты вроде сделал что было написано, но оказалось, что нужно было не то и не так ¯\_(ツ)_/¯

мы в команде стараемся придерживаться культуры ведения задач — попробую описать как я это вижу


⌘⌘⌘

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

есть базовый паттерн, которого мы придерживаемся:
⁃ контекст
⁃ проблема
⁃ что сделать
⁃ допматериалы

небольшие тикеты могут пропускать 1-2 пункта; а большие эпики будут наоборот побольше


⌘⌘⌘

«хорошие» задачи формулируются через глаголы:
сделать …, добавить …, исправить …, пересчитать …

однозначно указан объект изменения: таблица, таск, модуль и пр.

есть перечень связанных действий: в конце …сделать миграцию, …пересчитать историю, и пр.


⌘⌘⌘

задачи на имплементацию проходят через общее техревью на входе, чтобы вместе посмотреть и проверить:
⁃ проверить, что мы в принципе хотим это делать
(тут бинарно; пока без приоритетов)
⁃ задача описана понятно
⁃ ожидаемый результат считывается однозначно
⁃ (опционально) докапывается технических деталей

цель такого пре-ревью проверить, что автор достаточно подумал про задачу и потенциальный исполнитель прочитает её ожидаемо

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


⌘⌘⌘

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

причём не абстрактный статус «продолжаю работать», а короткий апдейт по фактам: сделано Х / осталось сделать У / открытые вопросы и блокеры …


⌘⌘⌘

в конце каждого тикет исполнитель оставляет резюме о проделанной работе

«сделал таск, пересчитал историю, вот ссылка на итоговый объект» — всё что нужно знать о задаче, осознанно принять результат (и при необходимости вспомнить через полгода что тут было вообще)

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

прозрачность ведения задач особенно важна при ведении инцидентов — для них помимо резюме дополнительно надо сразу заполнить пост-морфем
(инцидент-менеджемент у нас тоже есть — про него в другой раз)

⌘⌘⌘

лайк-шер-репост
👉 https://t.me/data_days/400