Ретроспектива самых важных уроков

Ранее я писал о том, как впервые попал в сферу науки о данных. Это продолжение статьи о том, что будет дальше: как максимально использовать свою новую роль и взяться за дело. Вдохновленный некоторыми вопросами моих менторских сессий по этой теме, я привожу примеры (иногда неожиданных) вещей, которые помогли мне в то время. Задним числом 20/20. (Кстати, с 2021 годом!)

Изучение бизнес-логики необходимо даже для того, чтобы начать вносить свой вклад.

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

Статьи в СМИ: Как я вошел в область науки о данных (часть 1) (часть 2)

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

Это не школа или Kaggle с каким-то готовым набором данных или мои студенческие парсинг-проекты, где я контролировал всю логику. По большей части нам приходилось создавать нужные нам данные из того, что было доступно в очень обширном хранилище данных. Большое спасибо команде инженеров данных за то, что она вообще существовала.

В первые несколько недель я был в значительной степени мертвым грузом, пока изучал эти вещи, засыпая своего приятеля такими вопросами, как:

  • «Эй, как называется стол в Онтарио [направление бизнеса]?»
  • «Является ли столбец [идентификатор клиента] таким же, как [другое имя для того же идентификатора, но в другой таблице]?»
  • «Мне нужно вычесть день из этого столбца даты, чтобы получить нужный мне диапазон реального времени?»

Даже спустя месяцы (и годы) я все еще изучал новые фрагменты логики, лежащие в основе данных. Например, зная, где найти внутреннюю вики-страницу об отключении данных, чтобы объяснить, почему за какой-то месяц в какой-то таблице было меньше записей.

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

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

Для себя из прошлого это было открытием: «Эй, я умею программировать! Я знаю статистику!» совсем не годится как специалист по данным. На последующих должностях мне снова пришлось пройти через этот процесс изучения бизнес-значений, прежде чем приносить большую пользу с точки зрения науки о данных. И теперь, когда моя точка зрения начинает меняться в сторону того, кто предоставляет это контекстуальное знание, я держу в уме, что все это того стоит.

Пробуйте и задавайте много вопросов

Это правило действует не только в первые 90 дней, а навсегда в карьере — но чем раньше человек это осознает, тем лучше.

Чтобы начать участвовать в проектах, мне было необходимо задавать вопросы. Я знаю, каково это чувствовать себя смущенным из-за того, что задал «глупый» вопрос, но для того, чтобы команда выполнила задание, более продуктивно просто отбросить эти мысли, поскольку это не выгодно… никому.

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

Я использую эмпирическое правило: по крайней мере, попробуйте кое-что, прежде чем спрашивать. Людям не нравится, когда кто-то сначала вообще не тратит усилий на поиск решения, но дело в том, что они поймут, если вы пытались и не нашли или не вспомнили ответ.

Гораздо продуктивнее спросить: «Эй, как называется стол в Онтарио [направление бизнеса]?» когда вы также можете сказать: «Я пытался просмотреть Wiki с именами таблиц для Квебека и попытался угадать имя таблицы Онтарио на основе соглашения об именах. Но так и не появилось». (Чисто пример: в хранилище данных для этой роли было 1000 таблиц, поэтому, выбрав все имена таблиц, я мог ничего не получить. А как новичок, я не знал, как это сделать.)

Это не просто слова. Как новичок, если я по крайней мере попытаюсь использовать имеющиеся в моем распоряжении ресурсы, даже если это будет маловероятно, это поможет мне попрактиковаться в получении информации самостоятельно в будущем. Это весьма ценно и развивает независимость.

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

Временные рамки различаются: для тривиальных вещей, таких как имена таблиц, я могу попробовать быстрый поиск в базе данных, а для кода я могу использовать немного больше времени, чтобы попробовать несколько решений Stack Overflow.

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

В общем, чтобы быть эффективным разработчиком, важно пробовать что-то и задавать вопросы, чтобы разблокировать себя. Даже будучи старшим разработчиком, я не стесняюсь задавать «глупые» вопросы после того, как испробовал несколько подходов; в большинстве случаев это не смущает, поскольку просьбы помогают ускорить продвижение проекта, по большому счету.

Переведите алгоритмы в простые английские слова

Не будьте человеком, который ходит по офису и бормочет что-то вроде «Я занимался БАС (чередование наименьших квадратов)». Поясню, что это значит…

Нам, специалистам по данным, нравится болтать об оптимизации ниш и научных журналах на работе, и это нормально. На самом деле группа Совокупный интеллект, которой я руковожу (вне работы), приглашает исследователей рассказать о своей работе в области машинного обучения на высокотехнологичном уровне и имеет более 12 тысяч подписчиков на YouTube.

Но даже в этих группах, которые любят разговоры о ботаниках, я знаю, что лучший способ на рабочем месте, где есть ограниченные ресурсы внимания, чтобы заставить кого-то заботиться о моей работе, — это описать эти «крутые вещи» на простом английском языке.

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

Наряду с алгоритмом и тем, что он делает в математическом и вычислительном смысле, я научился также упоминать, что он на самом деле делает в бизнесе (например, рекомендует что-то на веб-сайте для повышения вовлеченности пользователей).

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

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

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

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

Вывод

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

Я надеюсь, что некоторые из этих мыслей были полезны! Как обычно, вы можете найти меня в LinkedIn или [email protected], чтобы обсудить этот пост.

Первоначально опубликовано на https://www.susanshu.com 3 января 2021 г.