Перевод статьи «Surviving Your First Junior Developer Job [Guide]».
Получить свою первую работу это уже большое достижение. Вам пришлось тяжело потрудиться, чтобы приобрести все свои навыки и иметь возможность с их помощью зарабатывать себе на хлеб. А теперь вам нужно показать себя на новом месте.
Вы, конечно, полны воодушевления. Так и должно быть. Но также нормально и немного нервничать по этому поводу. Моя первая рабочая неделя на позиции разработчика была довольно лихорадочной. В мой первый рабочий день мне дали SQL-запрос на 200 строк, чтобы с ним разобраться… как вспомню, так вздрогну. В общем, вокруг будет много того, что вы не до конца понимаете или вообще не знаете, но это необходимый этап вашей карьеры.
В этой статье я дам несколько советов, которые должны помочь вам как можно более гладко войти в профессию и быстрее начать приносить пользу команде.
На самом деле разберитесь с Git и семантическим версионированием
Git это самый популярный инструмент для управления исходным кодом. Если вы закончили университет или прошли какие-то курсы, вы, скорее всего, знаете, что такое Git.
А теперь вам нужно научиться с ним работать.
Когда вы начнете работать в команде, вас познакомят с такими концептуальными стратегиями как:
- пул-реквесты (или PR, как их называют на GitHub),
- мердж-реквесты (и именно их называют PR на GitLab),
- merging (слияние),
- rebasing,
- squashing commits и
- semver (semantic versioning, семантическое версионирование).
В свою первую неделю я еще не до конца понимал, как пользоваться Git, и без конца потел, переживая, что могу ненароком уничтожить всю компанию.
Исходя из своего опыта, могу сказать, что многие команды любят использовать Git Flow для менеджмента разработки кода, версионирования и выпуска сборок в производство.
Начинающие разработчики, как я заметил, чаще всего задают следующие вопросы:
- в чем разница между merging и rebasing?
- когда делать rebase?
- как работают номера версий?
Постарайтесь хорошенько разобраться с этими терминами, и вы будете куда более готовы к командной работе и выпуску функционала.
Приходите на стендапы подготовленным
Если ваша команда практикует agile, вы должны быть готовы рассказывать на стендапе о том,
- чего вам удалось достигнуть вчера,
- над чем вы работаете сегодня,
- что блокирует вашу работу.
Все это может отличаться в зависимости от компании. Порой у вас могут ничего такого и не спросить. Но я считаю, что вам как разработчику в любом случае полезно заранее продумывать, над чем вы собираетесь работать на следующий день. Случается, человек входит в режим, при котором все время разбирается с проблемами по мере их поступления, а это ведет к выгоранию и потере фокуса.
Старайтесь планировать свой день заранее и приходить на стендапы подготовленным. Уделите три минуты перед работой или перед отходом ко сну, чтобы разложить по полочкам, что вам удалось сделать, чем еще предстоит заняться и что мешает вам решить вашу задачу.
Придя на стендап во всеоружии, вы не только произведете хорошее впечатление на вашего тимлида, но и вообще покажете себя более профессиональным и надежным человеком, даже если вы застряли и так и не смогли выполнить намеченное на сегодня.
Научитесь просить о помощи
Для начинающего разработчика невероятно важно знать, как и когда просить о помощи. Вы можете потратить 5 часов на попытки разобраться в чем-нибудь, а у более опытного разработчика уйдет 5 минут (или даже секунд) на то, чтобы вам помочь.
Просить о помощи, когда вы в ней нуждаетесь, это в ваших собственных интересах (да и в интересах компании тоже).
Но каждый раз немедленно бросаться за помощью, даже не попытавшись вначале решить задачу самостоятельно, это тоже не лучшая идея.
Поэтому, прежде чем попросить кого-то вам помочь, попытайтесь разобраться с проблемой самостоятельно, а если не удалось, – поищите ответ в Google (вставляйте в строку поиска нужное место из логов или сообщение об ошибке).
Если это ни к чему не привело, пора обращаться за помощью. И это тоже нужно делать соответствующим образом.
Личное обращение с просьбой помочь
Обратите внимание на язык тела человека, к которому хотите обратиться. Если вам кажется, что он раздражен, пребывает в состоянии стресса или вошел в «зону», может быть, лучше сначала «пингануть» его и спросить, можно ли подойти к нему с вопросом.
Имейте в виду, что люди могут применять на практике трюк Джорджа Костанцы (притворяться занятыми).
Просьба о помощи в мессенджере
Если вы подумываете попросить другого разработчика о помощи, отправив ему сообщение в мессенджере, есть пара способов повысить вероятность положительного и скорого ответа.
Вот плохой пример обращения за помощью: «Эй, можешь мне помочь? Я не могу установить node.js на своем компьютере, он не работает».
Так делать не надо. Это сообщение можно улучшить следующим образом:
- Для начала представьтесь, как если бы вы никогда прежде с этим человеком не говорили.
- Обязательно упомяните в сообщении, что вы пытались разобраться самостоятельно. Расскажите, с чем точно проблем нет, чтобы человек мог быстрее сообразить, где они могут быть.
Вот лучший вариант обращения:
«Привет, Джон, это Халиль, ваш новый разработчик. Приятно познакомиться. Я слышал, ты можешь помочь мне с проблемой, с которой я столкнулся. В общем, я пытаюсь установить на свой компьютер Node.js. Я попробовал эту ссылку (вставлена ссылка) и следовал инструкциям, но когда я запустил эту команду (вставлена команда), я получил сообщение об ошибке (вставлен текст сообщения). Я пользуюсь одним из новых макбуков. Есть идеи, в чем может быть загвоздка?».
Это сообщение звучит гораздо лучше. Таким образом вы сообщаете человеку достаточно информации о том, что вы уже пробовали сделать, и в результате он может быстрее понять, в чем проблема. Когда вы такой информации не даете, ему приходится задавать вам кучу наводящих вопросов. Время, уходящее на все эти вопросы, ваш коллега мог бы потратить на свои дела, которыми он и занимался, пока вы его не перебили.
В общем, старайтесь помочь другому человеку сэкономить как можно больше времени. Для этого предоставляйте ему как можно больше информации о проблеме, с которой вы столкнулись.
Как себя вести, когда вам помогли
Забудьте о своем эго.
Когда кто-то потратил время, чтобы вам помочь, не следует изображать, что вы все это время знали, как справиться с задачей.
Когда проблема решена, не говорите: «Ага, именно это я и хотел сделать».
Просто поблагодарите вашего коллегу.
Старайтесь не отпускать обвиняющих комментариев ни в чей адрес. Не говорите: «Бэкенд-команда все перепутала, вот почему оно не работало».
Вместо этого можно сказать: «Я думаю, это может быть связано с недавними изменениями в бэкенде».
Если вы обратились с вопросом, а позже нашли решение самостоятельно, обязательно сообщите об этом человеку, к которому обращались. Возможно, он все еще обдумывает способы вам помочь, а поскольку помощь уже не нужна, сможет заняться следующей задачей.
Обязательно тестируйте свой код вручную
Я никогда не забуду случая на своей первой работе, когда я наплевал на тесты и просто решил, что код будет работать в продакшене.
Этот код попал к клиенту и сломался сразу же. Ну и разнос же мне устроили тогда!
Не повторяйте моих ошибок: обязательно проверяйте, работает ли ваш код! Тестируйте happy paths (типовые пути выполнения вашего кода) и, в особенности, non-happy paths.
Старайтесь сломать свой код. Если я чему-то и научился относительно отправки кода в продакшен, это тому, что если в вашем коде есть баги, пользователи в конечном итоге их обязательно найдут.
Даже если у вас есть команда QA, ваша цель – сделать так, чтобы QA ничего не нашли.
Учитесь писать тестируемый код и тесты для него
Написание тестируемого кода обычно выходит за рамки программы в вузе, но этому учишься, применяя принципы SOLID.
Также стоит спросить ведущих разработчиков, как написать тесты для вашего кода. Они оценят, что вы об этом спросили. Возможно, даже сядут с вами и покажут пару приемов. Если они не смогут или если вы вообще видите, что кодовая база не богата тестами, следующее, что вы должны сделать, это протестировать свой код вручную.
Постоянно учитесь
Если вы фронтенд-разработчик, изучайте бэкенд и devops. Если вы бэкенд-разработчик, исследуйте HCI (взаимодействие человека и компьютера) и UX.
Хорошенько освойте инструмент, которым пользуетесь ежедневно.
В нашей сфере деятельности успех в конечном счете зависит от вашего стремления учиться и расти.
Мы рассмотрели несколько лучших способов, как независимо от вашей специализации сделать вашу первую работу успешной. Следуя этим советам, вы произведете благоприятное впечатление на свое начальство и быстро разберетесь, как стать продуктивным членом команды.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]