https://platformcon.com/

Вот тут еще наткнулся на виртуальную конференцию для тех, кто делает платформы.

Есть парочка интересных докладов, но очень не хочется завышать ожидания от них. На DRECon тоже так было, а в итоге такой воды налили…. =(

- Код чаще читается, чем пишется!
- Важней не код, а как ты коммуницируешь с людьми!
- Да я свой билд жду по 40 минут, потому что на М1 не пересел!


Мы тратим время на написание кода, его чтение, дебаг и тушение пожаров, общение с коллегами в зуме и с коллегами на кухне с кофе. Не одна сотня копий сломана на теме “На что разработчики тратят время?”.
Ребята из ReTool (клевый low-code инструмент для создания внутренних инструментов) провели опрос под названием “The State of Engineering Time”, в котором пытались понять, на что больше всего тратится времени у инженеров.

https://retool.com/reports/state-of-engineering-time-2022/

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

Так, я тут понял, что я так и не рассказал, где я работаю, хотя часть людей знает про это.

С января этого года я работаю в Gett. Ага, том самом Gett, который 31 мая окончательно ушел из России (у нас даже в слаке есть канал #ru-shuthdown).
Причины, почему я уходил из Semrush я уже описывал вот тут, а вот причины, по которым я пошел в Gett:

- Платформенная команда. Теперь рядом со мной и вокруг меня другие DE, а значит можно выкачать опыт из них.
- Распределенная, международная команда. У нас ребята из РФ, Израиля, Болгарии, UK, а значит постоянное общение на английском
- Размер и нагрузка данных. Данных стало гораздо больше, а значит сложней и интересней решения
- Новый стек, новые тулзы. Теперь я знаю больше, а значит $$$

Вообще весь путь в Gett был забавным и с неожиданными поворотами, собесами в несколько компаний одновременно, HR, которые обещали “мы за тебя поборемся =)”, которые вылились в salary negotiation, смены приоритетов среди компаний и вот это все. В итоге все вышло вот так и я рад, что так вышло.
Кстати, fun fact: за весь процесс собеседования я не написал ни строчки кода. И никаких leetcode не было. И в Semrush, кстати, тоже ☺️

Что по стеку?
Python, SQL, Trino, K8S & Docker, Spark, Jenkins, GitHub, Jira/Confluence

Что классного?
Довольно много свободы и простора, относительно свободный график, оба моих менеджера клевые ребята и у меня с ними наладился контакт.

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


Я приходил как Senior Data Engineer, но в результате сами знаете чего + небольшого изменения бизнес целей и KPI компании, нас покинули люди, поэтому мне предложили подхватить одно направление.
Поэтому со вчерашнего дня я ML & Data Ops Lead 🔥, буду выгребать теперь еще и тут, кроме дата инженерных задач.

Как вы мб не знаете, лычки для меня не имеют значения, я всегда придерживался позиции Дяди Бена из Человека-Паука: “With great responsibility power comes great money responsibility”.

I expect a “senior” engineer to be a mature engineer

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

Мне на глаза попалась прекрасная статья “On being senior engineer” и я согласен со всеми принципами, которые в ней написаны. А следовать этим принципам можно в любом возрасте.

- seek out constructive criticism of their designs
- understand the non-technical areas of how they are perceived
- do not shy away from making estimates and are always trying to get better at it
- have an innate sense of anticipation, even if they don’t know they do
- understand that not all of their projects are filled with rockstar-on-stage work
- lift the skills and expertise of those around them
- understand the difference between mentorship and sponsorship, and develop a habit of the latter
- make their trade-offs explicit when making judgments and decisions
- don’t practice CYAE (“Cover Your Ass Engineering”)
- are empathetic.
- don’t make empty complaints
- are aware of cognitive biases

Сама статья вот: https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/

https://www.youtube.com/watch?v=N8SJPb5JpOA

Год назад у Netflix была вот такая реклама для поиска DE инженеров.

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

Или это все не работает, пожалуйста, напишите мне в LinkedIn что-то в стиле:
“Делаем ретейл-сервис. Команда 8 человек, один лид, один менеджер и 6 инженеров. Стек: Python, Airflow, AWS, Redshift, Tableu. Платим 8000 зеленых”

https://www.amazon.com/Fundamentals-Data-Engineering-Robust-Systems/dp/1098108302/

Вот такая вот книженция от O’Reilly доступна для предзаказа на Amazon.
Будет выпущена в июле/августе.

Автор: https://www.linkedin.com/in/josephreis/

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

Очень согласен с автором статьи, которая мне попалась на глаза на этой неделе - “Professional Development is a choice”. Поэтому вам нужен план!
Типичные вопросы этого плана:

1. Что у меня хорошо получается?
2. Что мне нравится делать?
3. За что мне платят деньги?
4. На какие аспекты мне необходимо обратить внимание?
5. А что я хочу изучить?
6. Цели на 1-3 года?
7. Цели на 3-5 лет?
8. Цели на 5-10 лет?

Да-да, тот самый топорный вопрос: “А кем вы видите себя через 5 лет?” - на самом деле не топорный, а оч тонкий. Он говорит о том, что вы можете в стратегическое планирование. И да, стратегии меняются, это нормально!
У меня в нефтянке был начальник, который сказал однажды фразу, которая заела мне навсегда: “If you fail to plan, you plan to fail”.

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

Статья → [https://alexchesser.medium.com/professional-development-is-a-choice-e90fb8719259], а подискутировать приглашаю в комменты.

Я тут выше писал, что обе свои позиции (в Semrush и в Gett) я получил не написав ни строчки кода. Конечно, это говорит о том, что я очень клевый и задавил популярностью и авторитетом 😋 (сарказм)
На деле это говорит о том, что компании понимают, что hiring is broken, а LeetCode-style интервью не имеют ничего общего с работой.

Опережая очевидный вопрос: для некоторых компаний это подходит. Потому что у них на входе огромная воронка людей, желающих работать у них, потому что $$$, HR бренд или бесплатные обеды в офисе.
Да, они хорошо скалируются на FAANG компании.
Да, они относительно редко дают false-positive (когда мы наняли человека, который заботал литкод, но на деле оказалось, что он не очень)

Но когда компания не набирает безумными темпами, контролирует скорость роста команды и вообще ищет человека, который им идеально подходит, она не страдает литкодом. Team-fit, System Design, Rational & Critical Thinking становятся существенно важней.

К чем это я: хочу поделиться прекрасной статьей (коих, на самом деле, на эту тему дофига) про то, почему LeetCode собеседования не очень https://fev.al/posts/leet-code/.
https://fev.al/posts/leet-code/

Ну, то есть если вы хотите попасть в FAANG и похожие компании, да, придется подчиниться правилам игры. Если нет, то базовые знания “алгоритмов” и стандартной библиотеки Python (а солидная часть Easy задач решается через collection) - это максимум, на который нужно упарываться.

Как говорится, не является индивидуальной инвестиционной рекомендацией (с)

https://www.youtube.com/watch?v=wl8FBpg4skQ&list=PLGudixcDaxY2LxjeHpZRtzq7miykjjFOn

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

https://dataproducts.substack.com/p/the-death-of-data-modeling-pt-1

Хех, как по живому. Встречал такое и не раз.
В статье рассказывается о том, что современная разработка сделала с моделированием данных. А именно: очень и очень быстро у нас все превращается в болото.

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

Дата Инженеры это челноки между теми, кто данные генерирует и “заказчиками”
Ага, какое-то DWH изначальное построили, а потом бегаем, пытаемся сметчить то, что нам приходит с тем, что нас просят. Расфокус, ибо “команд много, я один”, приводит к тому, что глубоко мы не знаем специфику потребителя данных.

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

Data is Reactive versus Active
Если честно, я не смог перевести это так, чтобы было емко и понятно =) В общем, вместо того, чтобы адаптировать модель и, возможно, где-то ее даже сильно переделать, с появлением новых запросов и источников, мы натягиваем сову на глобус и пытаемся сделать Франкенштейна.

Тут у Andreas Kretz (тот самый, который делает Академию https://learndataengineering.com/) вышел новый выпуск его “журнала” The Future of Data Engineering. Это 2 выпуск, за июнь.

Можете не тратить время на 21 страницу, вот выдержка самого интересного:
- Результаты исследования про будущее data janitors. В кратце: все будет хорошо, работы будет дофига, продолжим кодить на Python, сертификаты не нужны
- Промо постов и ютуб видосиков. Единственный интересный, как мне кажется, это про то, в чем проблема всех Data Engineer Roadmap статей, блогов и видосов. Сам видос посмотреть можно тут https://www.youtube.com/watch?v=bPPztQsk5ws

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

Приходите в комментарии к @ohmydataengineer, накидать автору (мне) в панамку за плохой контент (что ты тут нам бесполезное чтиво принес?)

Я не буду хитрым жуком и типа “я нашел эту статью сам, вот ссылка!”.
Случайно наткнулся на этот канал и конспекты больших статей - прямо очень топчинский контент. Хоть очень редко, но метко.

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

Подготовил конспект статьи от Shopify о сетапе Airflow на 10 тысяч DAG'ов со 150 тысячами запусков в день. Сэкономит вам время на прочтении и поможет освежить в памяти в будущем.

#briefly #airflow Airflow: scaling out recommendations by Shopify
https://telegra.ph/Airflow-scaling-out-recommendations-by-Shopify-06-03

What's inside:
— Cloud Storage vs Network File System.
— Metadata retention policy.
— Manifest file.
— Consistent distribution of load.
— Concurrency management.
— Using different execution environments.

Origin: Lessons Learned From Running Apache Airflow at Scale

Привет!
Меня не покидала мысль про расширение аудитории и в очередной раз мне про нее напомнили.
Я хочу доносить свои идеи про хороших инженеров, дата инженеринг и все вокруг этого до большего количества людей.
И кажется, 1000+ человек на русском языке - это отличный показатель, но постепенно наступает diminishing return (это я помню из игры в WoW, а никак не экономики 😁)

Можно, конечно, постить всякие мемосики, брать деньги за рекламу и вообще размазать фокус на все уровни, от тех, кто хочет войти в IT до матерых DBA, но мне не хочется делать ничего из этого.
Отсюда вылезает самый главный вопрос, который я задаю себе уже некоторое количество десятков раз - продолжить вести данный канал на русском языке или перевести его на английский? Паша Дуров говорит, что аудитория Telegram 700 миллионов, но чет мой пузырь состоит только из рускоязычных каналов….

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

https://habr.com/ru/company/jugru/blog/670018/

Какое-то время назад я постил пару статей (раз и два - https://news.1rj.ru/str/ohmydataengineer/210) на тему сеньорности и того, как вырасти в хорошего инженера. На глаза мне попалась еще одна статья на эту тему, но уже на русском (вообще, это был доклад на DotNet-конференции, там внутри есть ссылка на на его).

Интересный момент: заявление на скриншоте противоречит заявлению из второй статьи. Вот это поворот!

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

@ohmydataengineer

https://www.youtube.com/watch?v=srP-DkkJWRc

Так, в мае 2019 года я ходил в подкаст MoscowPython и тогда мы болтали про всякое. Выпуск, кстати, стал самым популярным среди всех выпусков подкаста.
Спустя 3 года я снова решил зайти в гости к своим друзьям, мы поболтали про ML & Data Ops, про мой карьерный путь и про то, как получать больше денег, при этом не прыгая с работы на работу. Конечно, не оч получилось поговорить про все детально, но, надеюсь, вам понравится.

Приходите кидаться помидорами в комменты сюда или к видео.

@ohmydataengineer

https://dataproducts.substack.com/p/datas-collaboration-problem

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

В погоне за всеми модными тулзами и growth, мы подзабили на модели, на архитектуру, на качество хранилища, закидав все деньгами. Не надо так!
Не тащите Modern Data Stack только потому, что он Modern…


@ohmydataengineer

https://habr.com/ru/post/671058/

И еще одна тема для жаркого спора про то, как выглядит хороший инженер. В последнем выпуске подкаста я вскольз затрагивал эту тему: чем больше вы вовлекаетесь в продукт, тем больше вас ценят и если это правильно использовать, то вам за это больше платят.
Я поддерживаю автора статьи за позицию “product engineer” - ты работаешь на благо продукта и гордись тем, что ты делаешь. Всегда старайся сделать это лучше и выгодней для продукта и компании.
Однако, в комментах есть люди (да и среди моих читателей тоже), которые придерживаются позиции “Моя хата с краю, дайте мне тикет нормально описанный, я отвечаю лишь за код, а все остальное - проблемы других людей”. Тоже валидная позиция.

Приходите в комментарии высказаться про то, манипуляция ли это со стороны компании или что-то иное?

@ohmydataengineer

ООООО! Гартнер выкатил “свежий” обзор текущих технологий и подходов в работе с данными, и это, если честно, очень смешно.
Самые забавные моменты, что мне бросились в глаза:

Data Mesh is obsolete. То у меня все лидеры мнений в линкедине постят про Data Mesh и Data Fabric, а то половина из этого, оказывается, уже устарела, даже не зайдя на хайп, а вторая летит в трубу.
Data Stewardship тоже устарело. Кхм, а не вы ли продвигали кровавому энтерпрайзу, что вам надо заводить Data Stewards?
Data Observability в самом начале пути..
Половина технологий - вообще какой-то странный набор хайпослов, ничего не имеющих общего с реальностью.
Поэтому, как только вам ваш CDO начинает задвигать что-то в стиле “Мы взяли 3-4 приложения из верхнего правого квадранта Гартнера”, это повод задуматься о текущем состоянии дел.


Ах, да. Data Engineering сейчас на самом “дне разочарования”.

@ohmydataengineer

https://blog.dataminded.com/why-rising-cloud-costs-are-the-silent-killers-of-data-platforms-52a98b371f28

Статья хоть и написана людьми ради продвижения своего продукта, однако в целом, очень правдивая. Snowflake, Databricks и все остальные платформы наглядно нам показывают, как быстро можно раздуть свой бюджет на овердофига тысяч долларов.
Несколько раз уже видел, как казалось бы несложные платформы и относительно простые ETL (а еще и интеграции всякие и другие cloud решения) очень быстренько кушают годовой бюджет.

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

@ohmydataengineer