Устроиться аналитиком в Яндекс за выходные
7–8 июня проводим Weekend Offer Analytics. До 3 июня оставьте заявку на участие, 7 июня пройдите два технические собеседования, а 8 июня познакомьтесь с командами и получите офер.
В мероприятии участвует 12 команд: Алиса и Умные устройства, Игры, R&D, Рекламные технологии, Поиск и Суперапп, Безопасность, Коммерческий департамент, Автономный транспорт, Ecom-сценарии Поиска, Качество Поиска, Международный Поиск, Карты. Вы сможете пообщаться с менеджерами и выбрать проект, который покажется самым интересным.
Узнать подробности и зарегистрироваться можно здесь.
7–8 июня проводим Weekend Offer Analytics. До 3 июня оставьте заявку на участие, 7 июня пройдите два технические собеседования, а 8 июня познакомьтесь с командами и получите офер.
В мероприятии участвует 12 команд: Алиса и Умные устройства, Игры, R&D, Рекламные технологии, Поиск и Суперапп, Безопасность, Коммерческий департамент, Автономный транспорт, Ecom-сценарии Поиска, Качество Поиска, Международный Поиск, Карты. Вы сможете пообщаться с менеджерами и выбрать проект, который покажется самым интересным.
Узнать подробности и зарегистрироваться можно здесь.
😭5🌚3
Хочу вам напомнить про полезные ресурсы:
1) datalearn учебник, где на русском есть 6,5 модулей про аналитику и инжиниринг данных и отдельный курс от Анатолия про SQL(лучше курса еще не придумали), где вы будете сами устанавливать Postgres и SQL Server и много практики https://github.com/Data-Learn/data-engineering
2) свежая версия курса на английском 3,5 модуля и дополнительный модуль 0 - https://surfalytics.com/surfalytics/2023-06-03-Introduction.html
1) datalearn учебник, где на русском есть 6,5 модулей про аналитику и инжиниринг данных и отдельный курс от Анатолия про SQL(лучше курса еще не придумали), где вы будете сами устанавливать Postgres и SQL Server и много практики https://github.com/Data-Learn/data-engineering
2) свежая версия курса на английском 3,5 модуля и дополнительный модуль 0 - https://surfalytics.com/surfalytics/2023-06-03-Introduction.html
GitHub
GitHub - Data-Learn/data-engineering: Getting Started with Data Enngineering
Getting Started with Data Enngineering. Contribute to Data-Learn/data-engineering development by creating an account on GitHub.
❤🔥118⚡19💯11🍾6
Неожиданно! Главный SaaS CRM покупает old-school ETL вендер Informatica🤪
Компания Salesforce объявила о планах приобрести платформу управления данными Informatica за приблизительно $8 миллиардов. Это станет крупнейшей сделкой Salesforce с момента покупки Slack за $28 миллиардов в 2021 году. Данная покупка направлена на усиление возможностей Salesforce в области управления данными и интеграции генеративного искусственного интеллекта (ИИ) в свои бизнес-инструменты. В частности, приобретение Informatica позволит Salesforce улучшить контроль над использованием данных, что критически важно для развития ИИ-функций, таких как платформа Agentforce, предназначенная для автоматизации задач с помощью виртуальных ИИ-агентов.
Осталось кому-нибудь купить Teradata📊
Компания Salesforce объявила о планах приобрести платформу управления данными Informatica за приблизительно $8 миллиардов. Это станет крупнейшей сделкой Salesforce с момента покупки Slack за $28 миллиардов в 2021 году. Данная покупка направлена на усиление возможностей Salesforce в области управления данными и интеграции генеративного искусственного интеллекта (ИИ) в свои бизнес-инструменты. В частности, приобретение Informatica позволит Salesforce улучшить контроль над использованием данных, что критически важно для развития ИИ-функций, таких как платформа Agentforce, предназначенная для автоматизации задач с помощью виртуальных ИИ-агентов.
Осталось кому-нибудь купить Teradata📊
🙈24🦄6❤🔥3🐳2
DuckDB предложил очень интересную альтернативу - DuckLake: SQL as a Lakehouse Format
Что это значит?
Если мы откатимся назад и повторим эволюцию аналитических решений - от классического хранилища данных до современного Lakehouse, можно выделить основные этапы:
- Data Warehouse (Хранилище данных) - хранение и вычисления происходят на одном физическом/виртуальном сервере или кластере.
- Data Lake (Озеро данных) - происходит разделение хранения и вычислений.
- Lakehouse - гибрид Data Lake и Data Warehouse. Ключевой элемент - формат таблиц (Iceberg, Delta, Hudi), который добавляет возможности управления изменениями в data lake. Эти форматы используют сложные файловые структуры (JSON, Avro) для отслеживания версий и схем.
Сегодня на рынке представлен широкий спектр инструментов и тесная интеграция между подходами. Любое решение - это всегда компромисс. Выбор зависит от бюджета, возможностей и экспертизы команды и т. д.
У Lakehouse есть важный недостаток - сложности с обеспечением атомарности операций и управлением несколькими таблицами, а также ряд других проблем. Те, кто строил Iceberg-архитектуру, могут поделиться своими ограничениями и трудностями.
DuckLake предлагает альтернативный подход: вся метаинформация (каталоги, схемы, версии) хранится в стандартной SQL-базе данных, поддерживающей ACID-транзакции и первичные ключи. Это позволяет:
- Обеспечить надежное и простое управление метаданными.
- Поддерживать транзакции, охватывающие несколько таблиц.
- Избежать сложностей, связанных с согласованностью в blob-хранилищах.
При этом данные продолжают храниться в открытых форматах, таких как Parquet, что обеспечивает совместимость и гибкость. То есть метаданные "уходят" в DuckDB - в SQL-таблицу, которая и используется в качестве каталога.
Вот такое элегантное решение. Кстати, ниша managed duckdb в публичных облаках свободна🍸
PS В Surfalytics мы делали пару проектов про DuckDB и даже есть урок в основном курсе:
Just enough DuckDB for Data Analyst | Module 2.7 | Surfalytics
И в datalearn у нас был классный обзор от Романа Зыкова:
Разработка data приложений на DuckDB
Что это значит?
Если мы откатимся назад и повторим эволюцию аналитических решений - от классического хранилища данных до современного Lakehouse, можно выделить основные этапы:
- Data Warehouse (Хранилище данных) - хранение и вычисления происходят на одном физическом/виртуальном сервере или кластере.
- Data Lake (Озеро данных) - происходит разделение хранения и вычислений.
- Lakehouse - гибрид Data Lake и Data Warehouse. Ключевой элемент - формат таблиц (Iceberg, Delta, Hudi), который добавляет возможности управления изменениями в data lake. Эти форматы используют сложные файловые структуры (JSON, Avro) для отслеживания версий и схем.
Сегодня на рынке представлен широкий спектр инструментов и тесная интеграция между подходами. Любое решение - это всегда компромисс. Выбор зависит от бюджета, возможностей и экспертизы команды и т. д.
У Lakehouse есть важный недостаток - сложности с обеспечением атомарности операций и управлением несколькими таблицами, а также ряд других проблем. Те, кто строил Iceberg-архитектуру, могут поделиться своими ограничениями и трудностями.
DuckLake предлагает альтернативный подход: вся метаинформация (каталоги, схемы, версии) хранится в стандартной SQL-базе данных, поддерживающей ACID-транзакции и первичные ключи. Это позволяет:
- Обеспечить надежное и простое управление метаданными.
- Поддерживать транзакции, охватывающие несколько таблиц.
- Избежать сложностей, связанных с согласованностью в blob-хранилищах.
При этом данные продолжают храниться в открытых форматах, таких как Parquet, что обеспечивает совместимость и гибкость. То есть метаданные "уходят" в DuckDB - в SQL-таблицу, которая и используется в качестве каталога.
Вот такое элегантное решение. Кстати, ниша managed duckdb в публичных облаках свободна
PS В Surfalytics мы делали пару проектов про DuckDB и даже есть урок в основном курсе:
Just enough DuckDB for Data Analyst | Module 2.7 | Surfalytics
И в datalearn у нас был классный обзор от Романа Зыкова:
Разработка data приложений на DuckDB
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥28🫡2
Как ВЫЙТИ из IT и стать счастливым?
Владислав Князев, тимлид из финтеха, искренне и с жизнелюбием пишет про путь от выгоревшего айтишника в надежного психолога.
Поддерживающий блог для тех, кто ищет гармонию и уверенность в себе❤️
Подпишись на @godnolytika
Владислав Князев, тимлид из финтеха, искренне и с жизнелюбием пишет про путь от выгоревшего айтишника в надежного психолога.
Поддерживающий блог для тех, кто ищет гармонию и уверенность в себе
Подпишись на @godnolytika
Please open Telegram to view this post
VIEW IN TELEGRAM
🤷18🗿9🦄7🌭6❤🔥4🍌3
Бодрая неделька выдалась, столько новинок интересных. Ведь скоро Databricks и Snowflake Summit.
Если вы будете на этих конференциях пишите в комментах, может там найдетесь, и выпьете по стаканьчику. Я сам смогу намутить pass на 1 бесплатный день на Snowflake конференцию, но этого малова-то. Если вы в Калифорнии и хотите попасть бесплатно на один день (среда) Snowlfake, я расскажу как это сделать.
1️⃣ dbt labs там выкатили большой список обновлений - dbt Launch Showcase 2025 recap
dbt MCP Server - сервер, обрабатывающий dbt-команды централизованно и ускоряющий запуск моделей, особенно в облачных и CI/CD-средах. А кто сейчас не делает MCP?
Fusion engine - движок на Rust, который анализирует SQL-код ещё до выполнения, улучшая производительность и предотвращая ошибки. Как раз был потс в январе про покупку SDF.
VS Code Extension - официальное расширение для VS Code с поддержкой Fusion, автодополнением и анализом SQL, но работает только с dbt Cloud.
dbt Canvas - визуальный интерфейс для проектирования моделей и связей между ними, ориентированный на командную работу и документирование. Получается, что главное преимущество аналитика как код уходит на 2й план. Это дает доступ простым бизнес пользователям (больше пользователей, больше лицензий?!), но по факту может изменить концепт. У меня уже коллеги интересуются как они могут модельки-то строить в канвасе.
dbt Insights - помогает отслеживать перформанс моделей и находить узкие места.
dbt Catalog - расширенный каталог моделей, колонок и источников с поиском, тегами и улучшенной навигацией по проекту. Удобно, но dbt docs и так был достаточно хорош.
Cost management dashboard - дашборд для мониторинга стоимости выполнения моделей в разных средах и выявления неэффективных запросов. Полезно, но можно и свой сделать в обычном BI.
Мы видим все больше и больше разделение dbt core (открытое ПО) и коммерческий dbt labs. Вы не поверите, но у меня даже проблемы использовать оба инструменты в командной строке, так как оба используют
2️⃣ вышел Spark 4.0. Но там нет таких красивых красочных изменений, поэтому и в новостях потише.
Spark Connect - новая клиент-серверная архитектура, позволяющая подключаться к Spark-кластерам из различных языков (Python, Scala, Go, Swift, Rust) без необходимости установки Spark локально, что упрощает разработку и масштабирование приложений.
ANSI SQL по умолчанию - включение режима ANSI SQL обеспечивает более строгую проверку данных и совместимость с другими СУБД, улучшая переносимость и предсказуемость SQL-запросов.
SQL PIPE-синтаксис - введение оператора |> для последовательного применения SQL-операций, повышая читаемость и упрощая написание сложных запросов.
SQL-скрипты с переменными и управляющими конструкциями — поддержка переменных, циклов и условий в SQL позволяет реализовывать сложную бизнес-логику непосредственно в SQL-скриптах без необходимости использования внешних языков программирования.
Тип данных VARIANT - новый тип данных (прям как у Snowflake 10 лет назад) для хранения полуструктурированных данных, таких как JSON, обеспечивая эффективную работу с вложенными структурами без необходимости явного определения схемы.
Нативная визуализация в PySpark - возможность создавать графики и диаграммы непосредственно из DataFrame в PySpark с использованием Plotly, упрощая анализ данных.
Python Data Source API - новый API, позволяющий разработчикам создавать собственные источники данных для пакетной и потоковой обработки полностью на Python, расширяя возможности интеграции.
Polymorphic Python UDTFs - поддержка пользовательских табличных функций в Python с динамической схемой, позволяя создавать гибкие и мощные трансформации данных.
Structured Logging - введение структурированного логирования в формате JSON, облегчая мониторинг и отладку приложений.
transformWithState API - новый API для обработки состояния в потоковой обработке, предоставляющий более гибкие и мощные возможности для управления состоянием в реальном времени.
PS вы можете посмотреть Snowflake Keynotes онлайн по этой ссылке
Если вы будете на этих конференциях пишите в комментах, может там найдетесь, и выпьете по стаканьчику. Я сам смогу намутить pass на 1 бесплатный день на Snowflake конференцию, но этого малова-то. Если вы в Калифорнии и хотите попасть бесплатно на один день (среда) Snowlfake, я расскажу как это сделать.
dbt MCP Server - сервер, обрабатывающий dbt-команды централизованно и ускоряющий запуск моделей, особенно в облачных и CI/CD-средах. А кто сейчас не делает MCP?
Fusion engine - движок на Rust, который анализирует SQL-код ещё до выполнения, улучшая производительность и предотвращая ошибки. Как раз был потс в январе про покупку SDF.
VS Code Extension - официальное расширение для VS Code с поддержкой Fusion, автодополнением и анализом SQL, но работает только с dbt Cloud.
dbt Canvas - визуальный интерфейс для проектирования моделей и связей между ними, ориентированный на командную работу и документирование. Получается, что главное преимущество аналитика как код уходит на 2й план. Это дает доступ простым бизнес пользователям (больше пользователей, больше лицензий?!), но по факту может изменить концепт. У меня уже коллеги интересуются как они могут модельки-то строить в канвасе.
dbt Insights - помогает отслеживать перформанс моделей и находить узкие места.
dbt Catalog - расширенный каталог моделей, колонок и источников с поиском, тегами и улучшенной навигацией по проекту. Удобно, но dbt docs и так был достаточно хорош.
Cost management dashboard - дашборд для мониторинга стоимости выполнения моделей в разных средах и выявления неэффективных запросов. Полезно, но можно и свой сделать в обычном BI.
Мы видим все больше и больше разделение dbt core (открытое ПО) и коммерческий dbt labs. Вы не поверите, но у меня даже проблемы использовать оба инструменты в командной строке, так как оба используют
dbt команду.Spark Connect - новая клиент-серверная архитектура, позволяющая подключаться к Spark-кластерам из различных языков (Python, Scala, Go, Swift, Rust) без необходимости установки Spark локально, что упрощает разработку и масштабирование приложений.
ANSI SQL по умолчанию - включение режима ANSI SQL обеспечивает более строгую проверку данных и совместимость с другими СУБД, улучшая переносимость и предсказуемость SQL-запросов.
SQL PIPE-синтаксис - введение оператора |> для последовательного применения SQL-операций, повышая читаемость и упрощая написание сложных запросов.
SQL-скрипты с переменными и управляющими конструкциями — поддержка переменных, циклов и условий в SQL позволяет реализовывать сложную бизнес-логику непосредственно в SQL-скриптах без необходимости использования внешних языков программирования.
Тип данных VARIANT - новый тип данных (прям как у Snowflake 10 лет назад) для хранения полуструктурированных данных, таких как JSON, обеспечивая эффективную работу с вложенными структурами без необходимости явного определения схемы.
Нативная визуализация в PySpark - возможность создавать графики и диаграммы непосредственно из DataFrame в PySpark с использованием Plotly, упрощая анализ данных.
Python Data Source API - новый API, позволяющий разработчикам создавать собственные источники данных для пакетной и потоковой обработки полностью на Python, расширяя возможности интеграции.
Polymorphic Python UDTFs - поддержка пользовательских табличных функций в Python с динамической схемой, позволяя создавать гибкие и мощные трансформации данных.
Structured Logging - введение структурированного логирования в формате JSON, облегчая мониторинг и отладку приложений.
transformWithState API - новый API для обработки состояния в потоковой обработке, предоставляющий более гибкие и мощные возможности для управления состоянием в реальном времени.
PS вы можете посмотреть Snowflake Keynotes онлайн по этой ссылке
Please open Telegram to view this post
VIEW IN TELEGRAM
dbt Labs
dbt Launch Showcase 2025 recap | dbt Labs
New features in dbt empower organizations to scale analytics for the age of AI
❤🔥17⚡4🍾2
Forwarded from BeOps
Вот такой сервис который сравнивает IT зарплаты из всего русского сегмента.
Как я понял, он пылесосит все открытые источники типа hh и сливает все в приятный репорт.
https://public.tableau.com/shared/3KN2X2YXN?:display_count=n&:origin=viz_share_link&:showVizHome=no
По-моему выглядит очень хорошо и полезно. Готовимся.
Как я понял, он пылесосит все открытые источники типа hh и сливает все в приятный репорт.
https://public.tableau.com/shared/3KN2X2YXN?:display_count=n&:origin=viz_share_link&:showVizHome=no
По-моему выглядит очень хорошо и полезно. Готовимся.
❤🔥52
Очень интересная точка зрения основателя Tobiko (SQLMesh) — главного конкурента dbt.
Мы тут были в восторге от новой фичи dbt: он стал значительно быстрее, потому что его переписали на Rust. Логично, что переписывание старого движка дало мощный прирост в скорости, и выбор Rust очевидно удачный.
Но мы так привыкли к "бесплатному" и хорошо работающему dbt Core, что воспринимаем это как должное. А вот из-за такой "данности" компания dbt Labs теряет деньги. А им ведь ещё нужно отчитываться перед инвесторами.
Вот с Airflow и Airbyte всегда было проще, косяк на косяке=) (вот только не говорите мне, что "готовить не умею", я бы тогда просто-бы макросы VBA "приготовил бы"🧐 )
Вот и сам текст:
dbt Fusion — это полная переработка dbt Core на языке Rust. В отличие от dbt Core, который является полностью бесплатным и с открытым исходным кодом под лицензией Apache 2.0, dbt Fusion — это не open-source проект, так как распространяется по более ограничительной лицензии Elastic 2.0.
Хотя Fusion и можно использовать бесплатно, его лицензия запрещает использование в хостинговых или управляемых решениях третьими сторонами. Возможно, это кажется незначительным, но у этого ограничения есть серьёзные последствия.
Открытый исходный код хорош тем, что он стимулирует как отдельных разработчиков, так и компании инвестировать в развитие продукта без риска. Компания может полностью полагаться на open-source решение, потому что в любом случае его можно форкнуть и использовать в своих целях, независимо от решений основного разработчика. Лицензия с ограничениями, такая как Elastic, наоборот, демотивирует компании вкладываться в развитие продукта.
Не поймите неправильно: в решении dbt Labs нет ничего неэтичного. Более того, с финансовой точки зрения для них это может быть наиболее разумным шагом. Но важно понять, как мы к этому пришли и что это может значить для будущего dbt Core.
Мне кажется, стратегия dbt заключается в том, чтобы перевести dbt Core в режим поддержки (maintenance mode), сосредоточившись на Fusion и других коммерческих продуктах. Формулировки в анонсе были выбраны очень осторожно и расплывчато. В частности, говоря о поддержке dbt Core, они упомянули только исправление багов, обновления безопасности и поддержание совместимости.
Согласно их роадмапу, они отделили dbt-язык от runtime-движка. Также отдельно подчёркивается, что Fusion и Core со временем неизбежно разойдутся, поскольку Fusion обладает возможностями, которые невозможно добавить в Core. По моему мнению, dbt Labs используют эту возможность, чтобы сосредоточиться на более ограниченном и прибыльном софте, постепенно сворачивая то, что сделало их знаменитыми, но одновременно мешает их финансовому росту.
В конечном итоге ресурсы ограничены, и компании вынуждены расставлять приоритеты исходя из интересов бизнеса.
Учитывая фундаментальное значение dbt Core для современной аналитической инфраструктуры, аналитики и инженеры данных заслуживают свободную, открытую и постоянно развивающуюся платформу для трансформации данных. В противном случае ваша карьера окажется слишком зависимой от решений одной-единственной компании. Чтобы обеспечить непрерывные инновации в области data-трансформаций, возможно, пришло время начать дискуссию об открытом стандарте описания трансформаций данных.
Посмотрим как долго SQLMesh будет открытый (то есть как долго будет экономика сходится)🔪
Мы тут были в восторге от новой фичи dbt: он стал значительно быстрее, потому что его переписали на Rust. Логично, что переписывание старого движка дало мощный прирост в скорости, и выбор Rust очевидно удачный.
Но мы так привыкли к "бесплатному" и хорошо работающему dbt Core, что воспринимаем это как должное. А вот из-за такой "данности" компания dbt Labs теряет деньги. А им ведь ещё нужно отчитываться перед инвесторами.
Вот с Airflow и Airbyte всегда было проще, косяк на косяке=) (вот только не говорите мне, что "готовить не умею", я бы тогда просто-бы макросы VBA "приготовил бы"
Вот и сам текст:
dbt Fusion — это полная переработка dbt Core на языке Rust. В отличие от dbt Core, который является полностью бесплатным и с открытым исходным кодом под лицензией Apache 2.0, dbt Fusion — это не open-source проект, так как распространяется по более ограничительной лицензии Elastic 2.0.
Хотя Fusion и можно использовать бесплатно, его лицензия запрещает использование в хостинговых или управляемых решениях третьими сторонами. Возможно, это кажется незначительным, но у этого ограничения есть серьёзные последствия.
Открытый исходный код хорош тем, что он стимулирует как отдельных разработчиков, так и компании инвестировать в развитие продукта без риска. Компания может полностью полагаться на open-source решение, потому что в любом случае его можно форкнуть и использовать в своих целях, независимо от решений основного разработчика. Лицензия с ограничениями, такая как Elastic, наоборот, демотивирует компании вкладываться в развитие продукта.
Не поймите неправильно: в решении dbt Labs нет ничего неэтичного. Более того, с финансовой точки зрения для них это может быть наиболее разумным шагом. Но важно понять, как мы к этому пришли и что это может значить для будущего dbt Core.
Мне кажется, стратегия dbt заключается в том, чтобы перевести dbt Core в режим поддержки (maintenance mode), сосредоточившись на Fusion и других коммерческих продуктах. Формулировки в анонсе были выбраны очень осторожно и расплывчато. В частности, говоря о поддержке dbt Core, они упомянули только исправление багов, обновления безопасности и поддержание совместимости.
Согласно их роадмапу, они отделили dbt-язык от runtime-движка. Также отдельно подчёркивается, что Fusion и Core со временем неизбежно разойдутся, поскольку Fusion обладает возможностями, которые невозможно добавить в Core. По моему мнению, dbt Labs используют эту возможность, чтобы сосредоточиться на более ограниченном и прибыльном софте, постепенно сворачивая то, что сделало их знаменитыми, но одновременно мешает их финансовому росту.
В конечном итоге ресурсы ограничены, и компании вынуждены расставлять приоритеты исходя из интересов бизнеса.
Учитывая фундаментальное значение dbt Core для современной аналитической инфраструктуры, аналитики и инженеры данных заслуживают свободную, открытую и постоянно развивающуюся платформу для трансформации данных. В противном случае ваша карьера окажется слишком зависимой от решений одной-единственной компании. Чтобы обеспечить непрерывные инновации в области data-трансформаций, возможно, пришло время начать дискуссию об открытом стандарте описания трансформаций данных.
Посмотрим как долго SQLMesh будет открытый (то есть как долго будет экономика сходится)
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡19🐳6🌚3❤🔥1🤷♂1
Forwarded from Книжный куб (Alexander Polomodov)
AI-помощники при работе с кодом. Взгляд в будущее - Евгений Колесников - Platform Engineering Night (Рубрика #AI)
Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже
1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.
Если подводить итоги, то Евгений считает, что AI-помощники однозначно полезны, но важно понимать их ограничения и правильно интегрировать в рабочий процесс, а не гнаться за хайпом.
#AI #Software #Engineering #Architecture #Agents
Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже
1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.
Если подводить итоги, то Евгений считает, что AI-помощники однозначно полезны, но важно понимать их ограничения и правильно интегрировать в рабочий процесс, а не гнаться за хайпом.
#AI #Software #Engineering #Architecture #Agents
YouTube
Евгений Колесников — «AI-помощники при работе с кодом. Взгляд в будущее»
ИИ-помощников при работе с кодом становится все больше: могут встречаться yet another LLM-wrapper или отдельные IDE. В докладе рассмотрели, какие инструменты бывают, как измерять качество и определять, что идем в правильном направлении при создании инструментов…
⚡22❤🔥8🌚1
Изучая новости отчественных облаков обратил внимание на ключевые тезисы из дискуссии «Озера данных для конкурентоспобности бизнеса».
1. Компании инвестируют в озера данных сейчас, даже если не видят большого эффекта. Через несколько лет догонять лидеров в этой гонке будет сложно.
2. Мы идем к тому, что компании, которые не используют Data Lakehouse, будут считаться отстающими на Х лет.
3. Для многих компаний работа с большими данными — инвестиция вдолгую. Впереди — выработка методологии для правильной оценки эффекта, который принесут объемы вложенных ресурсов.
4. Перед бизнесом стоит организационный вызов: нужно научить отделы внутри компаний делиться данными и, возможно, идти в сторону отраслевых хранилищ с обезличенными данными.
5. Средний объем корпоративных хранилищ данных перешагнул порог 500 Тб.
6. Подобрать инфраструктуру для работы с большими данными сложно, поскольку ошибки при выборе провайдера могут сильно помешать масштабироваться на долгой дистанции.
К самим тезисам и облачным продуктам вопросов нет - уверен, озёра данных действительно рулят: они хранят большие объёмы информации, даже в формате Iceberg. Но тема-то заявлена - «конкурентоспособность бизнеса».
Подобные посты часто публикуют и Yandex Cloud, и Arenadata. Но такой контент не создаёт ценности - он ориентирован на нетехнических пользователей. Обычно таким читателям неважно, сколько там терабайт, и вряд ли они поймут разницу между lakehouse и data warehouse.
Складывается впечатление, что компании должны внедрять озёра данных просто потому, что «все внедряют». И если вы ещё не внедрили и не мигрировали - то вам, по сути, нечем будет «мериться». Сколько у кого терабайт? Сколько кластеров? Сколько табличек?
Кстати, западные вендоры уже ушли от такого подхода. Они либо делают упор на бизнес-результат и намеренно опускают технические детали, либо наоборот - таргетируют глубоко техническую аудиторию и погружаются в детали. То есть аудиторию чётко сегментируют.
Этот подход хорошо иллюстрирует пример с резюме. Вы можете описать свой опыт через output:
- количество таблиц
- количество пайплайнов
- количество дашбордов
- количество PR
- количество строк кода
- миграция из А в Б
- внедрение А, Б, В
Но в этом мало ценности. Ценность - в outcome, в пользе, которую вы принесли. Написать резюме, в котором будет баланс между технологиями и бизнес-ценностью, - непростая задача. Особенно если его нужно уместить в две страницы.
PS мне нравятся продукты yandex, vk, arenadata, проделана колоссальная работа и созданы отличные решения. Просто улыбнул факт подачи информации о ценности для бизнеса, напомнил мне собеседования и резюме. Всегда хочется рассказать про детали, но они не так важны.
1. Компании инвестируют в озера данных сейчас, даже если не видят большого эффекта. Через несколько лет догонять лидеров в этой гонке будет сложно.
2. Мы идем к тому, что компании, которые не используют Data Lakehouse, будут считаться отстающими на Х лет.
3. Для многих компаний работа с большими данными — инвестиция вдолгую. Впереди — выработка методологии для правильной оценки эффекта, который принесут объемы вложенных ресурсов.
4. Перед бизнесом стоит организационный вызов: нужно научить отделы внутри компаний делиться данными и, возможно, идти в сторону отраслевых хранилищ с обезличенными данными.
5. Средний объем корпоративных хранилищ данных перешагнул порог 500 Тб.
6. Подобрать инфраструктуру для работы с большими данными сложно, поскольку ошибки при выборе провайдера могут сильно помешать масштабироваться на долгой дистанции.
К самим тезисам и облачным продуктам вопросов нет - уверен, озёра данных действительно рулят: они хранят большие объёмы информации, даже в формате Iceberg. Но тема-то заявлена - «конкурентоспособность бизнеса».
Подобные посты часто публикуют и Yandex Cloud, и Arenadata. Но такой контент не создаёт ценности - он ориентирован на нетехнических пользователей. Обычно таким читателям неважно, сколько там терабайт, и вряд ли они поймут разницу между lakehouse и data warehouse.
Складывается впечатление, что компании должны внедрять озёра данных просто потому, что «все внедряют». И если вы ещё не внедрили и не мигрировали - то вам, по сути, нечем будет «мериться». Сколько у кого терабайт? Сколько кластеров? Сколько табличек?
Кстати, западные вендоры уже ушли от такого подхода. Они либо делают упор на бизнес-результат и намеренно опускают технические детали, либо наоборот - таргетируют глубоко техническую аудиторию и погружаются в детали. То есть аудиторию чётко сегментируют.
Этот подход хорошо иллюстрирует пример с резюме. Вы можете описать свой опыт через output:
- количество таблиц
- количество пайплайнов
- количество дашбордов
- количество PR
- количество строк кода
- миграция из А в Б
- внедрение А, Б, В
Но в этом мало ценности. Ценность - в outcome, в пользе, которую вы принесли. Написать резюме, в котором будет баланс между технологиями и бизнес-ценностью, - непростая задача. Особенно если его нужно уместить в две страницы.
PS мне нравятся продукты yandex, vk, arenadata, проделана колоссальная работа и созданы отличные решения. Просто улыбнул факт подачи информации о ценности для бизнеса, напомнил мне собеседования и резюме. Всегда хочется рассказать про детали, но они не так важны.
⚡11❤🔥6💯6🐳2
Все знакомы с понятием Ad-hoc запросов. Обычно мы воспринимаем их негативно, так как они отвлекают, время-то и так мало.
На самом деле, ad-hoc запросы могут бысть источником quick wins, и способом быстро показать impact и завоевать доверие (earn trust).
Ad-hoc — это не бардак. Это VIP-запросы, которые показывают: вам доверяют. Ваша задача - не утонуть, а превратить это в рычаг для влияния.
Вот пример фреймфорка:
1. Принять быстро
Ответ в течение пары минут (или автоответ, если в фокусе) показывает: у нас есть процесс, а не паника.
2. Быстрое фильтрование (2 минуты):
- Это повлияет на $Xk+ или стратегию?
- Нужно на этой неделе для принятия решений?
- Делается за полдня одним аналитиком?
- Если да → делаем. Если нет - в бэклог с пометкой по приоритету.
3. Минимум, но по делу
- Отправляем краткий инсайт, график или SQL - что реально помогает. Повторилось 3 раза? → автоматизация.
📌 Чтобы не сгореть:
- Назначаем on-call-аналитика/инженера (10% времени спринта)
- Не забываем про ротацию и отслеживание нагрузки
- Повторяемые запросы → обучающие материалы или дашборды
Эскалации - через менеджера, не через «договорился в курилке».
На самом деле, ad-hoc запросы могут бысть источником quick wins, и способом быстро показать impact и завоевать доверие (earn trust).
Ad-hoc — это не бардак. Это VIP-запросы, которые показывают: вам доверяют. Ваша задача - не утонуть, а превратить это в рычаг для влияния.
Вот пример фреймфорка:
1. Принять быстро
Ответ в течение пары минут (или автоответ, если в фокусе) показывает: у нас есть процесс, а не паника.
2. Быстрое фильтрование (2 минуты):
- Это повлияет на $Xk+ или стратегию?
- Нужно на этой неделе для принятия решений?
- Делается за полдня одним аналитиком?
- Если да → делаем. Если нет - в бэклог с пометкой по приоритету.
3. Минимум, но по делу
- Отправляем краткий инсайт, график или SQL - что реально помогает. Повторилось 3 раза? → автоматизация.
📌 Чтобы не сгореть:
- Назначаем on-call-аналитика/инженера (10% времени спринта)
- Не забываем про ротацию и отслеживание нагрузки
- Повторяемые запросы → обучающие материалы или дашборды
Эскалации - через менеджера, не через «договорился в курилке».
1💯55❤🔥22🗿4⚡1
Data-driven культура часто выглядит как BI инструмент(ы) с метриками и дашбордами + хранилище данных (хотя уже модно делать Data Lakeuse на 500ТБ 🤔 ).
В идеале культура, основанная на данных, должна включать три ключевых элемента — так называемый 3P framework:
- People - вовлечённые сотрудники и поддержка со стороны руководства.
- Platform - удобные и доступные инструменты (BI-системы, дашборды, ноутбуки, хранилища и т. п.).
- Process - процессы, которые помогают извлекать инсайты и превращать их в действия, с акцентом на качество данных, метрики и бизнес-приоритеты.
В такой культуре важно позволять людям экспериментировать с данными, поощрять стремление к обучению и развитию, задавать бизнес-вопросы, формулировать гипотезы и проверять их.
Способность находить закономерности в данных, предлагать улучшения и отслеживать их влияние на бизнес — одна из ключевых ценностей data-led подхода.
Несколько практик, которые помогают достичь такого уровня зрелости:
🎮 Проведение хакатонов и вовлечение бизнес-пользователей в работу с данными.
🙂 Отправка аналитиков и инженеров "в поля", чтобы на практике понять, как устроен бизнес, как генерируются данные и как аналитические решения влияют на процессы.
⚡️ Временная интеграция аналитиков и инженеров в бизнес-команды для более глубокого погружения в задачи и контекст.
Вообще парадокс, в маленькой компании или стартапе достаточно завести эксельку и вести учет нескольких показателей и вы уже data-driven. А вот в большой корпарации у вас может быть 10 хранилищ, 5 озер, 7 BI, и армия аналитиков и инженеров, и вы нифига не data-driven🤣
В идеале культура, основанная на данных, должна включать три ключевых элемента — так называемый 3P framework:
- People - вовлечённые сотрудники и поддержка со стороны руководства.
- Platform - удобные и доступные инструменты (BI-системы, дашборды, ноутбуки, хранилища и т. п.).
- Process - процессы, которые помогают извлекать инсайты и превращать их в действия, с акцентом на качество данных, метрики и бизнес-приоритеты.
В такой культуре важно позволять людям экспериментировать с данными, поощрять стремление к обучению и развитию, задавать бизнес-вопросы, формулировать гипотезы и проверять их.
Способность находить закономерности в данных, предлагать улучшения и отслеживать их влияние на бизнес — одна из ключевых ценностей data-led подхода.
Несколько практик, которые помогают достичь такого уровня зрелости:
Вообще парадокс, в маленькой компании или стартапе достаточно завести эксельку и вести учет нескольких показателей и вы уже data-driven. А вот в большой корпарации у вас может быть 10 хранилищ, 5 озер, 7 BI, и армия аналитиков и инженеров, и вы нифига не data-driven
Please open Telegram to view this post
VIEW IN TELEGRAM
💯42
Ищете работу на международном рынке?
Тогда канал Connectable Jobs будет полезен для вас. Ребята собирают вакансии в международных стартапах с русскоязычными фаундерами, делятся важной информацией про команды и инвестиции, а также прямыми контактами HR для удобного отклика.
Вот несколько актуальных вакансий таких компаниях:
— Head of Data в Manychat
— Data Engineer в Constructor
— Lead of Engineering в Appodeal
Еще у Connectable Jobs есть отдельный канал для разработчиков и инженеров, где публикуются вакансии только в этой области.
Подписывайтесь и развивайте карьеру в будущем единороге 🚀
Тогда канал Connectable Jobs будет полезен для вас. Ребята собирают вакансии в международных стартапах с русскоязычными фаундерами, делятся важной информацией про команды и инвестиции, а также прямыми контактами HR для удобного отклика.
Вот несколько актуальных вакансий таких компаниях:
— Head of Data в Manychat
— Data Engineer в Constructor
— Lead of Engineering в Appodeal
Еще у Connectable Jobs есть отдельный канал для разработчиков и инженеров, где публикуются вакансии только в этой области.
Подписывайтесь и развивайте карьеру в будущем единороге 🚀
Telegram
Connectable Jobs
Вакансии от 300+ зарубежных компаний с русскоговорящими фаундерами или командами. Наши читатели уже получили офферы в InDrive, Revolut, Wallet, JetBrains и др. 💙
Разместить вакансию: https://forms.gle/K5KiBsaqo6Tp2sje8
Q&A: @connectable_jobs_team
Разместить вакансию: https://forms.gle/K5KiBsaqo6Tp2sje8
Q&A: @connectable_jobs_team
❤🔥6
Всем хороших выходных! Для меня бутылочка сидра в компании жены лучшая награда за 6 рабочих дней:)
PS в пятницу записал для Surfalytics первый эпизод mock Data Engineering System Design interview, использовали Azure cloud.
PPS интересный факт, стаканы из IKEA, но made in Russia😊
PS в пятницу записал для Surfalytics первый эпизод mock Data Engineering System Design interview, использовали Azure cloud.
PPS интересный факт, стаканы из IKEA, но made in Russia😊
1⚡39❤🔥34💯7🐳6🫡1
Недавно увидел хорошие термины про тип работы - deep work vs shallow work.
Deep work - глубокое погружение в работу, которое позволяет сосредоточиться на проблеме, изучить необходимые технологии и процессы. Обычно такая работа требует как минимум несколько часов без отвлечений, и по окончании процесса вы получаете удовлетворение. От такой напряжённой работы вы не так устаете и не выгораете.
Shallow work, напротив, - это работа урывками, когда часто меняется контекст между задачами и проектами.
Даже хорошо спланированную работу в формате deep work можно легко превратить в shallow work. Достаточно начать реагировать на сообщения в мессенджере от коллег, менеджеров, друзей. Или участвовать в частых митингах.
Вот и получается: вроде день прошёл, а результата ноль.
Мне лично помогает несложное кольцо действий:
1. составить список 2–3 важных дел на день
2. не переключаться на новое дело, пока не закончу первое
3. блоки deep work в календаре, которые отменяют все встречи - они у меня стоят на год вперёд
Так же можно запланировать дела на неделю, добавив в них личные дела. Свой календарь я не разделяю на личный и рабочий.
Лично для вас будет эффективнее и приятнее выполнить от начала до конца одно важное дело, чем ответить всем подряд в мессенджерах, сходить на несколько митингов и при этом задержаться на работе на несколько часов - всё равно без результатов.
Deep work - глубокое погружение в работу, которое позволяет сосредоточиться на проблеме, изучить необходимые технологии и процессы. Обычно такая работа требует как минимум несколько часов без отвлечений, и по окончании процесса вы получаете удовлетворение. От такой напряжённой работы вы не так устаете и не выгораете.
Shallow work, напротив, - это работа урывками, когда часто меняется контекст между задачами и проектами.
Даже хорошо спланированную работу в формате deep work можно легко превратить в shallow work. Достаточно начать реагировать на сообщения в мессенджере от коллег, менеджеров, друзей. Или участвовать в частых митингах.
Вот и получается: вроде день прошёл, а результата ноль.
Мне лично помогает несложное кольцо действий:
1. составить список 2–3 важных дел на день
2. не переключаться на новое дело, пока не закончу первое
3. блоки deep work в календаре, которые отменяют все встречи - они у меня стоят на год вперёд
Так же можно запланировать дела на неделю, добавив в них личные дела. Свой календарь я не разделяю на личный и рабочий.
Лично для вас будет эффективнее и приятнее выполнить от начала до конца одно важное дело, чем ответить всем подряд в мессенджерах, сходить на несколько митингов и при этом задержаться на работе на несколько часов - всё равно без результатов.
2⚡62💯46❤🔥16👨💻4
Forwarded from CEO Readz
📖 SLOW PRODUCTIVITY: THE LOST ART OF ACCOMPLISHMENT WITHOUT BURNOUT (2024)
Cal Newport
#лучшее
#безперевода
✏️ О КНИГЕ
Кэл Ньюпорт написал очень актуальную и своевременную книгу с тремя принципами «медленной продуктивности». Это и интересное чтение с примерами и размышлениями о природе продуктивности и умственной работы в современном мире, и конкретные рекомендации по достижению результатов в ваших проектах (ведь, как известно, «быстро — это медленно без перерывов»).
Он предлагает фокусироваться на качестве, а не количестве, и ограничивать число проектов в работе. Число часов в сутках ограничено, и с ростом числа проектов накладные временные расходы будут съедать всё больше времени, которое пригодилось бы для основной работы. С увеличением нагрузки они могут вырасти до точки, когда обслуживание работы будет требовать столько времени, что вы не будете успевать закрывать задачи — новые будут появляться быстрее.
🔥ФИШКИ КНИГИ
— Простые правила медленной продуктивности из трёх пунктов
— В списке лучших книг 2024 года по версии редакторов Amazon
— Лучшая книга года по версии The Economist и Independent
👨💻 КТО АВТОР
Кэл Ньюпорт — преподаватель, писатель, 42 года:
— Профессор факультета информатики Джорджтаунского университета, специализируется на теории распределённых вычислительных систем и цифровой этике
— Один из лучших авторов издания New York Times
— Регулярно пишет для широкой аудитории статьи о том, как пересекаются технологии и культура, и выступает на Национальном общественном радио
— Сторонник цифрового минимализма, никогда не заводил соцсетей, но ведёт блог Study Hacks с 2007 года, который читают более 2 000 000 человек в год в стремлении жить и глубоко работать в мире, который всё больше отвлекается
— C 2022 года Кэл запустил новый портал TheDeepLife.com, на котором размещается весь контент: все прошлые эпизоды популярного подкаста и обширная библиотека оригинальных видеоматериалов, которые доступны в том числе на YouTube
📌 ЦИТАТЫ ИЗ КНИГИ
Медленная продуктивность базируется на трёх принципах:
1. Делайте меньше дел
2. Работайте в естественном темпе
3. Сосредоточьтесь на качестве
Длительные рабочие отрезки, которые не создают мгновенных результатов, могут вызывать тревожность — куда проще проверять почту или ходить со встречи на встречу, чем сесть и много часов думать над новой стратегией.
Псевдо-продуктивность — использование видимой деятельности для оценки действительно продуктивных полезных усилий. Появление электронной почты и корпоративных мессенджеров позволили создавать видимость дела с минимальными усилиями и привели к тому, что средний работник больше времени говорит о работе, чем работает.
Если вы решите делать четыре отчёта параллельно вместо одного, «накладные расходы» времени будут занимать половину рабочего дня, если не больше. В конечном итоге, делать меньше — это путь к тому, чтобы получать результаты быстрее.
Моя рекомендация проста: работайте над одним проектом каждый день. Я не имею в виду, что этот проект будет вашей единственной работой за день. У вас точно будут письма, встречи. Но если мы говорим о ключевых, важных задачах, сфокусируйтесь на движении к одной цели в рамках дня.
Люди не очень хороши в оценке времени, необходимого на выполнение умственных задач.
Простое правило: уменьшать список задач на день, который вы запланировали, на 25-50%. Мы очень оптимистичны в такого рода оценках.
(Автор этого обзора, кстати, примерно в два раза переоценил время, необходимое на его написание — хотя читал эту и многие другие книги по теме😊)
📖 ВЫХОДНЫЕ ДАННЫЕ
Slow Productivity: The Lost Art of Accomplishment Without Burnout
Portfolio, 5 марта 2024
256 стр.
Перевод названия:
Медленная продуктивность: утраченное искусство достижения целей без выгорания
Саммари на русском от Smart Reading
Автор: Ренат Шагабутдинов
📚 CEO Readz. Книги для первых лиц
Cal Newport
#лучшее
#безперевода
✏️ О КНИГЕ
Кэл Ньюпорт написал очень актуальную и своевременную книгу с тремя принципами «медленной продуктивности». Это и интересное чтение с примерами и размышлениями о природе продуктивности и умственной работы в современном мире, и конкретные рекомендации по достижению результатов в ваших проектах (ведь, как известно, «быстро — это медленно без перерывов»).
Он предлагает фокусироваться на качестве, а не количестве, и ограничивать число проектов в работе. Число часов в сутках ограничено, и с ростом числа проектов накладные временные расходы будут съедать всё больше времени, которое пригодилось бы для основной работы. С увеличением нагрузки они могут вырасти до точки, когда обслуживание работы будет требовать столько времени, что вы не будете успевать закрывать задачи — новые будут появляться быстрее.
🔥ФИШКИ КНИГИ
— Простые правила медленной продуктивности из трёх пунктов
— В списке лучших книг 2024 года по версии редакторов Amazon
— Лучшая книга года по версии The Economist и Independent
👨💻 КТО АВТОР
Кэл Ньюпорт — преподаватель, писатель, 42 года:
— Профессор факультета информатики Джорджтаунского университета, специализируется на теории распределённых вычислительных систем и цифровой этике
— Один из лучших авторов издания New York Times
— Регулярно пишет для широкой аудитории статьи о том, как пересекаются технологии и культура, и выступает на Национальном общественном радио
— Сторонник цифрового минимализма, никогда не заводил соцсетей, но ведёт блог Study Hacks с 2007 года, который читают более 2 000 000 человек в год в стремлении жить и глубоко работать в мире, который всё больше отвлекается
— C 2022 года Кэл запустил новый портал TheDeepLife.com, на котором размещается весь контент: все прошлые эпизоды популярного подкаста и обширная библиотека оригинальных видеоматериалов, которые доступны в том числе на YouTube
📌 ЦИТАТЫ ИЗ КНИГИ
Медленная продуктивность базируется на трёх принципах:
1. Делайте меньше дел
2. Работайте в естественном темпе
3. Сосредоточьтесь на качестве
Длительные рабочие отрезки, которые не создают мгновенных результатов, могут вызывать тревожность — куда проще проверять почту или ходить со встречи на встречу, чем сесть и много часов думать над новой стратегией.
Псевдо-продуктивность — использование видимой деятельности для оценки действительно продуктивных полезных усилий. Появление электронной почты и корпоративных мессенджеров позволили создавать видимость дела с минимальными усилиями и привели к тому, что средний работник больше времени говорит о работе, чем работает.
Если вы решите делать четыре отчёта параллельно вместо одного, «накладные расходы» времени будут занимать половину рабочего дня, если не больше. В конечном итоге, делать меньше — это путь к тому, чтобы получать результаты быстрее.
Моя рекомендация проста: работайте над одним проектом каждый день. Я не имею в виду, что этот проект будет вашей единственной работой за день. У вас точно будут письма, встречи. Но если мы говорим о ключевых, важных задачах, сфокусируйтесь на движении к одной цели в рамках дня.
Люди не очень хороши в оценке времени, необходимого на выполнение умственных задач.
Простое правило: уменьшать список задач на день, который вы запланировали, на 25-50%. Мы очень оптимистичны в такого рода оценках.
(Автор этого обзора, кстати, примерно в два раза переоценил время, необходимое на его написание — хотя читал эту и многие другие книги по теме😊)
📖 ВЫХОДНЫЕ ДАННЫЕ
Slow Productivity: The Lost Art of Accomplishment Without Burnout
Portfolio, 5 марта 2024
256 стр.
Перевод названия:
Медленная продуктивность: утраченное искусство достижения целей без выгорания
Саммари на русском от Smart Reading
Автор: Ренат Шагабутдинов
Please open Telegram to view this post
VIEW IN TELEGRAM
3💯31❤🔥17⚡6🙈1
В прошлом году мы сделали небольшой surf camp в Тофино, на бергу тихого океана.
В этом году мы тоже решили сделать небольшой camp: 30 июня по 3 июля.
Присоединяйтесь:)
В этом году мы тоже решили сделать небольшой camp: 30 июня по 3 июля.
Присоединяйтесь:)
Telegram
Инжиниринг Данных
Вот и прошел наш 6ти дневный Surfalytics meetup в красивом Тофино на острове Ванкувер на берегу открытого Тихого океана.
6 дней пролетело незаметно, было 10 семей и каждый нашел свое, все попробовали серф и влюбились в это место как мы 9 лет назад.
Мы…
6 дней пролетело незаметно, было 10 семей и каждый нашел свое, все попробовали серф и влюбились в это место как мы 9 лет назад.
Мы…
❤🔥25⚡15🐳5
Labubu и Vibe Coding
Недавно дочка загорелась монстриками Labubu. Это такие брелоки - стоят недорого, но достать их почти невозможно. Кто-то вешает их на дорогие сумки, кто-то кринжует по-другому.
Дочка захотела Labubu. Окей, подумал я, всего-то $30. Нашёл сайт, где их продают - https://www.popmart.com/ca, и понял, что там какие-то дропы: ограниченное количество игрушек.
Была надпись: старт продаж в 18:30. Я поставил будильник на 18:25. Зашёл на сайт и начал кликать. Сайт дико тормозил, и уже в 18:30 все игрушки были зарезервированы.
«Так значит?» - подумал я. У меня же есть Cursor. Сейчас как на вайбе закодю - мало не покажется.
Поставил себе задачу для плагина:
- Зайти на сайт
- Ровно в 18:30 нажать Shake the Box и добавить в корзину (ADD TO CART)
Решил начать с Google Chrome плагина. Я ведь уже купил один за $7 - не работает. Cursor быстро накатал мне плагин, который умел:
- запускаться по времени,
- добавлять в корзину,
- обновлять страницу,
- показывать логи.
Даже работал на простых товарах. Дети бегали в восторге и кричали: «Папа, хакер!»
Но с Labuba — это реальный high-load. Я решил масштабировать вкладки, и в итоге всё зависло. MacBook Pro с 32 GB оперативки пришлось перезагружать вручную — hard reset🪦
Спросил у ChatGPT, какие есть варианты на Python с headless-браузером.
Стал фигачить: сначала на Playwright, потом на Selenium. Нужно было логиниться, качать cookies. В итоге потратил часов восемь на всё это. Оно вроде как работало, но было сыровато и оставалось еще много недоделок.
Было очень интересно, настоящий deep work и поток. Но, увы, другие дела-то не делаются…
На следующий день, пока я собирался на новый заход, жена прислала фото с коробками Labubu. Нашла магазинчик, где они были в наличии. Так что… вы поняли, кто тут настоящий хакер.
Когда дочка принесла их в школу — был дикий ажиотаж. Ни у кого нет, а у неё аж три.
А у вас есть Labubu?
Недавно дочка загорелась монстриками Labubu. Это такие брелоки - стоят недорого, но достать их почти невозможно. Кто-то вешает их на дорогие сумки, кто-то кринжует по-другому.
Дочка захотела Labubu. Окей, подумал я, всего-то $30. Нашёл сайт, где их продают - https://www.popmart.com/ca, и понял, что там какие-то дропы: ограниченное количество игрушек.
Была надпись: старт продаж в 18:30. Я поставил будильник на 18:25. Зашёл на сайт и начал кликать. Сайт дико тормозил, и уже в 18:30 все игрушки были зарезервированы.
«Так значит?» - подумал я. У меня же есть Cursor. Сейчас как на вайбе закодю - мало не покажется.
Поставил себе задачу для плагина:
- Зайти на сайт
- Ровно в 18:30 нажать Shake the Box и добавить в корзину (ADD TO CART)
Решил начать с Google Chrome плагина. Я ведь уже купил один за $7 - не работает. Cursor быстро накатал мне плагин, который умел:
- запускаться по времени,
- добавлять в корзину,
- обновлять страницу,
- показывать логи.
Даже работал на простых товарах. Дети бегали в восторге и кричали: «Папа, хакер!»
Но с Labuba — это реальный high-load. Я решил масштабировать вкладки, и в итоге всё зависло. MacBook Pro с 32 GB оперативки пришлось перезагружать вручную — hard reset
Спросил у ChatGPT, какие есть варианты на Python с headless-браузером.
Стал фигачить: сначала на Playwright, потом на Selenium. Нужно было логиниться, качать cookies. В итоге потратил часов восемь на всё это. Оно вроде как работало, но было сыровато и оставалось еще много недоделок.
Было очень интересно, настоящий deep work и поток. Но, увы, другие дела-то не делаются…
На следующий день, пока я собирался на новый заход, жена прислала фото с коробками Labubu. Нашла магазинчик, где они были в наличии. Так что… вы поняли, кто тут настоящий хакер.
Когда дочка принесла их в школу — был дикий ажиотаж. Ни у кого нет, а у неё аж три.
А у вас есть Labubu?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥112