Привет сообщество разработчиков,
Прошло более 2 лет с тех пор, как я в последний раз писал на Dev, поэтому сначала я представлюсь и расскажу о себе.
В ноябре 2019 года я начал свое путешествие в качестве #codenewbie в Twitter и завершил свой первый #100daysofcode challenge к 6 марта 2020 года. 8 мая 2020 года я устроился на свою первую работу в качестве дизайнера программного обеспечения и со временем постепенно перешел на роль front-end разработчика.
Если вы новичок, то, как бы ни было волнительно получить работу, не менее страшно представить, каково это — работать младшим разработчиком, чего ожидать, какова культура работы и т. д. Конечно, опыт работы в разных компаниях может быть разным, но здесь я хотел бы поделиться 5 самыми важными вопросами, которые меня интересовали до поступления на работу, и тем, как все прошло на самом деле.
На что будет похож мой первый рабочий день?
В первый же день работы я начала свой день с участия в ежедневном собрании команды, где я представилась всем, рассказав интересный факт о себе. Затем остальные поприветствовали меня в команде, представились, поделились интересным фактом и сообщили руководителю команды, над чем они работали, поскольку это основная цель ежедневного собрания команды.
После ежедневного совещания мне дали ссылку на Github, направляющую к документации «Как начать работу». Меня также попросили проверить, есть ли в документации области для улучшения, такие как орфографические ошибки, неработающие ссылки и т. д. Поэтому первый же запрос на исправление (PR), который я создал для кодовой базы, был связан с незначительными улучшениями, связанными с пунктуацией и неработающими ссылками в документации. И снова ничего страшного!
Интересно, какие инструменты я буду использовать?
Обычно один из разработчиков отвечает за объяснение инструментов, используемых в компании, а в моем случае у меня была встреча с ведущим дизайнером продукта, который подробно объяснил, что такое каждый инструмент и как он используется. Ниже перечислены несколько инструментов, которые я использую ежедневно:
- Инструмент управления задачами — Target Process —> Azure DevOps
- IDE — [WebStorm] Да, не VS Code. Сюрприз, сюрприз!
- Инструмент для проектирования — Sketch —> Figma
- Инструмент для создания скриншотов — Monosnap
- Конечное тестирование — Cypress
- Общая коммуникация — Slack
- Формальная коммуникация — Outlook
После установки некоторых из вышеперечисленных инструментов я потратил некоторое время на изучение каждого из них, что было медленным прогрессом, потому что привыкание к новым инструментам требует времени и усилий. Но самое приятное, что все в команде знают об этом, поэтому от вас не ожидают, что вы будете знать, как работают инструменты с первого дня, особенно переход от VS Code к WebStorm был для меня трудным.
Каким будет мое ежедневное расписание?
Будучи младшим разработчиком, у меня не было большого количества ежедневных встреч. Самое большое количество встреч за один день было 4, но это случалось очень редко. Вот как выглядело мое расписание:
- Общекомандное собрание (3 дня в неделю) — на нем выступают только лидеры команд и сообщают высшему руководству, над чем мы работали.
- Командный стендап (3 дня в неделю) — где мы объясняем лидерам команд, над чем мы работали.
- Планирование спринта (раз в 2 недели) — сообщаем Скрам-мастеру, над какими историями мы будем работать в ближайшие 2 недели.
- Ретроспектива (раз в 2 недели) — взлеты и падения спринта, комментарии, улучшения, благодарности и т.д.
С кем я буду работать?
Это сильно менялось в зависимости от множества текущих факторов, происходящих в компании, но вот общая идея:
В организации было 4 команды:
- Интеграция
- Функции
- По вызову
- Производительность и безопасность
В каждой команде, за исключением команды производительности и безопасности, было не менее 3/4 разработчиков, 1 руководитель команды, 1 дизайнер, 1/2 QA-инженера, 1 scrum-мастер и 1 владелец продукта. Важно отметить, что даже если в начале работы вы будете приписаны к определенной команде, вы всегда должны сохранять открытость к переходу от команды к команде, адаптироваться к их культуре работы и двигаться вперед быстрыми темпами, если это необходимо.
Что, если мне понадобится помощь?
Я думаю, что этот вопрос не дает нам спать по ночам, потому что мы редко чувствуем себя уверенно при приеме на работу в качестве младшего разработчика, потому что мы создаем воображаемую ситуацию, в которой мы застряли в проблеме на 2 недели без какого-либо решения. Вот что я сделал, чтобы преодолеть эту проблему после вступления в компанию:
- Я очень хорошо использовал канал Slack под названием dev-help, где каждый может поделиться своими проблемами и вопросами, и всегда найдутся разработчики, которые просто придут на помощь.
- Еще один прием, который я использовал для получения помощи, — это проверка авторства кода (расширение GitLens) и отправка им сообщений напрямую, чтобы узнать, могут ли они помочь с проблемой, с которой я столкнулся. Это не всегда срабатывает, но иногда стоит попробовать.
- И последний способ — парное программирование. Почти все старшие разработчики будут рады провести с вами сеанс парного программирования, где они либо продемонстрируют это для вас, либо попросят вас сделать это самостоятельно с их помощью. Парное программирование всегда помогает задать вопросы опытным разработчикам, обсудить преимущества/недостатки определенных методов и узнать новые способы решения проблем, что просто замечательно.
Если вы новичок в программировании и в настоящее время с нетерпением ждете захватывающих возможностей в качестве младшего разработчика в будущем, я надеюсь, что вы нашли вышеприведенные вопросы полезными и информативными. Спасибо за прочтение