Какой именно спрос работник, как профессионал, удовлетворяет?
Когда-то существовала профессия трубочистов и людям платили за работу, в которой сейчас никто не нуждается. Возможно это один из ярких примеров закона "спрос рождает предложение".
Я, будучи ML-инженером, удовлетворяю спрос на внедрение соответствующей технологии. Но истинная потребность компании не в моделях машинного обучения или микросервисах. Истинная потребность более сложна и состоит из нескольких частей.
Во-первых, быть более конкурентной компанией, ведь большинство инноваций - это битва с конкурентами.
Во-вторых, закрывается часть менеджерских потребностей по адекватному распределению ресурсов - какими силами и средствами будем внедрять.
В-третьих, закрывается потребность в "продуктовом видении" - зачем и как применять инновации.
Есть еще несколько аспектов, но перечисленные, на мой взгляд, наиболее яркие. Хотя в комментариях можно высказать другое мнение.
С точки зрения удовлетворения этих истинных потребностей появление ChatGPT и подобных инструментов - хорошее явление. Ведь это просто более эффективный инструмент моей работы. Как появление компьютера в эпоху печатных машинок. Осталось только научиться пользоваться компьютером. История показывает, что процесс этот будет болезненным.
Когда-то существовала профессия трубочистов и людям платили за работу, в которой сейчас никто не нуждается. Возможно это один из ярких примеров закона "спрос рождает предложение".
Я, будучи ML-инженером, удовлетворяю спрос на внедрение соответствующей технологии. Но истинная потребность компании не в моделях машинного обучения или микросервисах. Истинная потребность более сложна и состоит из нескольких частей.
Во-первых, быть более конкурентной компанией, ведь большинство инноваций - это битва с конкурентами.
Во-вторых, закрывается часть менеджерских потребностей по адекватному распределению ресурсов - какими силами и средствами будем внедрять.
В-третьих, закрывается потребность в "продуктовом видении" - зачем и как применять инновации.
Есть еще несколько аспектов, но перечисленные, на мой взгляд, наиболее яркие. Хотя в комментариях можно высказать другое мнение.
С точки зрения удовлетворения этих истинных потребностей появление ChatGPT и подобных инструментов - хорошее явление. Ведь это просто более эффективный инструмент моей работы. Как появление компьютера в эпоху печатных машинок. Осталось только научиться пользоваться компьютером. История показывает, что процесс этот будет болезненным.
Где применяется RL?
В Tesla для планирования путей беспилотных автомобилей при самостоятельной парковке. Количество возможных путей с каждым движением растет экспоненциально. Это приводит к тому, что традиционные методы планирования пути слишко долго работают. На AI Day компания Tesla показала алгоритм, основанный на AlphaGo, направленный на решение этой проблемы с помощью RL. Но иногда случаются казусы как на картинке :)
Ещё одно полезное применение RL — охлаждение дата-центров в Google. Дата-центры потребляют огромное количество энергии, а компьютеры, которые в них содержатся, рассеивают эту энергию в виде тепла. Поддержание дата-центра в работоспособном состоянии требует применения серьёзных и дорогих систем охлаждения. Благодаря RL Google смогла развернуть системы охлаждения, которые включаются лишь по необходимости, что позволяет исключить работу "в холостую".
В Tesla для планирования путей беспилотных автомобилей при самостоятельной парковке. Количество возможных путей с каждым движением растет экспоненциально. Это приводит к тому, что традиционные методы планирования пути слишко долго работают. На AI Day компания Tesla показала алгоритм, основанный на AlphaGo, направленный на решение этой проблемы с помощью RL. Но иногда случаются казусы как на картинке :)
Ещё одно полезное применение RL — охлаждение дата-центров в Google. Дата-центры потребляют огромное количество энергии, а компьютеры, которые в них содержатся, рассеивают эту энергию в виде тепла. Поддержание дата-центра в работоспособном состоянии требует применения серьёзных и дорогих систем охлаждения. Благодаря RL Google смогла развернуть системы охлаждения, которые включаются лишь по необходимости, что позволяет исключить работу "в холостую".
Недавно заходил в Decathlon за покупками спортивной снаряги. На кассе спросили телефон и почту, который называть я отказался. Выяснилось, что обязательным условием продажи является участие в их "программе лояльности". После такого заявления какая-либо лояльность у меня сразу пропадает.
В итоге свои данные оставила жена, которая не видит проблем с распространением таких данных. А я ушел с мыслью, что ценность данных не всем так очевидна.
В итоге свои данные оставила жена, которая не видит проблем с распространением таких данных. А я ушел с мыслью, что ценность данных не всем так очевидна.
На днях со знакомым обсуждали вопрос про переход его в другую компанию на руководящую позицию. Он поинтересовался, стоит ли ему переходить и какие могут быть плюсы/минусы. Рассуждение ушло в сторону определения карьерных целей и оптимизации метрики счастья. Я рассказал, как иногда бывает больно работать в компании с хаотичными процессами, размытой ответственностью и огромным легаси. Предложил ему, как будущему руководителю, оценивать возможность внедрения определенных изменений в компании, куда он собирался переходить.
И тут он меня спросил: "А откуда ты знаешь как надо делать и как делать не надо?".
Вопрос оказался не из простых и уходил в глубины моего менеджерского опыта, бизнеса и карьеры. Быстрого ответа я на этот вопрос не нашел и, наверно, все еще не могу четко на него ответить. Но почему-то у меня сложилось ощущение, что эта область знаний со мной настолько давно, что уже не вспомнить откуда она взялась.
И тут он меня спросил: "А откуда ты знаешь как надо делать и как делать не надо?".
Вопрос оказался не из простых и уходил в глубины моего менеджерского опыта, бизнеса и карьеры. Быстрого ответа я на этот вопрос не нашел и, наверно, все еще не могу четко на него ответить. Но почему-то у меня сложилось ощущение, что эта область знаний со мной настолько давно, что уже не вспомнить откуда она взялась.
Примерно каждые полгода я пытаюсь понять направление своей карьеры и думаю о том, как развиваться дальше. Сейчас как раз такой период "ревью". В прошлый период составил план-капкан, он же Personal Development Plan. К таким планам всегда относился скептически, но в них есть ценная идея - балансировка своих усилий между направлениями.
Я думал, что знаю свой план развития. Это ощущение обманчиво и относится к разряду тех, когда ты вроде бы знаешь, но это не точно. Чтобы все-таки зафиксировать этот план, решено было его записать.
В целом любой план развития - это компромисс между сферами развития и доступными умственными ресурсами. Если подойти к этому процессу, как к инвестициям умственного ресурса, то на ум приходит подход из современной портфельной теории. Идея в основе теории - набираем в портфель такие инструменты, которые в сумме дают наилучшее соотношение доходность/риск.
Так и с личным развитием - балансируем усилия по сферам с учетом вероятности освоить тот самый курс "<название_крутого_курса>" и будущей доходности этих знаний.
Звучит конечно классно, но возникает две проблемы.
Во-первых, эта самая вероятность меняется во времени от множества личных обстоятельств и оценить эту вероятность на старте весьма непросто.
Во-вторых, спрогнозировать будущую доходность знаний тоже непросто.
Я думал, что знаю свой план развития. Это ощущение обманчиво и относится к разряду тех, когда ты вроде бы знаешь, но это не точно. Чтобы все-таки зафиксировать этот план, решено было его записать.
В целом любой план развития - это компромисс между сферами развития и доступными умственными ресурсами. Если подойти к этому процессу, как к инвестициям умственного ресурса, то на ум приходит подход из современной портфельной теории. Идея в основе теории - набираем в портфель такие инструменты, которые в сумме дают наилучшее соотношение доходность/риск.
Так и с личным развитием - балансируем усилия по сферам с учетом вероятности освоить тот самый курс "<название_крутого_курса>" и будущей доходности этих знаний.
Звучит конечно классно, но возникает две проблемы.
Во-первых, эта самая вероятность меняется во времени от множества личных обстоятельств и оценить эту вероятность на старте весьма непросто.
Во-вторых, спрогнозировать будущую доходность знаний тоже непросто.
Разговаривали с коллегой про А/В тесты с синтетическим контролем. Погрузился в статью "Using Synthetic Controls:
Feasibility, Data Requirements, and Methodological Aspects " , у нее 40+ страниц текста, так что на освоение стоит закладывать время. Если дойдут руки, попробую сделать реализацию в коде. Статья интересная и, на удивление, не самая сложная.
Некоторые идеи из нее ниже 👇
Feasibility, Data Requirements, and Methodological Aspects " , у нее 40+ страниц текста, так что на освоение стоит закладывать время. Если дойдут руки, попробую сделать реализацию в коде. Статья интересная и, на удивление, не самая сложная.
Некоторые идеи из нее ниже 👇
Синтетический контроль нужен, когда у нас нет возможности провести полноценный А/В тест из-за отсутствия контрольной группы. Можно сделать контрольную группу искусственно.
По сути с помощью некоторого набора семплов и регрессии с ограничениями на веса можно создать взвешенное среднее из этих семплов, которое по своим стат. параметрам будет удовлетворять условиям контрольной группы.
За счет свойств весов (веса положительны, суммируются в единицу, должны быть разряжены) все становится интерпретируемым с вероятностной точки зрения. Зная ошибку регрессии, можно контролировать стат. значимое отличие групп и надежность теста.
Все это возможно при условии качественной модели, которая дает нормальную нулевую ошибку. Примерно 5 страниц уделено вопросу, чем опасно смещение и что в итоге делать: грамотно отбирать в трейн семплы, которые по своим наблюдаемым или не наблюдаемым характеристикам близки к таргету.
Идея не новая, но если про нее забыть, можно добиться переобучения и даже не заметить этого.
По сути с помощью некоторого набора семплов и регрессии с ограничениями на веса можно создать взвешенное среднее из этих семплов, которое по своим стат. параметрам будет удовлетворять условиям контрольной группы.
За счет свойств весов (веса положительны, суммируются в единицу, должны быть разряжены) все становится интерпретируемым с вероятностной точки зрения. Зная ошибку регрессии, можно контролировать стат. значимое отличие групп и надежность теста.
Все это возможно при условии качественной модели, которая дает нормальную нулевую ошибку. Примерно 5 страниц уделено вопросу, чем опасно смещение и что в итоге делать: грамотно отбирать в трейн семплы, которые по своим наблюдаемым или не наблюдаемым характеристикам близки к таргету.
Идея не новая, но если про нее забыть, можно добиться переобучения и даже не заметить этого.
#MLOps
Начинаю серию постов о качественной разработке ML приложений.
MLOps о том, как писать код, чтобы было не стыдно показать его коллегам и не позориться на весь интернет 🌐
Большинство крутых проектов не делается в одиночку. Командная разработка - сложная штука с точки зрения организации команды. Ведь когда ты один, никто не сделает тебе ревью, не укажет на качество кода и разные небольшие "и-так-сойдет".
Команда дисциплинирует. Чтобы настроить ее работу, нужно учитывать амбиции коллег, разные хард и софт скилы внутри команды, доступные ресурсы для разработки и много других факторов.
Честно признаюсь - несколько лет назад у меня был шанс построить идеальную команду, но в то время задача оказалась не по плечу. С тех пор набрался опыта и хочу им поделиться.
Первый пост на тему шаблонизации проекта будет на следующей неделе.
▶️ Для старта поделюсь ресурсом создания вашей MLOps архитектуры.
Начинаю серию постов о качественной разработке ML приложений.
MLOps о том, как писать код, чтобы было не стыдно показать его коллегам и не позориться на весь интернет 🌐
Большинство крутых проектов не делается в одиночку. Командная разработка - сложная штука с точки зрения организации команды. Ведь когда ты один, никто не сделает тебе ревью, не укажет на качество кода и разные небольшие "и-так-сойдет".
Команда дисциплинирует. Чтобы настроить ее работу, нужно учитывать амбиции коллег, разные хард и софт скилы внутри команды, доступные ресурсы для разработки и много других факторов.
Честно признаюсь - несколько лет назад у меня был шанс построить идеальную команду, но в то время задача оказалась не по плечу. С тех пор набрался опыта и хочу им поделиться.
Первый пост на тему шаблонизации проекта будет на следующей неделе.
▶️ Для старта поделюсь ресурсом создания вашей MLOps архитектуры.
#тру_стори
Чудо-вакансия
Недавно в чате Питерского ОДС появилось сообщение с необычной вакансией. Ребята искали ML-инженера, который мог бы для них оценивать проекты с точки зрения их бизнес-потенциала и технической инновационности «на предмет халтура внутри или нет». Все, что в кавычках - дословно, цитат дальше будет много.
Хотят найти «звезду ИИ-аналитики». Первый раз слышу такое название, похоже это придумка талантливого и крайне эффективного менеджера. Само собой, обещают чемодан денег такому уникальному человеку.
Из требований:
1. Быть сильным в рисерче, а именно смочь «прочитать и понять статью по ИИ».
2. Хотеть самому писать статьи или обзоры, что «подтвердить лекциями на ютубе и личным блогом».
3. Уметь понять, что продукт на основе API ChatGPT не прорывной, потому что «его любой кодер повторит».
Ребята «понимают, что требования сильные, но и задачи сложные».
Есть ощущение, что вакансию они закрывать будут долго.
Чудо-вакансия
Недавно в чате Питерского ОДС появилось сообщение с необычной вакансией. Ребята искали ML-инженера, который мог бы для них оценивать проекты с точки зрения их бизнес-потенциала и технической инновационности «на предмет халтура внутри или нет». Все, что в кавычках - дословно, цитат дальше будет много.
Хотят найти «звезду ИИ-аналитики». Первый раз слышу такое название, похоже это придумка талантливого и крайне эффективного менеджера. Само собой, обещают чемодан денег такому уникальному человеку.
Из требований:
1. Быть сильным в рисерче, а именно смочь «прочитать и понять статью по ИИ».
2. Хотеть самому писать статьи или обзоры, что «подтвердить лекциями на ютубе и личным блогом».
3. Уметь понять, что продукт на основе API ChatGPT не прорывной, потому что «его любой кодер повторит».
Ребята «понимают, что требования сильные, но и задачи сложные».
Есть ощущение, что вакансию они закрывать будут долго.
#инфо
Открытый курс по MLOps
По чистому совпадению на ods.ai сегодня стартует бесплатный курс по MLOps. Я в составе команды курса выполняю роль ментора/члена_жюри/человека_оркестра.
Авторы курса - опытные ML-инженеры, у которых есть чему поучиться. Курс построен не просто на контенте видео-лекций. Формат предполагает много практической работы в команде и будет полезен как начинающим, так и продолжающим ML-специалистам, разрабам и всем, кто имеет отношение к данным. Стартует курс сегодня в 18:00 МСК, до старта можно выбрать проект из доступных и присоединиться к его разработке. В конце курса предполагается защита проектов.
По опыту прошлогоднего курса - те, кто закончили этот курс, реально выросли по скиллам. Хотя для многих это было непросто.
На том же сайте можно найти прошлый выпуск курса, чтобы понять примерный уровень материала и загрузку. Удачи всем, кто решится на это приключение 🚀
Открытый курс по MLOps
По чистому совпадению на ods.ai сегодня стартует бесплатный курс по MLOps. Я в составе команды курса выполняю роль ментора/члена_жюри/человека_оркестра.
Авторы курса - опытные ML-инженеры, у которых есть чему поучиться. Курс построен не просто на контенте видео-лекций. Формат предполагает много практической работы в команде и будет полезен как начинающим, так и продолжающим ML-специалистам, разрабам и всем, кто имеет отношение к данным. Стартует курс сегодня в 18:00 МСК, до старта можно выбрать проект из доступных и присоединиться к его разработке. В конце курса предполагается защита проектов.
По опыту прошлогоднего курса - те, кто закончили этот курс, реально выросли по скиллам. Хотя для многих это было непросто.
На том же сайте можно найти прошлый выпуск курса, чтобы понять примерный уровень материала и загрузку. Удачи всем, кто решится на это приключение 🚀
#тру_стори
Был у меня опыт внедрения ML в один проект возрастом чуть больше 15 лет. В проекте было больше 20 тысяч строк кода на разных языках, части проекта при передаче от разных владельцев терялись, что-то ломалось. В общем самый настоящий кошмар программиста.
Над проектом трудилось несколько команд в совокупности из 70 человек. И вот мне, единственному ML-инженеру, была поставлена задача - внедрить сервис на основе ML.
Первая проблема была в том, что даже аналитики не знали, какие данные собираются. Пришлось вместе с ними выстроить хотя бы базовый сбор юзерских событий. Дальше выяснилось, что данных слишком много для экспериментальной машины, которую мне выделили. Потом возникли проблемы с интеграциями решения, настройкой процессов вокруг модели и еще целый ворох мелких организационных проблем.
Весь этот вандализм длился чуть больше 8 месяцев.
Все это время меня не покидала мысль, что проект двигается не благодаря, а вопреки разработчикам.
Почему так происходит? Думается, что из-за стадии жизни проекта. По сути проект на этапе «дойная корова», а это подпитывает нежелание что-то менять со стороны всех участников.
В таких случаях создают специальную команду изменений, куда включают наиболее заинтересованных в развитии проекта людей. Их задача - создать атмосферу стартапа и двигать проект сильно быстрее.
Был у меня опыт внедрения ML в один проект возрастом чуть больше 15 лет. В проекте было больше 20 тысяч строк кода на разных языках, части проекта при передаче от разных владельцев терялись, что-то ломалось. В общем самый настоящий кошмар программиста.
Над проектом трудилось несколько команд в совокупности из 70 человек. И вот мне, единственному ML-инженеру, была поставлена задача - внедрить сервис на основе ML.
Первая проблема была в том, что даже аналитики не знали, какие данные собираются. Пришлось вместе с ними выстроить хотя бы базовый сбор юзерских событий. Дальше выяснилось, что данных слишком много для экспериментальной машины, которую мне выделили. Потом возникли проблемы с интеграциями решения, настройкой процессов вокруг модели и еще целый ворох мелких организационных проблем.
Весь этот вандализм длился чуть больше 8 месяцев.
Все это время меня не покидала мысль, что проект двигается не благодаря, а вопреки разработчикам.
Почему так происходит? Думается, что из-за стадии жизни проекта. По сути проект на этапе «дойная корова», а это подпитывает нежелание что-то менять со стороны всех участников.
В таких случаях создают специальную команду изменений, куда включают наиболее заинтересованных в развитии проекта людей. Их задача - создать атмосферу стартапа и двигать проект сильно быстрее.
#MLOps
Как мы начинаем писать код? Обычно примерно в голове прикидываем структуру модулей и начинаем писать. Я так делал и иногда продолжаю делать сейчас. Со временем структура кода может меняться, иногда весьма сильно, что доставляет много головной боли. В какой-то момент я пришел собственному "скелету" кода, а потом наткнулся на сookiecutter.
Ниже будет разбор этого инструмента на примере DS-проекта 👇
Как мы начинаем писать код? Обычно примерно в голове прикидываем структуру модулей и начинаем писать. Я так делал и иногда продолжаю делать сейчас. Со временем структура кода может меняться, иногда весьма сильно, что доставляет много головной боли. В какой-то момент я пришел собственному "скелету" кода, а потом наткнулся на сookiecutter.
Ниже будет разбор этого инструмента на примере DS-проекта 👇
Вот шаблон data-science-проекта.
Применил этот шаблон в командном проекте, что сильно упростило разработку. К сожалению, шаблон заточен под DS-проект, поэтому структурой проекта авторы решают проблему воспроизводимости анализа и потоков данных, но не проблему production-ready кода (это было бы слишком). Прелесть шаблона в том, что мы можем на его основе сделать свой с блекджеком и эндпоинтами.
Концепция этого шаблона следует практикам бекенд разработки. Например, при работе с django не возникает вопросов о том, куда поместить тот или иной модуль. Сама структура кода django-проекта позволяет не думать о взаимозависимостях с другими модулями. Хорошо организованный код имеет тенденцию к самодокументированию, ведь его структура обеспечивает контекст восприятия без особых когнитивных расходов.
За нас написали полезный функционал: есть автогенерация документации на основе Sphinx, файлы сетапа и настроек проекта, шаблоны модулей обработки данных.
С точки зрения потоков данных шаблон построен на идеи "Analysis is a DAG", что как раз решает проблему воспроизводимости.
Больше того, уже существует множество шаблонов для самых разных сервисов, которые можно найти по запросу "cookiecutter <твой_сервис>".
К этому инструменту у меня не возникло аллергии, поэтому советую попробовать.
В комментариях можно поделиться болью про организацию кода в твоем проекте. Говорят, от этого становится легче 🫢
Применил этот шаблон в командном проекте, что сильно упростило разработку. К сожалению, шаблон заточен под DS-проект, поэтому структурой проекта авторы решают проблему воспроизводимости анализа и потоков данных, но не проблему production-ready кода (это было бы слишком). Прелесть шаблона в том, что мы можем на его основе сделать свой с блекджеком и эндпоинтами.
Концепция этого шаблона следует практикам бекенд разработки. Например, при работе с django не возникает вопросов о том, куда поместить тот или иной модуль. Сама структура кода django-проекта позволяет не думать о взаимозависимостях с другими модулями. Хорошо организованный код имеет тенденцию к самодокументированию, ведь его структура обеспечивает контекст восприятия без особых когнитивных расходов.
За нас написали полезный функционал: есть автогенерация документации на основе Sphinx, файлы сетапа и настроек проекта, шаблоны модулей обработки данных.
С точки зрения потоков данных шаблон построен на идеи "Analysis is a DAG", что как раз решает проблему воспроизводимости.
Больше того, уже существует множество шаблонов для самых разных сервисов, которые можно найти по запросу "cookiecutter <твой_сервис>".
К этому инструменту у меня не возникло аллергии, поэтому советую попробовать.
В комментариях можно поделиться болью про организацию кода в твоем проекте. Говорят, от этого становится легче 🫢
drivendata.github.io
Cookecutter Data Science
🙈 В пятницу вечером начинать не стоит...
Топ-5 вопросов, которые нужно задать перед началом работы над проектом.
Опытные разработчики задают хорошо структурированные вопросы, без лишних слов и с достаточным количеством исходных данных. Хороший вопрос во многом похож на красивый код. На собеседовании и во время испытательного срока работодатель по вашим вопросам оценивает ваш ход мысли, умение анализировать, подход к обработке задач. Ваши вопросы — это второе портфолио, способ продемонстрировать себя и свои навыки, подход к решению задач и проблем.
Вопросы помогают сэкономить время. Да, перед тем как задавать вопросы, важно уделить время самостоятельному поиску. Но здесь важно не увлечься и не потратить весь день на то, чтобы найти ответ на один вопрос. Если через пару часов решение не нашлось — самое время спросить.
Индустрия быстро растёт и меняется. На протяжении всей карьеры вам придётся задавать вопросы тем, кто в курсе новых технологий. Огромную часть вашего времени будет занимать общение с коллегами. Помните - нанимают за харды, увольняют за софты.
Содержательный вопрос показывает тому, кто его прочитал, что вы столкнулись с проблемой, пробовали решать её самостоятельно, подумали — и только потом пришли за помощью. Они выстроены так, что адресат быстро понимает, в чём проблема: ему удобно читать и отвечать на такой вопрос.
Например, вы сообщаете, что ознакомились с документацией к проекту, посмотрели код в репозитории, посмотрели ТЗ на задачу и предлагаете решение. После этого стоит спросить:
1. Насколько быстро и безболезненно предложенное решение может быть встроено в проект? Нужно ли что-то в нем кардинально изменить?
2. Какие есть ограничения по времени и памяти для работы кода?
3. Какие потоки данных будут затронуты моим решением, что я должен знать про данные?
4. Существует ли метрика, которую мне нужно улучшить через выполнение таски? Как она рассчитывается?
5. Что предусмотрено в Definition of Done для задачи?
На все эти вопросы сначала стоит ответить самостоятельно, потом подробно расписать детали в черновике или воспользоваться методом rubber duck debugging. Если предыдущие шаги не добавили ясности, стоит спросить более опытного коллегу или постановщика задачи.
Зачастую правильная формулировка вопроса содержит как минимум половину ответа.
Топ-5 вопросов, которые нужно задать перед началом работы над проектом.
Опытные разработчики задают хорошо структурированные вопросы, без лишних слов и с достаточным количеством исходных данных. Хороший вопрос во многом похож на красивый код. На собеседовании и во время испытательного срока работодатель по вашим вопросам оценивает ваш ход мысли, умение анализировать, подход к обработке задач. Ваши вопросы — это второе портфолио, способ продемонстрировать себя и свои навыки, подход к решению задач и проблем.
Вопросы помогают сэкономить время. Да, перед тем как задавать вопросы, важно уделить время самостоятельному поиску. Но здесь важно не увлечься и не потратить весь день на то, чтобы найти ответ на один вопрос. Если через пару часов решение не нашлось — самое время спросить.
Индустрия быстро растёт и меняется. На протяжении всей карьеры вам придётся задавать вопросы тем, кто в курсе новых технологий. Огромную часть вашего времени будет занимать общение с коллегами. Помните - нанимают за харды, увольняют за софты.
Содержательный вопрос показывает тому, кто его прочитал, что вы столкнулись с проблемой, пробовали решать её самостоятельно, подумали — и только потом пришли за помощью. Они выстроены так, что адресат быстро понимает, в чём проблема: ему удобно читать и отвечать на такой вопрос.
Например, вы сообщаете, что ознакомились с документацией к проекту, посмотрели код в репозитории, посмотрели ТЗ на задачу и предлагаете решение. После этого стоит спросить:
1. Насколько быстро и безболезненно предложенное решение может быть встроено в проект? Нужно ли что-то в нем кардинально изменить?
2. Какие есть ограничения по времени и памяти для работы кода?
3. Какие потоки данных будут затронуты моим решением, что я должен знать про данные?
4. Существует ли метрика, которую мне нужно улучшить через выполнение таски? Как она рассчитывается?
5. Что предусмотрено в Definition of Done для задачи?
На все эти вопросы сначала стоит ответить самостоятельно, потом подробно расписать детали в черновике или воспользоваться методом rubber duck debugging. Если предыдущие шаги не добавили ясности, стоит спросить более опытного коллегу или постановщика задачи.
Зачастую правильная формулировка вопроса содержит как минимум половину ответа.
Wikipedia
Метод утёнка
психологический метод решения задачи
#MLOps
Если кто еще не слышал, то на прошлой неделе был опубликован код системы рекомендаций твиттера. Сейчас вокруг меня много говорят про разные особенности этой системы - закладки от гос.органов или политическую направленность. Пост не об этом.
ML-часть этой системы тоже стала открытой, ее можно найти здесь, а заодно посмотреть на практики работы с кодом. Ниже некоторые мысли на этот счет 👇👇👇
Если кто еще не слышал, то на прошлой неделе был опубликован код системы рекомендаций твиттера. Сейчас вокруг меня много говорят про разные особенности этой системы - закладки от гос.органов или политическую направленность. Пост не об этом.
ML-часть этой системы тоже стала открытой, ее можно найти здесь, а заодно посмотреть на практики работы с кодом. Ниже некоторые мысли на этот счет 👇👇👇