Так, мне тут рассылка от DataTalks.Club (Это те ребята, которые делали Zoomcamp DE - https://news.1rj.ru/str/ohmydataengineer/172) принесла еще одну конференцию про DE - The ML Data Engineering Conference


Ссылка на регистрацию и темы на два дня - тут

А давайте поговорим еще разок про блоги и паблики?

Я для чтения и слежения за всякими блогами пользуюсь древней как Греция технологией под названием RSS. И очередной раз просматривая ленту Medium и Reddit по теме Data Engineering, бегло читая заголовки в поисках хорошей статьи или новости, я натыкаюсь на 856 статью про то, как начать пользоваться DBT, с десяток вопросов в стиле “Чем отличается Data Engineer от Big Data Engineer?” и т.д. И мне становится от этого грустно.

Потому что количество материала растет, а его качество - падает. Причем очень стремительно. Поэтому я решил, что нужно немножко почистить ленту, уменьшить количество источников, откуда приходит контент.

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

Все эти блоги про то, как быть хорошим инженером, просто классным специалистом. Не web developer, не software developer, не DE и не QA. А именно специалистом, то есть инженером с высоким уровнем технической подкованности, умеющим видеть проблему, предлагать решения, искать компромиссы, умеющим в софт скиллы и продукт.

Первая партия блогов выглядит вот так (потом будет еще):


The Pragmatic Engineer
Автор (в чатиках именуемый как *Венгр*) был EM в Uber, а сейчас полностью сосредоточен на своем блоге, который приносит ему денег больше, чем работа в Uber. Не зря эта рассылка № 1 в категории Tech на Substack.
Автор хорошо известен, например, по вот этому видео https://www.youtube.com/watch?v=h8Xpapy6I9E или вот этой https://newsletter.pragmaticengineer.com/p/perfect-storm-causing-a-hot-tech-hiring-market статье про рыночек.
https://blog.pragmaticengineer.com/ - это сам блог, но он там не очень часто пишет.
https://newsletter.pragmaticengineer.com - вот эта рассылка, несколько бесплатных статей, но много платного контента. Если автору написать в твиттер, даст 50% скидку. Вот только с оплатой из РФ будут проблемы, сами знаете.


The Senior Engineer Mindset
Вообще это книга https://swizec.com/senior-mindset, но если побродить по сайту, то можно подписаться на рассылку, а там уже приходят очень клевые и классные тексты.


From Junior to Senior
Это тоже книга https://www.learninpublic.org, но есть опция купить книгу с доступом в сообщество инженеров, оно средней активности, но довольно мотивирующее тебя развиваться и даже писать о том, что ты изучаешь. Кстати, вот тут еще видел подобное: https://education.borshev.com/relocate курс + доступ в сообщество. Кажется, что сообщество будет сильных специалистов, раз они задумываются о релокации и т.п., но я не уверен. Не реклама, никто не платил за нее, курс не смотрел и не покупал (только первое видео видел, потому что подписан на Senior Software Vlogger), какое сообщество на самом деле там будет - не знаю.


No Idea Blog
Тоже прекрасный блог, хоть и не очень активный. Этого автора я узнал давно, когда попал в похожую ситуацию, которую она описывает в одном из своих выступлений (я смотрел вот это https://www.youtube.com/watch?v=5cr2Yn_MrKg, но у нее вроде вышло более развернутое на эту же тему https://www.youtube.com/watch?v=KClAPipnKqw.



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

https://www.getlago.com/blog/why-billing-systems-are-a-nightmare-for-engineers


Работа с биллингом - боль. В смысле, это очень сложно и mission critical, любая ошибка стоит дофига денег.
По ссылке выше прекрасная статья о сложностях, с которыми приходится сталкиваться при работе над биллингом.

В продолжении разговоров про блоги и статьи…

https://roundup.getdbt.com/p/avoiding-traps

У DBT, кстати, кроме подкаста, есть очень хороший дайджест - The Analytics Engineering Roundup. Раз в недельку они собирают интересные статьи и интервью.
На этой неделе в подкасте был Justin Borgman, CEO Starbust (SaaS поверх Trino), и ребята обсуждали работу Data Teams.
Краткая выдержка и не только по ссылке выше, а выпуск подкаста доступен тут -> https://roundup.getdbt.com/p/ep-27-to-move-or-not-to-move-data

Мой глаз зацепился за вот эту "пропискую" истину:

Conventional wisdom in software engineering suggest that teams should be spending roughly:
- 50% of their time on net new capabilities
- 20% on “KTLO” (keeping the lights on…scaling systems, incident response)
- 20% on quality improvements
- 10% on internal tooling

Фактически, почти 50% - это работа над техническим долгом команды. Хочется узнать, а какое распределение у вас в команде?

Капец я актуальный, конечно.
Тут Мета фризит найм, а Нетфликс, Болт, Better, Klarna, Robinhood и еще куча компаний увольняют людей, в том числе разработчиков, а я вам принес статью про… онбоардинг!

https://leadership.garden/onboarding-engineers/

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

https://github.com/DataTalksClub/mlops-zoomcamp

Новость с опозданием небольшим, ну простите 😢

Ребята из DataTalks Club, те самые, которые проводили DE Zoomcamp https://news.1rj.ru/str/ohmydataengineer/172, сейчас проводят ML Ops Zoomcamp.
То, что новость с опозданием не очень страшно, можно ж в self-paced проходить, если вам не очень важно, чтобы вашу домашку проверяли, а главное - получить знания.
Zoomcamp`ы у ребят клевые, дают базовые и фундаментальные понимания того что и куда.

ML & Data Ops упало в мои обязанности на работе, поэтому лично для меня это очень вовремя.

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 миллионов, но чет мой пузырь состоит только из рускоязычных каналов….

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