Building an Observability Startup: Chronosphere - статья от Pragmatic Engineer. В статье автор рассказывает про инженера, который поработал в Microsoft, потом AWS, где трудился над observability для виртуальных машин и создал сервис AWS System Manager, затем создавал observability систему M3 в Uber и уже потом создал продукт Chronosphere и получил под него инвестиции.

В этой истории мне понравилось, что мужик всю жизнь занимался +/- одним и тем же и потом решил сделать продукт по своей теме. Достаточно популярная история.

Но я задумался о другом - о возможностях. В Северной Америке я вижу много успешных кейсов, когда студенты computer science уже после 3го курса попадают в FAANG на стажировку, а после окончания учебы уже работают на полную ставку. Я сам наблюдал, как приходят стажеры в Amazon, быстро учатся, через 1-2 годика уже в штате, через 1-2 годика уже senior. Было очевидно, что компания делает на них ставку, поощряет их и инвестирует в них.

Для них все выглядит просто и они плывут практически по течению карьерного роста. Конечно, надо напрягаться, учиться, и еще раз учиться. В LinkedIn я часто вижу как вчерашние junior сегодня уже staff инженеры и рассказывают о высоких зарплатах и продают консультации по 200$ в час, где вам могут дать пару дельных советов.

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

Все таки, хороший старт очень важен, а если он еще произошел в 20 лет, а не 35, то вообще будет замечательно. Но мне кажется, что "хороший старт" это не про большинство моих читателей, у всех свой "тернистый" путь, он тяжелый, и чтобы достичь более менее такого же результата нам придется постараться и сделать намного больше. А если мы еще хотим и зарплату как в долине, но это уже тогда вообще придется как следует впахивать на старости лет. Хотя это же относительный термин, кто-то и в 70 себя на 20 ощущает.

У меня вот есть самовар на дровах, и если вдруг не будет электричества, я всегда смогу скипятить чайку, а вот все эти инженеры из долины не смогут, так что не все так плохо!

16 по 20 Октября у Microsoft будет онлайн ивент - Airlift. Раньше не слышал про такое событие, там будут секции про Data&AI, где будут углубленные сессия по аналитическим решениям.

Основные бенефиты:
- попрактиковать английский
- понять куда Microsoft двигает аналитическую индустрию
- узнать больше про новые продукты и use cases (Power BI, Fabric, Synapse, Databricks, Azure ML and etc)

Зак все правильно говорит - много работы, проектов, ad-hoc запросов вам не помогут получить промо, да и вообще будут проблемы с результатом, потому что во всей это билиберде (или белеберде) мало ценности, много лишних телодвижений, сообщений, и активностей, но для руководства и бизнеса это бесполезно.

Поэтому на работе попробуйте понять какие проекты ценны, и какие люди важны для вашего промо и фидбека, и работайте на них. Все хотелки от пользователей (если это не директор/vp) можно слать лесом.

AWS Glue: Hands-on Optimization Workshop
Thursday, October 26 2023 | 9:00AM - 12:00PM PDT

Отличная возможность узнать про Spark на AWS.

Why Most Data Projects Fail and How to Avoid It • Jesse Anderson • YOW! 2022

Интересное выступление про data проекты от Jesse Anderson, автора книги "Data Teams". Автор говорит о ключевых вопросах, которые стоит задать при старте проектов
- Who - Автор говорит про правильный состав команды для data проектов. Собственно автор про это написал целую книгу и он говорит про баланс data scientists, data engineers, operations.
- What - Автор задает вопрос про бизнес значение того data продукта/проекта, которым вы занимаетесь. Автор говорит о том, что фразы "Мы делаем AI" от CEO не хватает для data strategy:) В общем, надо понимать как ваш проект принесет ценность для бизнеса. Причем помимо стратегии нужен план и его execution. Особенно во времена, когда tech компании занимаются сокращениями в направлениях, что не приносят деньги.
- When - Автор говорит о том, а когда эта бизнес ценность будет создана. Нужен проект с понятными временными границами, чтобы он не был слишокм долгим, чтобы быть отмененным где-то посердине и не слишком коротким, обещающим золотые горы, которым на самом деле будет невозможно соответствовать.
- Where - И вот мы наконец-то добрались до первого технического вопроса, а где собственно эти данные будут обрабатываться, как будет выглядеть архитектура решения. И тут для ответа тоже не хватает фразу "Мы будем использовать технологию XYZ вендора ABC". Проблема в том, что вендор может пообещать все что угодно, но это обещание не факт, что выполнимо, более того, не факт, что оно оптимально для заказчика:)
- How - Здесь речь идет про план выполнения и про фокусировку на приоритетных направлениях. Хотя часто такие data проекты пытаются успеть сразу везде, а дальше теряют эффективность на context switches и застывают на месте, переставая генерировать какую-либо ценность кроме рассказов о наступлении AI:) Автор интересно рассказывает про то, как бизнес заказчикам перпендикулярно на конкретные технические решения, но важно какую бизнес-ценность они могут получить по результатам выполнения плана.
- Why - Автор задает вопрос, а почему же эти данные обладают ценностью? Просто отгружать данные и гонять ETL/ELT пайпланы не достаточно. Важно понимать как использование данных в новых проектах позволит обеспечить нужный ROI (return on investments), причем автор говорит о том, что он ищет 10x ROI для data проектов

Напоследок автор говорит о том, что для AI и data проектов важно понимать, что такие проекты сложны и требуют навыков, людей и организационных изменений для своего успеха. И это достаточно сложно и не все способны приносить пользу в таких проектах. Конкретно, автор рассказывает про то, что если запускать data и AI проекты внутри DWH команд, то такие проекты обречены на неудачу ("the team where good data projects go to die). Это обусловлено не тем, что DWH технологии плохие, а потому, что это скорее проблема людей ("people problem"), которые очень специфично разбираются с проблемами и очень специфичным образом выстраивают свою работу. В общем, автор говорит о том, что эта не та команда, которая должна отвечать за data и AI проекты нового типа.

В конце автор рассказывает о том, как можно получить помощь с такими проектами за счет аутсорсинга (если у компании нет своей инженерной команды и культуры), за счет привлечения консультантов (правда, автор говорит о том, что консультанты по менеджменту типа BCG, Bain, Mckinsey зачастую не обладают компетенциями для помощи в таких data проектах). В конце автор упоминает свою книгу "Data teams", которую он написал для менеджеров, которым предстоит запускать data и AI проекты.

P.S.
Мне автор продал свою книгу, поэтому я добавлю ее в свой long list на чтение:)

#Management #Leadership #Data #DataScience #AI #Engineering #Software #SoftwareDevelopment #ML

Маленькая презентация про Data Skew (перекос данных) в Databricks.

Перекос данных известный термин при работе с распределенными системами (Redshift, Synapse, Hadoop и тд). Можно сказать это фундаментальная вещь. Но решается в каждом продукте по своему.

Классная математика увольнений 🧮

Бизнес, данные и кибер-футуризм: Alfa Data Science Meetup #3 🪩

27 октября в Екатеринбурге пройдет хардовый Alfa DS Meetup #3 Business. Участникам предложат посмотреть на ценности, метрики и особенности CLTV через призму бизнеса и аналитики.

Ребята из Альфы расскажут о том, как успешно справляются с рутиной с помощью машинного обучения, а также всех гостей ждет два отдельных трека докладов.

Только для очных зрителей будет доступна закрытая панельная дискуссия с приглашенными спикерами из билайна и СберМаркета про особенности разработки и применения моделей CLTV и Networking Party.

Когда: 27 октября в 19:00 (по местному времени)

Где: г. Екатеринбург, ул. Горького, д. 7А (офис Альфа-Банка) + онлайн-трансляция

Успейте зарегистрироваться на митап по ссылке — количество мест ограничено!

Реклама. АО "АЛЬФА-БАНК" erid: 2Vtzqxm7VW4 шла

ML-инженер Газпромбанка опубликовал на Хабре статью про автоматизацию переобучения моделей в банковских условиях. Когда на работу влияет не только финансовая специфика, но и куча регуляторики с требованиями безопасников (нет того же Git LFS).

Текст об параллельном выполнении процесса сканирования и выкатки кода по CI/CD-процессу, благодаря архитектурному разграничению весов модели и самого кода как разных сущностей сборки.

Мой бывший коллега Андрей Менде ищет человека:

Привет!

Я ищу инженера и/или аналитика данных на проект. Сразу предупрежу, что это не трудоустройство, имеет смысл вписываться если вы хотите добавить себе в портфолио интересный кейс и попрактиковаться за вознаграждение.

Сервис аренды автомобилей систематически логировал в ClickHouse все поиски, клики и бронирования, которые делали клиенты.

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

Писать в телеграм @andrewmende

Ок кстати еще и на data learn выступал - Data science и Product Management

Для опыта будет неплохо вам поковырять реальные данные, заодно можно и refference попросить на будущее к нему в компанию (booking)

Ну это пушка Dbeaver + ChatGPT https://youtu.be/ujXKnUZKrNM?si=hyi-23efWYE-mmyo

А вы продуктивный инженер или так себе? Вот Майкрософт решил провести опрос среди 413 разработчик и попытался ответить на это вопрос - Characterizing Software Developers by Perceptions of Productivity

Было выделено 6 групп и дано описание каждой группе.

1 Social developers (C1) feel productive when helping coworkers, collaborating and doing code reviews. 
2 Lone developers (C2) avoid disruptions such as noise, email, meetings, and code reviews. They feel most productive when they have little to no social interactions and when they can work on solving problems, fixing bugs or coding features in quiet and without interruptions. 
3 Focused developers (C3) feel most productive when they are working efficiently and concentrated on a single task at a time.  
4 Balanced developers (C4) are less affected by disruptions. They are also less likely to come to work early or stay at work late. 
5 Leading developers (C5) are more comfortable with meetings and emails. They feel more productive in the afternoon and when they can write and design things. 
6 Goal-oriented developers (C6) feel productive when they complete or make progress on tasks. They feel less productive when they multi-task, are goal-less or are stuck.

Термин data observability достаточно недавно стал применятся к хранилищам данных и ETL. Раньше просто говорили - качество данных.

The concept of data observability was first described by Barr Moses, co-founder and CEO of software vendor Monte Carlo Data. Moses coined the term in 2019, when she wrote a blog post about applying the general principles of observability for IT systems to data.



а сам термин observability пришел из devops, подразумевает процесс мониторинга ИТ систем и возможность быстро найти причину неполадки.
Где как не на сайте Мonte Carlo можно узнать больше про data observability - What is Data Observability? Для меня это просто процесс мониторинги всего чего только можно в нашем хранилище данных и случае отклонения -> ⚠️.
Самое интересное у них это типы "мониторов", то есть типы проверок ваших данных, которые могут покрыть все решение. Я сам пользуюсь уже год, и продукт мне нравится, а недавно мы стали интегрировать dbt и MC.
Если нет денег на MC, всегда можно подсмотреть идеи у них и уже сделать с помощью dbt, python, или какой язык вы там используете.

Что для вас значит хороший код и как измерить его качество? На этот вопрос ответили в статье Developers talking about code quality.

В ней опросили больше 100 инженеров и все сошлись на мнении, что хороший код про понятный структурированный код, который легко читать и понимать.