Верните свое время, чтобы написать больше кода и решений для данных!
Вы всегда чувствуете, что не используете свое время продуктивно? Ты не один!
Многие инженеры данных сталкиваются с трудностями, пытаясь максимизировать свою производительность и достичь совершенства, на которое, как они знают, они способны. Но не бойтесь, этот пост в блоге поможет вам.
Узнайте, как повысить свою карьеру инженера данных, чтобы превзойти своих коллег, освоив эти пять основных методов повышения производительности, и раскройте секреты, которые выделят вас в этой высококонкурентной отрасли!
«Производительность никогда не бывает случайной. Это всегда результат стремления к совершенству, разумного планирования и целенаправленных усилий». - Пол Дж. Мейер.
Будьте движущей силой, чтобы вернуть себе концентрацию
Как инженер данных, вы отвечаете за управление огромными объемами данных и обеспечение их качества и доступности. Это требует высокого уровня концентрации и самоотверженности. Распознавайте отвлекающие факторы, характерные для вашей роли, такие как частые оповещения о данных, специальные запросы, сложные задачи по отладке или просто огромное количество совещаний, и устанавливайте более жесткие ограничения для эффективного управления ими.
1. Откажитесь от необязательных встреч
Один из самых больших налогов на энергию — это встречи подряд, никому не нравится быть на встрече, которая могла бы быть электронной почтой, мы не менеджеры, которые любят свои встречи!
Инженерам данных требуется много глубокой работы для реализации своих конвейеров данных, запросов на моделирование данных или поиска ошибки, которая приводит к сбою качества ваших данных.
Все эти встречи сильно отвлекают, а несколько встреч подряд даже вызывают сильный стресс, который будет влиять на вас до конца дня, как показано в исследовании Microsoft ниже.
Если вы ничего не приносите на встречу, просто откажитесь, если вы просто слушаете и не говорите ни слова, то коллега мог просто подвести итоги встречи и вместо этого отправить вам сообщение.
2. Блокировать уведомления о сообщениях
Как Data Engineers, нам часто приходится общаться с большим количеством разных людей, и наш мониторинг качества данных связан с приложениями для обмена сообщениями.
Как часто вы слышите звуковой сигнал приложения для обмена сообщениями (Teams, Slack, Google Chat и т. д.)? Каждый раз, когда вы слышите это, вы мгновенно отвлекаетесь.
Даже если вы не смотрите на них, ваш разум уже блуждает и думает о том, о чем сообщение. И мы любопытны, как человеческие существа, и проверка сообщения — это система удовлетворения для нашего дофамина.
Блокируя уведомления, мы можем избежать этого отрицательного цикла. Вместо этого мы назначаем время, когда вы хотите проверить свой почтовый ящик, сообщения и т. д.
Таким образом, вы установили здоровую границу, и ваши коллеги не нуждаются в вас прямо сейчас, даже если они им нужны, то они могут позвонить вам в экстренных случаях. Если они заблокированы, и вы их спаситель, чтобы разблокировать их, то они могут просто работать над другой задачей, пока вы не ответите.
Сообщите им расписание ваших сообщений, чтобы они знали, когда ожидать ответа или рассчитывайте его время вокруг ваших блоков сообщений; вы можете сделать это в отдельном документе, указав, как вы хотите, чтобы ваши коллеги связывались с вами. Я вернусь к этой теме и создам отдельный документ для этого в следующей записи блога.
3. Запланируйте фокус-блоки
Блоки внимания – это моменты в течение дня, когда вы можете полностью сосредоточиться на одной задаче. Идея в том, что вы устанавливаете определенный блок времени (я заметила, что для себя я предпочитаю блоки не менее 2 часов) и полностью отключаетесь от любых возможных отвлекающих факторов.
Таким образом, вы можете быстрее войти в состояние «зоны» и получить гораздо более высокое качество кода. Идеальное время, чтобы подумать о дизайне кода, архитектуре данных или просто о создании хороших, простых в тестировании функций для ваших идемпотентных конвейеров данных!
Обязательно запланируйте свои фокус-блоки заранее, чтобы вы могли как можно чаще планировать встречи вне их, а также общаться со своими непосредственными коллегами, когда вы будете вдали от любого шума.
Создавайте границы, когда люди могут называть вас «бодрствующими», например, когда есть критическая ошибка, которую можете исправить только вы, например, когда ваш коллега сбрасывает производственные столы ;-). Это нормально, если люди временно заблокированы, они могут просто продолжить выполнение своей следующей задачи, пока вы не сможете им помочь.
Используйте автоматизацию, чтобы освободить место для важных задач
4. Автоматизация с помощью Makefile
Повышение производительности вашей команды так же важно, как и ваше собственное. Автоматизация повторяющихся (сложных) задач освобождает много времени для вас и ваших коллег.
Это можно сделать с помощью Makefiles или Taskfiles в зависимости от ваших предпочтений. Makefile запускает команды bash для автоматизации различных задач.
Одна из замечательных особенностей заключается в том, что даже юниоры могут использовать их, поскольку они автоматизированы с помощью команд, и они могут постепенно изучать, что происходит под водой.
Пример из моей работы; У нас есть docker-compose.yaml, который используется в нашем конвейере CI/CD, который строится на образе докера, хранящемся внутри переменной среды.
Теперь, чтобы запустить эти тесты с docker-compose.yaml, довольно сложно постоянно запускать несколько команд…
- Установка имени образа докера на основе имени нашей ветки
- Создание образа докера
- Запуск тестов в docker-compose, чтобы не отставать от конвейера CI/CD.
# Use the current branch name as test_image_name (lowercase)
# Docker tags are required to be lowercased
export TEST_IMAGE_NAME := $(shell git branch --show-current | sed 's/^feature\///' | tr '[:upper:]' '[:lower:]')
build:
docker build --tag ${TEST_IMAGE_NAME} .
test: build
docker-compose -f docker-compose-testing.yml run app /code/bash/run_tests.sh
Приведенный выше Makefile делает все за нас, и просто запустив make test, он перестроит образ с именем нашей ветки, чтобы мы всегда могли вернуться к правильному при замене веток, а затем запустить docker-compose, который использует тегированный образ docker.
Это мгновенно дало возможность всей команде запускать тесты локально, даже людям, менее знакомым с docker и bash.
Другой Makefile, который я создал в предыдущей компании, должен был помочь новичкам, которые только начали работать с облачными виртуальными машинами, настроить правильную среду Python.
ACTIVATE_VENV = . venv/bin/active
PYTHONPATH = PYTHONPATH=$$PWD/src
# Build a virtual environment and install all the required packages
build:
(python3 -m venv venv; \
${ACTIVATE_ENV}; \
pip install -r requirements.txt --upgrade pip; \
pip install pytest pytest-cov; \
)
# Activate virtual env and run the uvicorn webserver to launch FastAPI
run:
(${ACTIVATE_VENV}; \
${PYTHONPATH} uvicorn main:app --reload --port 8000; \
)
Всякий раз, когда они находились в новом репозитории, они могли запускать make build, и он устанавливал все зависимости, а если они хотели протестировать API, они могли запускать make run, и он запускал виртуальную среду перед запуском веб-сервера, который использует FastAPI.
Таким образом, им не нужно было сразу знать, как и почему мы используем виртуальные среды, и они могли протестировать свои конечные точки с помощью предоставленной документации FastAPI.
Имейте в виду, что вы должны запускать все команды внутри (), только тогда они будут вызываться из той же оболочки, иначе для каждой команды будет использоваться новая оболочка.
5. CI/CD: обеспечение качества
Возвращаясь к производительности команды, требования к решениям для обработки данных часто меняются, и эти изменения должны снова попасть в производство.
Дай бог, чтобы ваша команда использовала правильно синхронизированную среду разработки/постановки/производства, но если нет, то, скорее всего, самый старший человек занимается (повторным) развертыванием кода.
Чтобы предотвратить возникновение каких-либо серьезных проблем, мы используем конвейеры CI/CD для тестирования и развертывания кода для нас.
Таким образом, мы можем убедиться, что любые будущие изменения, которые нарушают код, должным образом фиксируются в рамках проверки кода и, если все выглядит хорошо, автоматически развертываются в соответствующей среде. Это экономит вам и вашим коллегам огромное количество времени, поскольку вам не нужно тестировать и развертывать вручную.
Это также высвобождает время самого старшего сотрудника для других дел, например, для обучения других тому, как правильно проводить проверку кода, создавать новые конвейеры данных или добавлять новые инструменты в архитектуру данных.
Наличие конвейеров CI/CD для ваших наиболее важных конвейеров данных также делает их намного более надежными, поскольку вы можете просто вернуться к старой версии в случае каких-либо незамеченных критических изменений.
Заключение
Возможность сократить количество времени, затрачиваемого на выполнение повторяющихся задач, или возможность пропускать встречи, которые просто не нужны, дает вам гораздо больше часов в неделю для создания высококачественных конвейеров данных и занятий тем, что вы любите больше всего, предоставляя данные. проекты оживают.
Поэтому обязательно выполните следующие действия:
- Дважды проверьте, действительно ли вам необходимо присутствовать на собрании
- Наслаждайтесь временем работы с тихим уведомлением
- Планируйте фокус-блоки для оптимальных моментов «в зоне»
- Автоматизируйте повторяющиеся (сложные) задачи, чтобы каждый в команде мог выполнять их, даже не подозревая, насколько это приятно для медленно адаптирующихся младших сотрудников.
- Не развертывайте вручную, вместо этого используйте конвейеры CI/CD.
