#QA
В рубрике QA я отвечаю на вопросы, заданные ранее подписчиками в гугл-форме
Вопросы принимаются постоянно, отвечать на них буду тоже постоянно, но в произвольном порядке, так что никакого SLA пока что не гарантирую. Сегодня у нас весьма любопытный вопрос: «Что важнее для руководителя в Data Science: лояльность или профессионализм?»
Есть такое понятие как гигиенические факторы — те вещи, которые нужно просто держать в норме, а не стремиться наращивать бесконечно. К ним, кстати, для большинства сотрудников относится и зарплата, но об этом поговорим в другой раз. Я думаю, что для опытного руководителя в Data Science лояльность сотрудника — тоже гигиенический параметр. Главное, чтобы с ней все было более-менее нормально или хотя бы не слишком плохо, а ключевой параметр всё же профессионализм. Но если профессионализм для аналитика данных еще более-менее понятное качество, то вот лояльность вещь туманная.
Мне кажется, что в технократической среде, априори склонной к скептицизму и критическому отношению к любой информации, это понятие имеет довольно тонкий смысл. Лояльность здесь подразумевает понимание базовых принципов руководства людьми, и бережное отношение к этим механизмам при взаимодействии с начальством.
Поясню примером. Допустим, вам есть за что покритиковать своего руководителя, но вы понимаете, что нарушение субординации при свидетелях может подорвать его авторитет у коллег и усложнить ему жизнь. Поэтому вы говорите с ним тет-а-тет. Кстати, понимание того, как работает руководство людьми, приводит и к выводу, что в этой ситуации лучше переформулировать недовольство как вопрос — почему происходит так как происходит (избегая интонаций наезда). Уже после предметного диалога, если после получения более полной картины ситуации, вы всё еще чем-то недовольны, важно явно, но вежливо сказать, что это для вас не ок. После этого кратко сформулировать, почему, и попросить это принять во внимание (опять же, скромно и без гонора). Пример показывает, как даже выражая несогласие, оставаться лояльным в технократическом смысле — понимать, как все устроено, и решать проблему, а не приносить руководству кучу дополнительных проблем.
Остается вопрос: что делать, если руководство не слышит, когда вы разговариваете с ним вежливо? Смотрите сами - если вы можете себе позволить еще несколько раз, все более четко, указать на проблему — пробуйте достучаться или получить адекватный ответ, что вы упускаете в своих просьбах. Если же вам уже не до этого — меняйте отдел или компанию. Место работы — это не страна проживания, сменить проще. Есть еще ряд других вариантов действий, но это уже black magic, и про это я рассказывать не буду, т.к. не одобряю 🙂
В рубрике QA я отвечаю на вопросы, заданные ранее подписчиками в гугл-форме
Вопросы принимаются постоянно, отвечать на них буду тоже постоянно, но в произвольном порядке, так что никакого SLA пока что не гарантирую. Сегодня у нас весьма любопытный вопрос: «Что важнее для руководителя в Data Science: лояльность или профессионализм?»
Есть такое понятие как гигиенические факторы — те вещи, которые нужно просто держать в норме, а не стремиться наращивать бесконечно. К ним, кстати, для большинства сотрудников относится и зарплата, но об этом поговорим в другой раз. Я думаю, что для опытного руководителя в Data Science лояльность сотрудника — тоже гигиенический параметр. Главное, чтобы с ней все было более-менее нормально или хотя бы не слишком плохо, а ключевой параметр всё же профессионализм. Но если профессионализм для аналитика данных еще более-менее понятное качество, то вот лояльность вещь туманная.
Мне кажется, что в технократической среде, априори склонной к скептицизму и критическому отношению к любой информации, это понятие имеет довольно тонкий смысл. Лояльность здесь подразумевает понимание базовых принципов руководства людьми, и бережное отношение к этим механизмам при взаимодействии с начальством.
Поясню примером. Допустим, вам есть за что покритиковать своего руководителя, но вы понимаете, что нарушение субординации при свидетелях может подорвать его авторитет у коллег и усложнить ему жизнь. Поэтому вы говорите с ним тет-а-тет. Кстати, понимание того, как работает руководство людьми, приводит и к выводу, что в этой ситуации лучше переформулировать недовольство как вопрос — почему происходит так как происходит (избегая интонаций наезда). Уже после предметного диалога, если после получения более полной картины ситуации, вы всё еще чем-то недовольны, важно явно, но вежливо сказать, что это для вас не ок. После этого кратко сформулировать, почему, и попросить это принять во внимание (опять же, скромно и без гонора). Пример показывает, как даже выражая несогласие, оставаться лояльным в технократическом смысле — понимать, как все устроено, и решать проблему, а не приносить руководству кучу дополнительных проблем.
Остается вопрос: что делать, если руководство не слышит, когда вы разговариваете с ним вежливо? Смотрите сами - если вы можете себе позволить еще несколько раз, все более четко, указать на проблему — пробуйте достучаться или получить адекватный ответ, что вы упускаете в своих просьбах. Если же вам уже не до этого — меняйте отдел или компанию. Место работы — это не страна проживания, сменить проще. Есть еще ряд других вариантов действий, но это уже black magic, и про это я рассказывать не буду, т.к. не одобряю 🙂
👍1
#QA
Есть ли такие задачи, где ML, в любом виде, будет работать примерно как подбрасывание монетки? Не хотелось бы начинать заранее безнадёжный проект по анализу спортивной статистики 😉
Если под задачей подразумевать "спрогнозировать ответ y по данным X", то конечно бывают данные, по которым ничего не спрогнозируешь. А по любым, даже довольно хорошим данным, все равно можно предсказать не всё, есть предел качества. В машинном обучении традиционно рассматривают ошибку алгоритма как сумму трёх вещей: смещения, разброса и шума. Если хотите, это три разных по смыслу части ошибки прогноза. Так вот шум - это часть, обусловленная сугубо случайностью, это оценка снизу для ошибки алгоритма. Меньше не бывает! (Если говорить о среднестатистической ошибке, а разово, конечно, можно и угадать) Отвечая на вопрос про анализ спортивной статистики, до какой-то степени спортивные прогнозы можно успешно делать с помощью ML, и есть примеры стартапов, которым удается на этом зарабатывать (в том числе российских стартапов), но супер точности здесь ожидать не стоит.
Например, одни знакомые применяют ML в Daily Fantasy Sports - там вы набирате вирутальную команду из игроков (на ограничнный бюджет) и в зависимости от результатов игроков в реальных играх получаются баллы вашей команды, которыми вы соревнуетесь с другими. С одной стороны, вполне можно прогнозировать сколько баллов наберет каждый игрок, и с учетом этого укомплектовывать команду. Но различные "редкие" события в духе получения травм или выхода игрока на нетипичную для него позицию сильно ломают прогноз. При этом зная, что кто-то вчера получил травму, вы иногда сами можете лучше скорректировать свои действия, чем это сделает алгоритм, не обладающий этой информацией. Модели даже сложно научиться нормально учитывать травмы - т.к. для того, чтобы ее этому обучить, нужна большая обучающая выборка (тысячи объектов). Ее обычно нет. Кроме того есть другой фактор, портящий прогнозы - изменение правил.
В общем я бы рекомендовал заниматься задачами, где данных достаточно для обучения, все важные для прогноза вещи автоматически логгируются в данных, а постановка задачи не меняется с течением времени слишком быстро. Возможно в спортивной аналитике такие тоже есть.
Есть ли такие задачи, где ML, в любом виде, будет работать примерно как подбрасывание монетки? Не хотелось бы начинать заранее безнадёжный проект по анализу спортивной статистики 😉
Если под задачей подразумевать "спрогнозировать ответ y по данным X", то конечно бывают данные, по которым ничего не спрогнозируешь. А по любым, даже довольно хорошим данным, все равно можно предсказать не всё, есть предел качества. В машинном обучении традиционно рассматривают ошибку алгоритма как сумму трёх вещей: смещения, разброса и шума. Если хотите, это три разных по смыслу части ошибки прогноза. Так вот шум - это часть, обусловленная сугубо случайностью, это оценка снизу для ошибки алгоритма. Меньше не бывает! (Если говорить о среднестатистической ошибке, а разово, конечно, можно и угадать) Отвечая на вопрос про анализ спортивной статистики, до какой-то степени спортивные прогнозы можно успешно делать с помощью ML, и есть примеры стартапов, которым удается на этом зарабатывать (в том числе российских стартапов), но супер точности здесь ожидать не стоит.
Например, одни знакомые применяют ML в Daily Fantasy Sports - там вы набирате вирутальную команду из игроков (на ограничнный бюджет) и в зависимости от результатов игроков в реальных играх получаются баллы вашей команды, которыми вы соревнуетесь с другими. С одной стороны, вполне можно прогнозировать сколько баллов наберет каждый игрок, и с учетом этого укомплектовывать команду. Но различные "редкие" события в духе получения травм или выхода игрока на нетипичную для него позицию сильно ломают прогноз. При этом зная, что кто-то вчера получил травму, вы иногда сами можете лучше скорректировать свои действия, чем это сделает алгоритм, не обладающий этой информацией. Модели даже сложно научиться нормально учитывать травмы - т.к. для того, чтобы ее этому обучить, нужна большая обучающая выборка (тысячи объектов). Ее обычно нет. Кроме того есть другой фактор, портящий прогнозы - изменение правил.
В общем я бы рекомендовал заниматься задачами, где данных достаточно для обучения, все важные для прогноза вещи автоматически логгируются в данных, а постановка задачи не меняется с течением времени слишком быстро. Возможно в спортивной аналитике такие тоже есть.
#QA Почему между продуктивностью программистов такая огромная разница?
Есть много причин, мне хочется выделить три, чтобы не увлечься перечислением, которое выльется в лонгрид.
Первая причина показана в прикрепленном к сообщению меме (на самом деле это выпуск xkcd, ну да кто уже помнит, что это такое). Для кого-то "оно компиллируется", "оно обучается", "оно считается" - это серьезный повод для паузы в работе. А для кого-то - нет, и он параллельно занимается другой задачей, а не работает в однопоточном режиме. Важный момент: в однопоточности есть свой плюс, а в частой смене контекстов даже между двумя задачами есть минусы, нужно разбираться, что для вас работает эффективнее, и такой подход и применять. Однако в большинстве случаев люди на работе имея возможность попродалбываться и подождать чего-то эту возможность ни в коем случае не упускают :) То же самое касается болтовни на работе. Кто-то ходит по десятому совещанию, чтобы принять решение о цвете кнопки, а кто-то уже все сделал, протестировал и выкатил, а тупой болтовней на 10 человек не занимался (за что был бы ненавидим всеми менеджерами, если бы не деливерил быстрее всех). В офисе любая работа может занять сколь угодно большое отпущенное на нее время, главная сложность - не участвовать в коллективном сжигании этого времени в топке пустых, чудовищно медленных разговоров. И не думайте, что это легко, шибко умным и шибко производительным коллектив даст понять, что так не принято, так что чтобы не заниматься фигней нужен определенный профессионализм, смелось, и даже талант.
Вторая причина в опыте. Человек, который имеет хороший кругозор (либо многое видел и многое делал в рамках работы, либо имеет хорошее образование, а лучше и то и другое), может идти к решению задачи по кратчайшему или почти кратчайшему пути. А еще не занимается преждевременной оптимизацией и может выбрать оптимальный вариант по сложности и функциональности решения. Это может экономить время на порядок. Почему на порядок? Ну потому что написать одно хорошее решение в десять раз быстрее, чем девять кривых, пока поймешь как надо на своем опыте. Кроме того, бывалый разработчик видит, когда менеджеры еще 10 раз поменяют запрос и экономит силы на исполнении первой же версии, а освободившееся время посвящает другим задачам, коих всегда хватает. Этому уже в университетах не научат, только на своем опыте, и это немного противоречит на первый взгляд причине 1. Но если кратко: бессознательное продалбывание времени - зло, экономное отношение к своему рабочему времени по причине еще уточняющейся постановки задачи - источник дополнительного времени на уже понятные задачи.
Третья причина в том, что обычно разработчик это наемный сотрудник, но при этом умный человек. Его зарплата не увеличится вдвое, если он будет работать вдвое больше. В лучшем случае за трудовые подвиги хорошего разработчика сделают плохим тимлидом и придется еще и менеджментом заниматься вместо любимого дела. Так что оптимальное решение - работать ровно столько и с такой скоростью, чтобы делать задачи приемлемо для бизнеса, а когда аврал или хочется повышения - поднажать. Заодно к авралу или зарплатным амбициями не выгоришь. А еще бывает, что специально работаешь на 70%, чтобы постепенно наращивать и получать левел-ап, а тебя повышают, когда ты все еще на уровне 70% и не начал реализовывать свой хитрый план. Такие вот дела. Вы скажете: он же любит программировать, почему тогда не работает по-полной? Ну как же, какие-то работают. А какие-то найдут вторую работу или сделают клевый пет-проект. И вообще-то говоря имеют полное право.
Есть много причин, мне хочется выделить три, чтобы не увлечься перечислением, которое выльется в лонгрид.
Первая причина показана в прикрепленном к сообщению меме (на самом деле это выпуск xkcd, ну да кто уже помнит, что это такое). Для кого-то "оно компиллируется", "оно обучается", "оно считается" - это серьезный повод для паузы в работе. А для кого-то - нет, и он параллельно занимается другой задачей, а не работает в однопоточном режиме. Важный момент: в однопоточности есть свой плюс, а в частой смене контекстов даже между двумя задачами есть минусы, нужно разбираться, что для вас работает эффективнее, и такой подход и применять. Однако в большинстве случаев люди на работе имея возможность попродалбываться и подождать чего-то эту возможность ни в коем случае не упускают :) То же самое касается болтовни на работе. Кто-то ходит по десятому совещанию, чтобы принять решение о цвете кнопки, а кто-то уже все сделал, протестировал и выкатил, а тупой болтовней на 10 человек не занимался (за что был бы ненавидим всеми менеджерами, если бы не деливерил быстрее всех). В офисе любая работа может занять сколь угодно большое отпущенное на нее время, главная сложность - не участвовать в коллективном сжигании этого времени в топке пустых, чудовищно медленных разговоров. И не думайте, что это легко, шибко умным и шибко производительным коллектив даст понять, что так не принято, так что чтобы не заниматься фигней нужен определенный профессионализм, смелось, и даже талант.
Вторая причина в опыте. Человек, который имеет хороший кругозор (либо многое видел и многое делал в рамках работы, либо имеет хорошее образование, а лучше и то и другое), может идти к решению задачи по кратчайшему или почти кратчайшему пути. А еще не занимается преждевременной оптимизацией и может выбрать оптимальный вариант по сложности и функциональности решения. Это может экономить время на порядок. Почему на порядок? Ну потому что написать одно хорошее решение в десять раз быстрее, чем девять кривых, пока поймешь как надо на своем опыте. Кроме того, бывалый разработчик видит, когда менеджеры еще 10 раз поменяют запрос и экономит силы на исполнении первой же версии, а освободившееся время посвящает другим задачам, коих всегда хватает. Этому уже в университетах не научат, только на своем опыте, и это немного противоречит на первый взгляд причине 1. Но если кратко: бессознательное продалбывание времени - зло, экономное отношение к своему рабочему времени по причине еще уточняющейся постановки задачи - источник дополнительного времени на уже понятные задачи.
Третья причина в том, что обычно разработчик это наемный сотрудник, но при этом умный человек. Его зарплата не увеличится вдвое, если он будет работать вдвое больше. В лучшем случае за трудовые подвиги хорошего разработчика сделают плохим тимлидом и придется еще и менеджментом заниматься вместо любимого дела. Так что оптимальное решение - работать ровно столько и с такой скоростью, чтобы делать задачи приемлемо для бизнеса, а когда аврал или хочется повышения - поднажать. Заодно к авралу или зарплатным амбициями не выгоришь. А еще бывает, что специально работаешь на 70%, чтобы постепенно наращивать и получать левел-ап, а тебя повышают, когда ты все еще на уровне 70% и не начал реализовывать свой хитрый план. Такие вот дела. Вы скажете: он же любит программировать, почему тогда не работает по-полной? Ну как же, какие-то работают. А какие-то найдут вторую работу или сделают клевый пет-проект. И вообще-то говоря имеют полное право.
❤40👍14🤯1