Тут AirBnB ввел интересную политику про одинаковые зарплаты:

https://news.airbnb.com/airbnbs-design-to-live-and-work-anywhere/

Вот основные пункты:
1. You can work from home or the office
А значит, можно продолжать работать удаленно, а не как Apple всех гонит обратно в офис на 3 дня в неделю.

2. You can move anywhere in the country you work in and your compensation won’t change
This means you can move from San Francisco to Nashville, or from Paris to Lyon. If you move, your compensation won’t change. Starting in June, we’ll have single pay tiers by country for both salary and equity. If your pay was set using a lower location-based pay tier, you’ll receive an increase in June.

То есть если вы жили в Bay Area, а потом переехали к бабушке Элли в Канзас, зарплата у вас останется старая.

3. You have the flexibility to travel and work around the world
Starting in September, you can live and work in over 170 countries for up to 90 days a year in each location.

Ну это с Сбербанка слизали, они тоже разрешали месяц в году работать откуда-то не из домашней локации. 😁

4. We’ll meet up regularly for team gatherings, off-sites, and social events
Ну оффсайты всегда прекрасно!

5. We’ll continue to work in a highly coordinated way
А это классика про core hours вокруг часовых поясов.


В AirBnB работает прикольный чел по имени Zach Wilson, дата инженер (ex-Netflix), который ведет интересный блог на LinkedIn, советую подписаться!

Так, мне тут рассылка от 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