"Часы работы"

Семь советов, как оставаться организованным в мире науки о данных

Помогаем вам оптимизировать рабочий процесс за счет организации повседневных занятий

В моей повседневной работе инженером по машинному обучению (MLE) я жонглирую довольно много мячей. Я поддерживаю несколько моделей в производстве, активно работаю над многими новыми проектами моделирования, участвую в качестве администратора в регулярных «встречах группы навыков» в нашей области и являюсь мастером схватки моей команды MLE. Я всегда готов сказать «да» на любую просьбу и более чем рад помочь товарищу по команде, в чем он застрял.

Что вас может удивить, так это то, что я не считаю себя очень занятым человеком.

Не поймите меня неправильно, я все время занят. (Если мой менеджер читает это, мне не больно по работе! 😂) Я просто никогда не доходил до того момента, когда я был занят «рванием волос». Если вы не знакомы с моим прошлым, я - немного аномалия в мире науки о данных. До того, как стать инженером по машинному обучению, я работал исключительно на бизнес-должностях. Моя степень магистра связана с организационным лидерством, и у меня есть несколько званий руководства / менеджмента.

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

1. Приведите свой git в порядок.

Создание систем для организации - это то, чем я люблю заниматься во всех сферах моей жизни, и я обнаружил, что это чрезвычайно полезно, когда дело доходит до организации моего кода. Все мои репозитории обрисованы в общих чертах одинаково, поэтому, если я когда-нибудь перехожу от усилия к усилию, я точно знаю, где найти определенные фрагменты информации. Если вы хотите получить дополнительную фантазию, вы можете даже придумать шаблон Cookie Cutter, чтобы автоматизировать структуру ваших репозиториев Git при инициализации. Вообще говоря, я организовываю свои репозитории в следующих каталогах:

  • Данные: здесь хранятся данные, которые мне нужны (если не в общем месте).
  • Модели: как ни странно, здесь находятся мои сохраненные файлы моделей.
  • Зависимости: он содержит такие вещи, как файл требований Python, и другие вещи, необходимые для поддержки моих усилий в производственной среде.
  • Тесты: в этом каталоге хранятся скрипты, которые я использую для тестирования, от модульных тестов до интеграционных тестов. Он также будет содержать несколько тестовых файлов JSON на случай, если мне нужно протестировать API в реальном времени в производственной среде.
  • Контейнер: я много работаю с контейнерами Docker (и я бы посоветовал вам поступить так же), поэтому этот каталог содержит все необходимые рабочие файлы, чтобы можно было делать все, что мне нужно, в образе Docker. Например, этот каталог может содержать файлы для включения чего-то вроде Flask API.
  • Блокноты: если мне когда-нибудь понадобится выполнить работу по обнаружению или «доказательству концепции» в блокнотах Jupyter, я помещу их все в один и тот же каталог.
  • K8s / Terraform: в зависимости от того, работаю ли я в Kubernetes или AWS, я создаю каталог для размещения соответствующих файлов, которые создают необходимые мне ресурсы в соответствующих средах.

2. Интегрируйте соответствующий уровень ведения журналов / предупреждений.

Это в большей степени относится к случаям, когда вы запускаете что-то в производство, но вы можете значительно упростить себе жизнь, если установите соответствующие журналы или предупреждения в своей прогнозной модели. Мне часто задают вопросы от деловых партнеров о входных данных, переданных в конкретную модель. Для постоянной проверки модели вам следует отказаться от этого, но я сделаю еще один шаг, создав отдельные журналы, более подходящие для данной ситуации. Например, если модель принимает более 100 функций в качестве входных данных, может иметь смысл сохранить другой файл журнала, который содержит только 10 из этих часто вызываемых вопросов. Позже вам будет намного проще разобрать!

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

3. Примите философию «нулевого почтового ящика».

Вы, возможно, слышали об этом раньше, и я считаю, что это особенно ценно в моей роли инженера по машинному обучению. Короче говоря, идея состоит в том, чтобы ваш почтовый ящик был как можно более чистым. Прочитав письмо, вы должны сохранить его в соответствующей папке. Благодаря возможностям «поиска», доступным в каждом современном почтовом сервисе, я храню свои электронные письма, рассортированные по «корзинам» довольно высокого уровня. Я не могу поделиться тем, что у меня есть для работы, но скажу вам, что я регулярно храню файлы только в 5 папках. Поддерживая чистоту своего почтового ящика, вы гарантируете, что все увидите и сможете своевременно со всем справиться.

4. Напишите свой код до подходящего уровня.

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

5. Всегда комментируйте свою работу.

Хороший программист всегда будет знать, что делает код при внимательном его изучении, но не всегда становится ясно при первом чтении. Чтобы помочь другим, а также забывчивому себе, я всегда аннотирую свою работу комментариями к коду, чтобы точно знать, что делает мой код. Это также помогает сделать код читаемым намного быстрее. Например, у вас может быть 5–10 строк кода, выполняющих определенное преобразование данных. Вы можете написать простой аннотированный комментарий, чтобы проинформировать вас об этом, а позже, когда вы захотите сослаться на что-то, вы можете быстро просмотреть тонны кода, чтобы найти именно то, что вы ищете.

6. Запишите, что вам нужно сделать за данную неделю.

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

7. Определите свои приоритеты.

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

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