🦆 прилетят орлы и поднимут прод
когда в работе встречаю какую-то проблему, то первым делом хочется написать в командный чатик, типа «ребята, там на дисках место заканчивается»
со стороны это читается как «там на дисках место заканчивается … кто-нибудь сделайте что-нибудь!»
получается, что я привлекаю внимание всех коллег к проблеме и тогда один из коллег (кстати, кто?) должен оторваться от своего текущего контекста и пойти расследовать эту проблему, потратить своё время и внимание, и найти причину и потенциальное решение
но если я уже видел проблему, почему бы самому не посмотреть глубже, потратить какое-то время на расследование и прикинуть варианты решений. и в результате прийти в чатик уже не с проблемой, а с каким-то решением!
- понятно, что расследование может занять больше нескольких минут
- понятно, что решение может быть тоже не простое или даже несовсем правильное
в этих случая включаются уже устоявшиеся процессы в команде; но базовый принцип остаётся — не рассчитывать, что в последний момент прилетят орлы и решат все проблемы
иными словами, приходи с решением, а не проблемой!
когда в работе встречаю какую-то проблему, то первым делом хочется написать в командный чатик, типа «ребята, там на дисках место заканчивается»
со стороны это читается как «там на дисках место заканчивается … кто-нибудь сделайте что-нибудь!»
получается, что я привлекаю внимание всех коллег к проблеме и тогда один из коллег (кстати, кто?) должен оторваться от своего текущего контекста и пойти расследовать эту проблему, потратить своё время и внимание, и найти причину и потенциальное решение
но если я уже видел проблему, почему бы самому не посмотреть глубже, потратить какое-то время на расследование и прикинуть варианты решений. и в результате прийти в чатик уже не с проблемой, а с каким-то решением!
- понятно, что расследование может занять больше нескольких минут
- понятно, что решение может быть тоже не простое или даже несовсем правильное
в этих случая включаются уже устоявшиеся процессы в команде; но базовый принцип остаётся — не рассчитывать, что в последний момент прилетят орлы и решат все проблемы
иными словами, приходи с решением, а не проблемой!
🔥11👍6❤2
🤑 yet another zarplaty
классный пример коллаборации:
Саша Варламов собрал парсер и визуализацию
https://t.me/data_bar/60
а Никита это дело автоматизировал
https://t.me/joni_in_web/21
в результате получаем работающий проект и возможность посмотреть живую аналитику зарплат — на скрин вынес кусочек деша с фильтром по аналитике.
что мне нравится в подобных проектах:
1. проактивность — сам придумал, сам спроектировал, сам затащил, сам отчитался в блог
2. коллаборация — организоваться вдвоём гораздо сложнее, чем сделать одному, но эффект может быть круче
3. полезность, направленная наружу: когда решал свою задачу, а польза — всем
в общем, смотрите деш и ставьте лайки Саше с Никитой)
классный пример коллаборации:
Саша Варламов собрал парсер и визуализацию
https://t.me/data_bar/60
а Никита это дело автоматизировал
https://t.me/joni_in_web/21
в результате получаем работающий проект и возможность посмотреть живую аналитику зарплат — на скрин вынес кусочек деша с фильтром по аналитике.
что мне нравится в подобных проектах:
1. проактивность — сам придумал, сам спроектировал, сам затащил, сам отчитался в блог
2. коллаборация — организоваться вдвоём гораздо сложнее, чем сделать одному, но эффект может быть круче
3. полезность, направленная наружу: когда решал свою задачу, а польза — всем
в общем, смотрите деш и ставьте лайки Саше с Никитой)
👍22❤12🔥5
🐤 джуны, 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 — для этого просто надо было написать письмо напрямую СЕО и просто попросить.
⌘
при этом инженеры — не основная профессия, которая пользуется аи-тулзами: помимо них там продакты, аналитики, сейлзы и, конечно, саппорт.
почти для каждого инструмента внутри Шопифай есть MCP сервер и инструкция как его подключить к своему Курсору.
⌘
про найм стажёров
- в прошлый семестр (?) Шопифай нанял 25 стажёров
- Farhan уговорил своего СЕО в следующий семестр нанятьноль 1000 (!) стажёров
при этом на собесах разрешается использовать любые помогаторы. а скорее даже поощряется! подразумевается, что кандидат идёт в комплекте с ai-агентом и умеет пользоваться этими новыми технологиями — без них он просто отстанет от будущих коллег
логика для такого найма простая — Farhan видит, что новое поколение думает по-другому. они уже буквально ai-native, они учатся и заканчивают вузы, когда chatgpt уже стал нормой, поэтому могут предложить нестандартные решения для задач.
и само наличие таких людей в командах помогает «старичкам» узнавать новое и где-то по-другому смотреть на свой опыт.
в общем, Шопифай делает ставку на ai-стажёров
подкаст есть на ютубе
https://youtu.be/u-3IILWQPRM
@data_days
в интернетах есть тезис, что с внедрением 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 уговорил своего СЕО в следующий семестр нанять
при этом на собесах разрешается использовать любые помогаторы. а скорее даже поощряется! подразумевается, что кандидат идёт в комплекте с ai-агентом и умеет пользоваться этими новыми технологиями — без них он просто отстанет от будущих коллег
логика для такого найма простая — Farhan видит, что новое поколение думает по-другому. они уже буквально ai-native, они учатся и заканчивают вузы, когда chatgpt уже стал нормой, поэтому могут предложить нестандартные решения для задач.
и само наличие таких людей в командах помогает «старичкам» узнавать новое и где-то по-другому смотреть на свой опыт.
в общем, Шопифай делает ставку на ai-стажёров
подкаст есть на ютубе
https://youtu.be/u-3IILWQPRM
@data_days
2❤8👍5🔥3👀1
NewHR в очередной — уже шестой! — раз проводит опрос про работу аналитиков
я бы тоже прошёл, но я, к сожалению, я не аналитик
если тоже любите читать результаты таких исследований, можно инвестировать 20 минут в опрос
новый опрос за 2025 год тут
я бы тоже прошёл, но я, к сожалению, я не аналитик
если тоже любите читать результаты таких исследований, можно инвестировать 20 минут в опрос
новый опрос за 2025 год тут
❤1👍1🔥1
🎧 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
послушал подкаст с СТО платформы данных Т-Банка
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
1❤7👍4🔥2
🤓 Martin Fowler в гостях Pragmatic Engineer
https://youtu.be/CQmI4XKTa0U
Мартину уже за 60 лет, из которых он 40 с лишним считает себя инженером; когда опыт исчисляется десятками, то накапливается тот уровень насмотренности, когда можно сравнивать эпохи и видеть глобальные тенденции
⌘⌘⌘
по своему масштабу Мартин сравнивает нынешний скачок с переходом программистов с ассемблера на языки более высокого уровня
сам Мартин не имеет ничего против вайбкодинга как такового (тут он понимает «вайбкодинга» именно как безоглядное принятие любого результата ллм-ки без глубокого осознания написанного), однако чётко ограничивает зону его возможностей: небольшие проекты, прототипы на выброс и т.д.
главный недостаток слепого вайбкодинга — отсутствие цикла обратной связи. не пропуская через себя этот код, нет процесса обучения. новые знания не налипают и не копятся
получается вайбкодер через год останется ровно с таким же уровнем и потом его сменит просто другой вайбкодер (помоложе); или просто следующее поколение агентов, которым не нужна будет «простилка» между клавиатурой и креслом
⌘⌘⌘
при этом в прототипировании аи-помощник показывает небывалые приросты в продуктивности. приводят пример инженера из Антропика, который за 2 дня собрал 20 прототипов, итеративно проверяя и валидируя их об команду.
здесь быстрый цикл обратной связи помог им сразу на практике осознать простанство потенциальных вариантов и найти подходящие векторы для развития, отбросив остальные
⌘⌘⌘
ещё одна проблема ллм-ок — полная неспособность решить задачу «переименования класса»; по своему дизайну она скорее перепишет половину кодовой базы, чем поправит в трёх местах нужное название
при этом современные иде уже давно научились это делать, правда со своей подкапотной магией (которой, видимо, и не хватает ллм-кам)
⌘⌘⌘
общий подход к результатам работы моделей — ничему не верить, всё проверять; вдумчиво читать, внимательно вникать, нещадно тестировать, чтобы добавить чуток детерменированности их безудержной креативности.
и тогда действительно можно получать какой-то профит от совместной работы
https://youtu.be/CQmI4XKTa0U
Мартину уже за 60 лет, из которых он 40 с лишним считает себя инженером; когда опыт исчисляется десятками, то накапливается тот уровень насмотренности, когда можно сравнивать эпохи и видеть глобальные тенденции
⌘⌘⌘
по своему масштабу Мартин сравнивает нынешний скачок с переходом программистов с ассемблера на языки более высокого уровня
сам Мартин не имеет ничего против вайбкодинга как такового (тут он понимает «вайбкодинга» именно как безоглядное принятие любого результата ллм-ки без глубокого осознания написанного), однако чётко ограничивает зону его возможностей: небольшие проекты, прототипы на выброс и т.д.
главный недостаток слепого вайбкодинга — отсутствие цикла обратной связи. не пропуская через себя этот код, нет процесса обучения. новые знания не налипают и не копятся
получается вайбкодер через год останется ровно с таким же уровнем и потом его сменит просто другой вайбкодер (помоложе); или просто следующее поколение агентов, которым не нужна будет «простилка» между клавиатурой и креслом
⌘⌘⌘
при этом в прототипировании аи-помощник показывает небывалые приросты в продуктивности. приводят пример инженера из Антропика, который за 2 дня собрал 20 прототипов, итеративно проверяя и валидируя их об команду.
здесь быстрый цикл обратной связи помог им сразу на практике осознать простанство потенциальных вариантов и найти подходящие векторы для развития, отбросив остальные
⌘⌘⌘
ещё одна проблема ллм-ок — полная неспособность решить задачу «переименования класса»; по своему дизайну она скорее перепишет половину кодовой базы, чем поправит в трёх местах нужное название
при этом современные иде уже давно научились это делать, правда со своей подкапотной магией (которой, видимо, и не хватает ллм-кам)
⌘⌘⌘
общий подход к результатам работы моделей — ничему не верить, всё проверять; вдумчиво читать, внимательно вникать, нещадно тестировать, чтобы добавить чуток детерменированности их безудержной креативности.
и тогда действительно можно получать какой-то профит от совместной работы
YouTube
How AI will change software engineering – with Martin Fowler
Martin Fowler is one of the most influential people within software architecture, and the broader tech industry. He is the Chief Scientist at Thoughtworks and the author of Refactoring and Patterns of Enterprise Application Architecture, and several other…
❤6👍6🔥3
✍️ о код-ревью
у нас в команде в прод только через пулл-реквесты и каждый пулл-реквест должно посмотреть двое коллег. моя личная статистика за 2025 год показывает 430 проведённых код-ревью. сложились какие-то мысли по этому поводу, ниже пытаюсь собрать их вместе.
⌘ зачем вообще нужно код-ревью
+ это вторая пара глаз с иным контекстом и уровнем погружения: автор и ревьюер смотрят на код в разных когнитивных режимах → ловятся разные ошибки
+ передача знаний в рамках команды: «применяем вот такие паттерны, а вот так не делаем» → в среднем качестве кода постепенно улучшается
+ барьер против энтропии и деградации кодовой базы: без должного присмотра любой проект постепенно превращается в трудно поддерживаемое болото
⌘ как бывает без код ревью
когда команда небольшая, да ещё и допустим без большого опыта, то большой соблазн поспешить с реализацией или смалодушничать при проектировании → в результате получается нагромождение модулей, которые через время проще сжечь, чем исправить
⌘ как задавать вопросы на код-ревью
+ открытые вопросы лучше чётких предложений — во-первых, ревьюер сам можем не осознать что здесь происходит, а, во-вторых,
+ любой код может быть написан множеством способов — прежде чем предложить что-то поправить, надо понять а точно ли оно будет объективно лучше? или просто «ревьюер привык писать по-другому»
+ спорные места должны быть выведены в общие архитектурные соглашения на команду (какие линтеры используем, как ставим отступы и пр.)
⌘ эффект от код ревью
− растёт время на разработку: уходит время на найти ревьюеров и иногда пройти несколько итераций над кодом
+ твои типичные вопросы на код-ревью возвращаются в твои пулл-реквесты — нарабатывается паттерны и начинаешь думать про типовые кейсы заранее
+ повышение качества среднего пулл-реквеста — на ревью не поступает откровенно плохих пулл-реквестов, где какой-то треш или забыли подумать
у нас в команде в прод только через пулл-реквесты и каждый пулл-реквест должно посмотреть двое коллег. моя личная статистика за 2025 год показывает 430 проведённых код-ревью. сложились какие-то мысли по этому поводу, ниже пытаюсь собрать их вместе.
⌘ зачем вообще нужно код-ревью
+ это вторая пара глаз с иным контекстом и уровнем погружения: автор и ревьюер смотрят на код в разных когнитивных режимах → ловятся разные ошибки
+ передача знаний в рамках команды: «применяем вот такие паттерны, а вот так не делаем» → в среднем качестве кода постепенно улучшается
+ барьер против энтропии и деградации кодовой базы: без должного присмотра любой проект постепенно превращается в трудно поддерживаемое болото
⌘ как бывает без код ревью
когда команда небольшая, да ещё и допустим без большого опыта, то большой соблазн поспешить с реализацией или смалодушничать при проектировании → в результате получается нагромождение модулей, которые через время проще сжечь, чем исправить
⌘ как задавать вопросы на код-ревью
+ открытые вопросы лучше чётких предложений — во-первых, ревьюер сам можем не осознать что здесь происходит, а, во-вторых,
+ любой код может быть написан множеством способов — прежде чем предложить что-то поправить, надо понять а точно ли оно будет объективно лучше? или просто «ревьюер привык писать по-другому»
+ спорные места должны быть выведены в общие архитектурные соглашения на команду (какие линтеры используем, как ставим отступы и пр.)
⌘ эффект от код ревью
− растёт время на разработку: уходит время на найти ревьюеров и иногда пройти несколько итераций над кодом
+ твои типичные вопросы на код-ревью возвращаются в твои пулл-реквесты — нарабатывается паттерны и начинаешь думать про типовые кейсы заранее
+ повышение качества среднего пулл-реквеста — на ревью не поступает откровенно плохих пулл-реквестов, где какой-то треш или забыли подумать
1👍15❤5🔥2👎1
📢 ищем дата-коллег к себе в Яндекс Финтех
→ дата инженеры
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
буду рад ответить на вопросы в комментах или так же в личке
→ дата инженеры
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❤14👍4🔥3👎2
data будни
✍️ о код-ревью у нас в команде в прод только через пулл-реквесты и каждый пулл-реквест должно посмотреть двое коллег. моя личная статистика за 2025 год показывает 430 проведённых код-ревью. сложились какие-то мысли по этому поводу, ниже пытаюсь собрать их…
📝 о код-ревью (часть 2)
вижу тема ↑ код-ревью хорошо зашла — продолжаю накидывать
⌘ разные авторы — разные вопросы на ревью
+ во время онбордина на первые ревью обычно приходит тьма комментариев; чтобы проверить, что автор достаточно погрузился в новый проект, приходится спрашивать с самых банальностей: «почему тут за Т-2», «почему тут снепшото, а не апсёрт?» и т.д.
+ со временем у авторов набирается «репутация» — вопросы переходят на следующий уровень абстракций (или вовсе пропадают с типовых решений)
⌘ размер имеет значение
− гигантский ПР на 500+ строк кода, затрагивающий множество модулей, имеет шанс погрязнуть в процессе ревью (не говоря уже про увеличенную вероятность пропустить багульку в прод)
+ а вот маленький атомарный ПР легко читать и требует адекватного количества когнитивной энергии ревьюера — а значит не вызывает сопротивления и обычно сходится предсказуемо быстро
⌘ не всегда есть «правильный» ответ
+ иногда вопрос — это предложение к дискуссии или просто любопытство почему выбран именно такой подход
+ хочется проверить, что автор продумал основные кейсы в предлагаемом решении
⌘ проблемы код-ревью
− неконсистентность от ревью к ревью: даже один ревьюер может спросить разное, не говоря уже о нескольких
− код-ревью не случается само — оно занимает время и тратит когнитивную энергию; это буквально конвейер и его надо явно планировать в своём календаре (получается всем в команде)
− ну и в целом — растёт тайм-ту-маркет, в задачу надо закладывать время на схождение код-ревью
⌘ ожидания от код-ревью
+ код-ревью не должно быть узким горлышком — положительные эффекты складываются, когда вся команда ревьюит друг-друга (не только один тимлид по ночам и выходным)
+ LGTM — это тоже ответственность; если код падает прям сразу после релиза — вопросики будут как к автору, так и к ревьюеру;
+ всем в команде (включая ревьюера) потом поддерживать этот код — в общих интересах поддерживать кодовую базу в хорошем виде
⌘ пускай потеет машина
+ проверять синтаксис и опечатки должны машины, а не белковые мешки; поэтому эффективнее настроить линтеры, тесты, вот это всё
+ если команда уже сформировала код-стайл и обсудила архитектурные подходы, то будет проще формализовать и базовые проверки
+ а дальше пускай уже и аи-шные агенты ревьюят код помимо базовых линтеров и тестов — эти уже не только формально, но и по смыслу смогут накидать на вентилятор
---
тем временем мы продолжаем искать дата-коллег — ваши репосты нам очень помогут
вижу тема ↑ код-ревью хорошо зашла — продолжаю накидывать
⌘ разные авторы — разные вопросы на ревью
+ во время онбордина на первые ревью обычно приходит тьма комментариев; чтобы проверить, что автор достаточно погрузился в новый проект, приходится спрашивать с самых банальностей: «почему тут за Т-2», «почему тут снепшото, а не апсёрт?» и т.д.
+ со временем у авторов набирается «репутация» — вопросы переходят на следующий уровень абстракций (или вовсе пропадают с типовых решений)
⌘ размер имеет значение
− гигантский ПР на 500+ строк кода, затрагивающий множество модулей, имеет шанс погрязнуть в процессе ревью (не говоря уже про увеличенную вероятность пропустить багульку в прод)
+ а вот маленький атомарный ПР легко читать и требует адекватного количества когнитивной энергии ревьюера — а значит не вызывает сопротивления и обычно сходится предсказуемо быстро
⌘ не всегда есть «правильный» ответ
+ иногда вопрос — это предложение к дискуссии или просто любопытство почему выбран именно такой подход
+ хочется проверить, что автор продумал основные кейсы в предлагаемом решении
⌘ проблемы код-ревью
− неконсистентность от ревью к ревью: даже один ревьюер может спросить разное, не говоря уже о нескольких
− код-ревью не случается само — оно занимает время и тратит когнитивную энергию; это буквально конвейер и его надо явно планировать в своём календаре (получается всем в команде)
− ну и в целом — растёт тайм-ту-маркет, в задачу надо закладывать время на схождение код-ревью
⌘ ожидания от код-ревью
+ код-ревью не должно быть узким горлышком — положительные эффекты складываются, когда вся команда ревьюит друг-друга (не только один тимлид по ночам и выходным)
+ LGTM — это тоже ответственность; если код падает прям сразу после релиза — вопросики будут как к автору, так и к ревьюеру;
+ всем в команде (включая ревьюера) потом поддерживать этот код — в общих интересах поддерживать кодовую базу в хорошем виде
⌘ пускай потеет машина
+ проверять синтаксис и опечатки должны машины, а не белковые мешки; поэтому эффективнее настроить линтеры, тесты, вот это всё
+ если команда уже сформировала код-стайл и обсудила архитектурные подходы, то будет проще формализовать и базовые проверки
+ а дальше пускай уже и аи-шные агенты ревьюят код помимо базовых линтеров и тестов — эти уже не только формально, но и по смыслу смогут накидать на вентилятор
---
тем временем мы продолжаем искать дата-коллег — ваши репосты нам очень помогут
Telegram
data будни
📢 ищем дата-коллег к себе в Яндекс Финтех
→ дата инженеры
https://yandex.ru/jobs/vacancies/inzhener-dannih-v-finteh-36637
→ дата-партнёры (они же системные аналитики двх)
https://yandex.ru/jobs/vacancies/analitik-dwh-v-finteh-27815
это прям в нашу команду…
→ дата инженеры
https://yandex.ru/jobs/vacancies/inzhener-dannih-v-finteh-36637
→ дата-партнёры (они же системные аналитики двх)
https://yandex.ru/jobs/vacancies/analitik-dwh-v-finteh-27815
это прям в нашу команду…
1❤4👍4🔥3
data будни pinned «📢 ищем дата-коллег к себе в Яндекс Финтех → дата инженеры https://yandex.ru/jobs/vacancies/inzhener-dannih-v-finteh-36637 → дата-партнёры (они же системные аналитики двх) https://yandex.ru/jobs/vacancies/analitik-dwh-v-finteh-27815 это прям в нашу команду…»
🦀 Clawdbot / Moltbot / OpenClaw
там похоже намечается очередной качественный скачок аи-строения: австрийский программист написал автономного (?) ии-агента… и понеслось
сам автор бота не случайный мамкин вайбкодер — он начинал ещё с веб-приложений в начале 2000-х и потом перешёл на приложения айос для первого айфона.
потом запилил как побочный продукт PSPDFKit — низкоуровневый парсер и рендере пдф-ок; продукт быстро стал приносить денег больше, чем основная работа и он переключился на него фултайм. потихоньку стартап разросся до 70 человек.
продукт оказался достаточно востребованным, чтобы его покупали большие компании, и при этом достаточно сложным, чтобы они не могли его просто сделать внутри
отсюда у автора большой опыт в построении сложных технических продуктов с большим количеством разношёрстных пользователей — надо успевать развивать продукт, ничего не поломав.
⌘⌘⌘
потом он (традиционно) выгорел и ушёл с радаров на три года, ничего не делал, ничем не занимался; и всё, чтобы «вернуться в интернет» в 2025-м —прямо на рассвете ии-агентов
тут он офигел от новой технологии и по первым ощущениям от продукта он вспомнил все хорошие впечатления от программирования
в итоге к осени он врубился в технологию настолько, что она стала для него «запойной»: работает на десятью пет-проектами сразу и 10 разных агентах / терминалах
⌘⌘⌘
поинты автора про подход к агентам:
⌘ замкнуть цикл обратной связи: задача → план → исполнение → отладка → тестирование → сверка с исходной задачей — всё это агент делает сам в бесконечной итерации, пока результат не достигнут
⌘ «новое» программирование — это верхнеуровневый дизайн, а не написание кода
⌘ из аи-агенты можно собирать локальные мини-команды (и не отдельные тулзы)
⌘ а синьорные инженеры — это теперь аи-менеджеры таких локальных команд для разработки
⌘⌘⌘
сам Moltbot / OpenClaw выглядит как проект на стыке аи- и арт-перфоманса
автономный агент, которому явно дают доступ к локальной системе — это что-то за гранью привычного
причём не каждый догадывается или может позволить себе отдельный мак-мини для инстанса бота — и они грузят их прям на своей основной тачке
с другой стороны, эти эмерджентный и удивительные свойства агента проявляются как раз на богатой почве развитого локального окружения; на стерильной системе у него не будет истории переписки в мессенджер и почте, не на что смотреть)
⌘⌘⌘
агент имеет доступ к своим настройкам и исходному коду
может менять свою конфигурацию, дописывать новые модули
так, у бота не было модуля работы с голосовыми сообщениями, но, получив однажды голосяшку от автора, он через какое-то время дал релевантный ответ (оказалось, он прочитал хедер сообщения, нашёл нужный модуль, установил его и смог декдодировать пришедшее ранее сообщение)
🤯
там похоже намечается очередной качественный скачок аи-строения: австрийский программист написал автономного (?) ии-агента… и понеслось
формат горячих новостей не мой любимый жанр, но это залетело в моё инфополе с трёх разных сторон:
+ Самат Галимов накидал ссылок для понимания контекста
https://t.me/ctodaily/1995
+ Pragmatic Engineer выпустил интервью с автором
https://youtu.be/8lF7HmQ_RgY
+ ребята из Шмит16 собрались вместе где-то на Бали и скупают все доступные мак-мини, чтобы устроить ферму из таких аи-агентов
сам автор бота не случайный мамкин вайбкодер — он начинал ещё с веб-приложений в начале 2000-х и потом перешёл на приложения айос для первого айфона.
потом запилил как побочный продукт PSPDFKit — низкоуровневый парсер и рендере пдф-ок; продукт быстро стал приносить денег больше, чем основная работа и он переключился на него фултайм. потихоньку стартап разросся до 70 человек.
продукт оказался достаточно востребованным, чтобы его покупали большие компании, и при этом достаточно сложным, чтобы они не могли его просто сделать внутри
отсюда у автора большой опыт в построении сложных технических продуктов с большим количеством разношёрстных пользователей — надо успевать развивать продукт, ничего не поломав.
⌘⌘⌘
потом он (традиционно) выгорел и ушёл с радаров на три года, ничего не делал, ничем не занимался; и всё, чтобы «вернуться в интернет» в 2025-м —прямо на рассвете ии-агентов
тут он офигел от новой технологии и по первым ощущениям от продукта он вспомнил все хорошие впечатления от программирования
в итоге к осени он врубился в технологию настолько, что она стала для него «запойной»: работает на десятью пет-проектами сразу и 10 разных агентах / терминалах
⌘⌘⌘
поинты автора про подход к агентам:
⌘ замкнуть цикл обратной связи: задача → план → исполнение → отладка → тестирование → сверка с исходной задачей — всё это агент делает сам в бесконечной итерации, пока результат не достигнут
⌘ «новое» программирование — это верхнеуровневый дизайн, а не написание кода
⌘ из аи-агенты можно собирать локальные мини-команды (и не отдельные тулзы)
⌘ а синьорные инженеры — это теперь аи-менеджеры таких локальных команд для разработки
⌘⌘⌘
сам Moltbot / OpenClaw выглядит как проект на стыке аи- и арт-перфоманса
автономный агент, которому явно дают доступ к локальной системе — это что-то за гранью привычного
причём не каждый догадывается или может позволить себе отдельный мак-мини для инстанса бота — и они грузят их прям на своей основной тачке
с другой стороны, эти эмерджентный и удивительные свойства агента проявляются как раз на богатой почве развитого локального окружения; на стерильной системе у него не будет истории переписки в мессенджер и почте, не на что смотреть)
⌘⌘⌘
агент имеет доступ к своим настройкам и исходному коду
может менять свою конфигурацию, дописывать новые модули
так, у бота не было модуля работы с голосовыми сообщениями, но, получив однажды голосяшку от автора, он через какое-то время дал релевантный ответ (оказалось, он прочитал хедер сообщения, нашёл нужный модуль, установил его и смог декдодировать пришедшее ранее сообщение)
🤯
❤3👍1🔥1
📁 про культуру ведения тикетов
продолжаю рассказывать про внутрянку нашей команды, привлекая ваше внимание к активным вакансиям >_>
думаю, все видели тикеты, прочитав которые, осталось непонятным что́ надо сделать; или задачи, где ты вроде сделал что было написано, но оказалось, что нужно было не то и не так ¯\_(ツ)_/¯
мы в команде стараемся придерживаться культуры ведения задач — попробую описать как я это вижу
⌘⌘⌘
начнём с того, что создать хороший тикет - это отдельная работа; чтобы понятно описать что надо сделать, надо как минимум представлять проблему и целевое решение
есть базовый паттерн, которого мы придерживаемся:
⁃ контекст
⁃ проблема
⁃ что сделать
⁃ допматериалы
небольшие тикеты могут пропускать 1-2 пункта; а большие эпики будут наоборот побольше
⌘⌘⌘
«хорошие» задачи формулируются через глаголы:
сделать …, добавить …, исправить …, пересчитать …
однозначно указан объект изменения: таблица, таск, модуль и пр.
есть перечень связанных действий: в конце …сделать миграцию, …пересчитать историю, и пр.
⌘⌘⌘
задачи на имплементацию проходят через общее техревью на входе, чтобы вместе посмотреть и проверить:
⁃ проверить, что мы в принципе хотим это делать
(тут бинарно; пока без приоритетов)
⁃ задача описана понятно
⁃ ожидаемый результат считывается однозначно
⁃ (опционально) докапывается технических деталей
цель такого пре-ревью проверить, что автор достаточно подумал про задачу и потенциальный исполнитель прочитает её ожидаемо
паттерны задач помогают консистентно формулировать задачи внутри команды, а так же уменьшают количество догадок и уточнений на этапе разработки
⌘⌘⌘
если задача занимает больше нескольких дней, то внутри ожидаются отбивки по текущему статусы; размер отбивок пропорционален масштабу задачи
причём не абстрактный статус «продолжаю работать», а короткий апдейт по фактам: сделано Х / осталось сделать У / открытые вопросы и блокеры …
⌘⌘⌘
в конце каждого тикет исполнитель оставляет резюме о проделанной работе
«сделал таск, пересчитал историю, вот ссылка на итоговый объект» — всё что нужно знать о задаче, осознанно принять результат (и при необходимости вспомнить через полгода что тут было вообще)
статусы и резюмешки повышают прозрачность работы для сторонних наблюдателей: заказчиков, тимлидов, а так же для себя из будущего
прозрачность ведения задач особенно важна при ведении инцидентов — для них помимо резюме дополнительно надо сразу заполнить пост-морфем
(инцидент-менеджемент у нас тоже есть — про него в другой раз)
⌘⌘⌘
лайк-шер-репост
👉 https://t.me/data_days/400
продолжаю рассказывать про внутрянку нашей команды, привлекая ваше внимание к активным вакансиям >_>
> важный дисклеймер: это не я, это всё наш техлид Кирилл (я тут только документирую и выношу)
думаю, все видели тикеты, прочитав которые, осталось непонятным что́ надо сделать; или задачи, где ты вроде сделал что было написано, но оказалось, что нужно было не то и не так ¯\_(ツ)_/¯
мы в команде стараемся придерживаться культуры ведения задач — попробую описать как я это вижу
⌘⌘⌘
начнём с того, что создать хороший тикет - это отдельная работа; чтобы понятно описать что надо сделать, надо как минимум представлять проблему и целевое решение
есть базовый паттерн, которого мы придерживаемся:
⁃ контекст
⁃ проблема
⁃ что сделать
⁃ допматериалы
небольшие тикеты могут пропускать 1-2 пункта; а большие эпики будут наоборот побольше
⌘⌘⌘
«хорошие» задачи формулируются через глаголы:
сделать …, добавить …, исправить …, пересчитать …
однозначно указан объект изменения: таблица, таск, модуль и пр.
есть перечень связанных действий: в конце …сделать миграцию, …пересчитать историю, и пр.
⌘⌘⌘
задачи на имплементацию проходят через общее техревью на входе, чтобы вместе посмотреть и проверить:
⁃ проверить, что мы в принципе хотим это делать
(тут бинарно; пока без приоритетов)
⁃ задача описана понятно
⁃ ожидаемый результат считывается однозначно
⁃ (опционально) докапывается технических деталей
цель такого пре-ревью проверить, что автор достаточно подумал про задачу и потенциальный исполнитель прочитает её ожидаемо
паттерны задач помогают консистентно формулировать задачи внутри команды, а так же уменьшают количество догадок и уточнений на этапе разработки
⌘⌘⌘
если задача занимает больше нескольких дней, то внутри ожидаются отбивки по текущему статусы; размер отбивок пропорционален масштабу задачи
причём не абстрактный статус «продолжаю работать», а короткий апдейт по фактам: сделано Х / осталось сделать У / открытые вопросы и блокеры …
⌘⌘⌘
в конце каждого тикет исполнитель оставляет резюме о проделанной работе
«сделал таск, пересчитал историю, вот ссылка на итоговый объект» — всё что нужно знать о задаче, осознанно принять результат (и при необходимости вспомнить через полгода что тут было вообще)
статусы и резюмешки повышают прозрачность работы для сторонних наблюдателей: заказчиков, тимлидов, а так же для себя из будущего
прозрачность ведения задач особенно важна при ведении инцидентов — для них помимо резюме дополнительно надо сразу заполнить пост-морфем
(инцидент-менеджемент у нас тоже есть — про него в другой раз)
⌘⌘⌘
лайк-шер-репост
👉 https://t.me/data_days/400
❤5🔥4👍3👌1