data будни
описание
работаю инженером данных и пишу в основном про это. Профильные ссылки с коротким резюме (статьи, доклады, подкасты), иногда «софтовое» — например, про поиск работы.
1 482
подписчиков
Охват к подписчикам
79,8%
ERR
Реакции к просмотрам
1,09%
244 на 19 постов
Пересылки к просмотрам
0,89%
199
Постов в день
0,0
всего 20
Где отзываются чаще
доля реакций к просмотрам- 28 янв.✍️ о код-ревью у нас в команде в прод только через пулл-реквесты и каждый пулл-реквест должно посмотреть двое коллег. моя личная статистика за 2025 год показывает 430 проведённых код-ревью. сложились какие-то мысли по этому поводу, ниже пытаюсь собрать их вместе. ⌘ зачем вообще нужно код-ревью + это вторая пара глаз с иным контекстом и уровнем погружения: автор и ревьюер смотрят на код в разных когнитивных режимах → ловятся разные ошибки + передача знаний в рамках команды: «применяем вот такие паттерны, а вот так не делаем» → в среднем качестве кода постепенно улучшается + барьер против энтропии и деградации кодовой базы: без должного присмотра любой проект постепенно превращается в трудно поддерживаемое болото ⌘ как бывает без код ревью когда команда небольшая, да ещё и допустим без большого опыта, то большой соблазн поспешить с реализацией или смалодушничать при проектировании → в результате получается нагромождение модулей, которые через время проще сжечь, чем исправить ⌘ как задавать вопросы на код-ревью + открытые вопросы лучше чётких предложений — во-первых, ревьюер сам можем не осознать что здесь происходит, а, во-вторых, + любой код может быть написан множеством способов — прежде чем предложить что-то поправить, надо понять а точно ли оно будет объективно лучше? или просто «ревьюер привык писать по-другому» + спорные места должны быть выведены в общие архитектурные соглашения на команду (какие линтеры используем, как ставим отступы и пр.) ⌘ эффект от код ревью − растёт время на разработку: уходит время на найти ревьюеров и иногда пройти несколько итераций над кодом + твои типичные вопросы на код-ревью возвращаются в твои пулл-реквесты — нарабатывается паттерны и начинаешь думать про типовые кейсы заранее + повышение качества среднего пулл-реквеста — на ревью не поступает откровенно плохих пулл-реквестов, где какой-то треш или забыли подумать2,62%
- 29 янв.📢 ищем дата-коллег к себе в Яндекс Финтех → дата инженеры 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 буду рад ответить на вопросы в комментах или так же в личке1,87%
- 2 февр.✍️ о код-ревью у нас в команде в прод только через пулл-реквесты и каждый пулл-реквест должно посмотреть двое коллег. моя личная статистика за 2025 год показывает 430 проведённых код-ревью. сложились какие-то мысли по этому поводу, ниже пытаюсь собрать их…1,81%
- 22 февр. 2025 г.🤑 yet another zarplaty классный пример коллаборации: Саша Варламов собрал парсер и визуализацию https://t.me/data_bar/60 а Никита это дело автоматизировал https://t.me/joni_in_web/21 в результате получаем работающий проект и возможность посмотреть живую аналитику зарплат — на скрин вынес кусочек деша с фильтром по аналитике. что мне нравится в подобных проектах: 1. проактивность — сам придумал, сам спроектировал, сам затащил, сам отчитался в блог 2. коллаборация — организоваться вдвоём гораздо сложнее, чем сделать одному, но эффект может быть круче 3. полезность, направленная наружу: когда решал свою задачу, а польза — всем в общем, смотрите деш и ставьте лайки Саше с Никитой)1,73%
- 19 апр.🦄 руководитель Claude Code об AI в разработке послушал интервью Бориса Чёрного в подкасте Ленни. Борис написал первую версию Claude Code и теперь руководит этим направлением в Anthropic. https://youtu.be/We7BZVKbCVw по их данным сейчас уже 4% всех коммитов в Гитхаб создаются через Claude Code (ожидают 20% к концу года) интересно, что первую версию Claude Code Борис сделал прошлой весной и это не был сиюминутный успех; популярность инструмента росла постепенно и взрывной рост случился после выхода модели осенью (Опус 4.5 кажется) и с ноября 2025 Борис не написал ни строчки кода вручную — всё через Клода; так же приводит в пример «лучших программистов Spotify», мол, они тоже больше не пишут код руками. Борис видит, что в будущем профессии будут теснее переплетены: не будет программистов или дизайнеров, все будут builder («создатель»?) — задавать ви́дение, раздавать задачи аи-агентам и принимать результат их работы. этот сдвиг парадигмы ставят в один ряд с изобретением печатного станка и освобождением пицсцов от монотонной работы; и с переходом от программирования на перфокартах к следующему уровню.1,57%
- 21 апр.🥷 DHH об agent-first подходе DHH — известный ии-скептик и сторонник написания кода вручную; в своём сетапе он не использует IDE с их подсказками и навигацией по коду — всё набивает ручками (и радуется) ещё DHH известен своими сильным мнением и радикальными взглядами — он говорит что думает, не взирая на мнения большинства или отдельных авторитетов недавно зашёл к Pragmatic Engineer на интервью https://youtu.be/JiWgKRgdgpI и вот наступил действительно переломный момент: ⁃ июль 2025 — DHH не верит и не использует агентов ⁃ январь 2026 — DHH переходит на agent-first разработку что поменялось? вышли модели, которые выдают достаточно хороший результат, которые при минимальных доработках можно шипать в прод. если уже DHH «распробовал» агентский подход — значит, результаты работы становятся действительно достаточно хорошими ⌘⌘⌘ DHH делится историей, как агент помогает ему разбирать ишью в его проекте на Гитхабе: из 250 открытых пулл-реквестов агент за пару часов разобрал 100. какие-то единицы можно было мержить «как есть» — они уже были достаточно хорошего качества; другую часть агент провалидировал как «правильно опознанный баг, но реализация не идеальная» — такие он адаптировал/переписал согласно принятому стилю репо; и ещё часть агент смог аргументированно зареджектить. при этом сам DHH потратил бы на эту работу несколько дней (и не получил бы большого удовольствия от неё).1,44%
- 5 февр.📁 про культуру ведения тикетов продолжаю рассказывать про внутрянку нашей команды, привлекая ваше внимание к активным вакансиям >_> > важный дисклеймер: это не я, это всё наш техлид Кирилл (я тут только документирую и выношу) думаю, все видели тикеты, прочитав которые, осталось непонятным что́ надо сделать; или задачи, где ты вроде сделал что было написано, но оказалось, что нужно было не то и не так ¯\_(ツ)_/¯ мы в команде стараемся придерживаться культуры ведения задач — попробую описать как я это вижу ⌘⌘⌘ начнём с того, что создать хороший тикет - это отдельная работа; чтобы понятно описать что надо сделать, надо как минимум представлять проблему и целевое решение есть базовый паттерн, которого мы придерживаемся: ⁃ контекст ⁃ проблема ⁃ что сделать ⁃ допматериалы небольшие тикеты могут пропускать 1-2 пункта; а большие эпики будут наоборот побольше ⌘⌘⌘ «хорошие» задачи формулируются через глаголы: сделать …, добавить …, исправить …, пересчитать … однозначно указан объект изменения: таблица, таск, модуль и пр. есть перечень связанных действий: в конце …сделать миграцию, …пересчитать историю, и пр. ⌘⌘⌘ задачи на имплементацию проходят через общее техревью на входе, чтобы вместе посмотреть и проверить: ⁃ проверить, что мы в принципе хотим это делать (тут бинарно; пока без приоритетов) ⁃ задача описана понятно ⁃ ожидаемый результат считывается однозначно ⁃ (опционально) докапывается технических деталей цель такого пре-ревью проверить, что автор достаточно подумал про задачу и потенциальный исполнитель прочитает её ожидаемо паттерны задач помогают консистентно формулировать задачи внутри команды, а так же уменьшают количество догадок и уточнений на этапе разработки ⌘⌘⌘ если задача занимает больше нескольких дней, то внутри ожидаются отбивки по текущему статусы; размер отбивок пропорционален масштабу задачи причём не абстрактный статус «продолжаю работать», а короткий апдейт по фактам: сделано Х / осталось сделать У / открытые вопросы и блокеры … ⌘⌘⌘ в конце каждого тикет исполнитель оставляет резюме о проделанной работе «сделал таск, пересчитал историю, вот ссылка на итоговый объект» — всё что нужно знать о задаче, осознанно принять результат (и при необходимости вспомнить через полгода что тут было вообще) статусы и резюмешки повышают прозрачность работы для сторонних наблюдателей: заказчиков, тимлидов, а так же для себя из будущего прозрачность ведения задач особенно важна при ведении инцидентов — для них помимо резюме дополнительно надо сразу заполнить пост-морфем (инцидент-менеджемент у нас тоже есть — про него в другой раз) ⌘⌘⌘ лайк-шер-репост 👉 https://t.me/data_days/4001,37%
- 8 дек.🤓 Martin Fowler в гостях Pragmatic Engineer https://youtu.be/CQmI4XKTa0U Мартину уже за 60 лет, из которых он 40 с лишним считает себя инженером; когда опыт исчисляется десятками, то накапливается тот уровень насмотренности, когда можно сравнивать эпохи и видеть глобальные тенденции ⌘⌘⌘ по своему масштабу Мартин сравнивает нынешний скачок с переходом программистов с ассемблера на языки более высокого уровня сам Мартин не имеет ничего против вайбкодинга как такового (тут он понимает «вайбкодинга» именно как безоглядное принятие любого результата ллм-ки без глубокого осознания написанного), однако чётко ограничивает зону его возможностей: небольшие проекты, прототипы на выброс и т.д. главный недостаток слепого вайбкодинга — отсутствие цикла обратной связи. не пропуская через себя этот код, нет процесса обучения. новые знания не налипают и не копятся получается вайбкодер через год останется ровно с таким же уровнем и потом его сменит просто другой вайбкодер (помоложе); или просто следующее поколение агентов, которым не нужна будет «простилка» между клавиатурой и креслом ⌘⌘⌘ при этом в прототипировании аи-помощник показывает небывалые приросты в продуктивности. приводят пример инженера из Антропика, который за 2 дня собрал 20 прототипов, итеративно проверяя и валидируя их об команду. здесь быстрый цикл обратной связи помог им сразу на практике осознать простанство потенциальных вариантов и найти подходящие векторы для развития, отбросив остальные ⌘⌘⌘ ещё одна проблема ллм-ок — полная неспособность решить задачу «переименования класса»; по своему дизайну она скорее перепишет половину кодовой базы, чем поправит в трёх местах нужное название при этом современные иде уже давно научились это делать, правда со своей подкапотной магией (которой, видимо, и не хватает ллм-кам) ⌘⌘⌘ общий подход к результатам работы моделей — ничему не верить, всё проверять; вдумчиво читать, внимательно вникать, нещадно тестировать, чтобы добавить чуток детерменированности их безудержной креативности. и тогда действительно можно получать какой-то профит от совместной работы1,32%
- 23 сент. 2025 г.🐤 джуны, 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_days1,25%
- 15 февр. 2025 г.🗿 подкасты про карьеру специально для постоянной читательницы этого блога — Натальи — ни к чему не обязывающая подборка подкастов на тему карьеры, её смены и всякого такого >_> подкасты хороши тем, что можно слушать на фоне, удобно чтобы ненапряжно набраться чужого опыта. пока остальные процессы ещё только готовятся или обдумываются ⌘⌘⌘ первым делом, конечно, стоит упомянуть про подкаст «собес» — в последнем сезоне они делают эпизоды в формате мок-собесов. это когда реальный рекрутер под реальную вакансию собесит кандидата прямо в эфире, а потом дают обратную связь и говорят что можно подкрутить. на своём опыте ощутил, что полезно послушать со стороны как звучит все эти привычные фразы и что излишняя скромность на интервью только мешает и будет интерпретирована не пользу кандидата. это сложно принять в теоретическом вакууме, надо просто послушать N раз других людей. → https://libolibo.ru/sobes ⌘⌘⌘ я бы сказал, что подлодка — мастхев в подкаст-приёмнике айтишника. как шутят сами ведущие, когда законичились темы про айти, начались про всё остальное, поэтому в длинном списке эпизодов можно найти темы под любые запросы. в недавнем выпуске собрался весь состав ведущих и обсудили смену работы, переход из кодеров в менеджеры и обратно (!), переходы внутренние и внешние. кажется на всех они собрали все возможные кейсы и всё подробно обсудили. м-м-мякотка! → https://t.me/podlodkanews/1440 ⌘⌘⌘ и отдельно на тему аналитики два проекта от ребят из тбанка. первый про аналитику — тоже можно повыбирать эпизоды с привлекательной темой. мне понравился выпуск про офлайн-ритейл с представителем Магнита. ребята в унисон разгоняли про темы как вообще анализировать штуки из реального мира, когда надо прямо ножками дойти, что-то поменять, а потом ещё как-то измерить результат. масштаб внушает трепет, а подходы — уважение. → https://t.me/eto_schitaetsya/477 и вот только что узнал про ещё один их подкаст, добавил себе в послушать. подводка звучит интересно. тематика, видимо, связана с продуктами их банка, но иногда зовут и людей извне. → https://t.me/karty_dengi_product/112 ⌘⌘⌘ ещё один пример с другой стороны, когда продукт надо не только анализировать, но и управлять им. кто такие продакты, зачем они нужны, где их место в общей организации и как наладить диалог с разработкой. → https://music.yandex.ru/album/22481935/track/129159864 ⌘⌘⌘ § что ещё можно послушать-посмотреть условному бизнес-аналитику в условном финтехе? что вообще понимают в разных компаниях под «бизнес-аналитиком»? в моей голове есть системные аналитики, которые ближе к данным и процессам, а есть продакты, которые ближе к бизнесу. а «бизнес-аналитиком» получается, это что-то между этими двумя.1,16%
- 19 февр. 2025 г.🦆 прилетят орлы и поднимут прод когда в работе встречаю какую-то проблему, то первым делом хочется написать в командный чатик, типа «ребята, там на дисках место заканчивается» со стороны это читается как «там на дисках место заканчивается … кто-нибудь сделайте что-нибудь!» получается, что я привлекаю внимание всех коллег к проблеме и тогда один из коллег (кстати, кто?) должен оторваться от своего текущего контекста и пойти расследовать эту проблему, потратить своё время и внимание, и найти причину и потенциальное решение но если я уже видел проблему, почему бы самому не посмотреть глубже, потратить какое-то время на расследование и прикинуть варианты решений. и в результате прийти в чатик уже не с проблемой, а с каким-то решением! - понятно, что расследование может занять больше нескольких минут - понятно, что решение может быть тоже не простое или даже несовсем правильное в этих случая включаются уже устоявшиеся процессы в команде; но базовый принцип остаётся — не рассчитывать, что в последний момент прилетят орлы и решат все проблемы иными словами, приходи с решением, а не проблемой!1,12%
- 9 окт. 2025 г.🎧 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_days0,76%