Ура! Ваше резюме рассмотрели, вам сделали оффер и вы приземляетесь на позицию джуниор-разработчика. Не время расслабляться, начинается новый этап вашего развития. В этом посте мы дадим ряд советов, как провести это время наилучшим образом, если вы начали путь в большой компании (хотя и для стартапов кое-что вполне справедливо).
Начинается всё обычно со множества встреч. Вас нужно представить команде, вам нужно понять, кто и за что в ней отвечает. Наверняка вы будете многого не понимать на этих встречах. Коллеги будут сыпать неизвестными аббревиатурами и странными, на первый взгляд, кусками кода. Это нормально, ведь вы, скорее всего, подключились в самый разгар проекта.
Большие встречи, где вы будто бы ничего не понимаете, со временем станут всё более полезными, по мере того как вы будете погружаться в контекст. Не торопитесь задавать самые базовые вопросы вроде «а что это?» или «о чем вообще речь?» — они требуют слишком обширного ответа и будут только раздражать остальных. Поваритесь некоторое время в общем котле, чтобы вопросы стали более глубокими, демонстрировали вашу вовлеченность. Например, «мы сейчас говорим о той фиче, что была включена в предпоследний релиз?». Или даже так: «Это функция, которую мы обсуждали в четверг на прошлой неделе? Я почитал документацию и не понял вот этот момент, можете объяснить подробнее?». Представьте, что ваш вопрос — это звено в цепи уточняющих вопросов, и выберите максимально точную из доступных вам формулировок. Это сэкономит всем время.
Возможно, что во время встречи более опытный коллега — например, ваш тимлид — прервется и обратится лично к вам: «Дима, ты будешь работать с этим, обрати внимание». Стоит воспользоваться шансом: это самый подходящий момент, чтобы задать накопившиеся вопросы.
Чтобы ничего не забыть, делайте заранее заметки по ходу других встреч. Необязательно записывать все подробности — так вы рискуете отвлечься и упустить развитие обсуждения. Достаточно пары слов, по которым вы сможете после встречи восстановить ответ и закрепить его уже подробней. Постепенно ваши заметки будут терять актуальность; перед встречей пробегитесь по списку того, что планируете спросить. Возможно, что-то вы уже узнали. Что-то вы можете проработать самостоятельно. Или это вообще не относится к предмету обсуждения. Это ваши собственные заметки, так что делайте с ними что хотите. Хоть код пишите — если он донесет до вас нужные смыслы, цель выполнена; никто не будет ревьюить личный блокнот.
Следующий вопрос — ваш рабочий сетап. На удаленке вы обычно получаете рабочий ноутбук, в офисе может быть и стационарный компьютер, иногда выдают еще и смартфон (например, мобильным разработчикам). В маленьких компаниях иногда просят поставить нужный софт на личный компьютер. Не очень приятно, если сюда входит софт для мониторинга вашей активности; возможно, стоит договориться о том, чтобы не ставить его, если без него вполне можно решать рабочие задачи. Иногда можно договориться с компанией о частичном возмещении расходов на компьютер, если вы будете его использовать и для личных, и для рабочих задач.
После онбордингов и подписания NDA вас подключают к корпоративным репозиториям. Их может быть много, они могут быть разрознены, иметь разную актуальность. Если ранее вы не работали с большими проектами, то такой масштаб может напугать. Хорошо, если вам выделят опытного коллегу, который сможет сориентировать вас во всем многообразии репозиториев и покажет, что и как реально работает. Если нет — придется полагаться на документацию. В ней обычно изложено, как запускать приложения, какие зависимости загружать и множество других важных вещей.
Отдельно в документации стоит обратить внимание на то, как разграничиваются зоны ответственности. Например, как разработчик, вы вряд ли будете уполномочены изменять информацию о продукте на сайте по собственному усмотрению — эта функция закреплена за маркетингом.
Как новый сотрудник, вы имеете одно важное преимущество над старожилами — это свежий взгляд на вещи. Если вы на своем опыте убедились, что онбординг, документацию и другие этапы взаимодействия на старте можно улучшить — сообщите об этом своим кураторам из команды или HR. Это докажет вашу заинтересованность в работе и улучшит жизнь тем, кто придет после вас.
Наконец, после всех приготовлений, вы получаете первые задачи и дедлайны. Вероятно, первые задачи будут сравнительно простыми — сейчас коллегам нужно убедиться, что вы нормально управляетесь с кодингом и вливаетесь в рабочий процесс. Но не стоит расслабляться: уже на этом этапе могут быть подводные камни. У вас точно есть нужные права? Исправили ли вы все места, которые нужно, связанные с вашей правкой? Если вы добавляете какой-то текст, то нужно ли его переводить на другие языки для соседних веток? Правильно ли вы оформляете пул-реквест?
Первые маленькие задачи направлены именно на то, чтобы вы отточили процессы. Важнейший совет здесь — хоть и банальный — RTFM, «read the f*cking manual». Обратите внимание, что и как настраивается именно для вашей системы. Если что-то где-то упущено — оставьте комментарий, чтобы другим новичкам было проще.
Если вы бойко начали первые недели, то спустя некоторое время так или иначе осознаете: оставаться сверхпродуктивным в течение всего дня не получится. Но важно шевелиться в этом направлении и не стесняться задавать вопросы даже по тем вещам, которые будто бы и спрашивать уже неудобно — если вы, конечно, не можете найти их в документации или Сети. Но прежде чем спросить, как что-то делать в принципе, попробуйте это сами и дополните свой вопрос историей о самостоятельной попытке. С большой долей вероятности ответить на вопрос в такой формулировке можно будет быстрее.
Будьте осторожны и со своими обещаниями. Если вы заявляете о себе как о «короле реакта», то вас могут сразу бросить на сложные задачи, руководствуясь принципом sink or swim — «спасение утопающих — дело рук самих утопающих». И если что-то пойдет не так, придется признать, что вы не справитесь с задачей сразу так же быстро, как ваши коллеги, которые уже давно в проекте. Но всё же это гораздо лучше, чем умалчивать о проблемах до самого дедлайна. Так что не стоит практиковать то, что в английском называется overpromising. Таким образом вы даже можете испортить отношения с коллегами, если ваши обещания затронут их зоны ответственности. Перетягивание одеяла на себя может разрушить баланс задач и привести всю команду к плачевному результату. Поэтому не спешите возлагать на себя большую командную роль, пока не поймете, что и как здесь работает, какая у команды динамика.
Начните осваивать лучше практики своей команды. Например, не выкладывайте на GitHub переменные среды, связанные с закрытыми проектами. Узнайте, что и когда нужно добавлять в gitignore. Делайте мерджи так, чтобы не удалить ненароком историю. Администраторы, конечно, ставят в репозитории защиту от подобных действий, но лучше не рисковать, если вы не уверены в благополучном исходе: вдруг все держится лишь на вере, что команда слишком опытна, чтобы такое допустить.
Если позволяет время, попробуйте в локальном режиме что-нибудь поломать. Например, если работаете над каким-нибудь уже стабильным API, попробуйте понять, что может оборвать соединение. Это поможет вам изучить код, позволит взглянуть на него с другого ракурса. Разберитесь в ошибках, которые вызываются теми или иными вашими действиями. Возможно, это станет исходной точкой для улучшения продукта. Будьте инициативны.
Что не стоит делать в первые недели? Выше мы уже упоминали про зоны ответственности: не нужно нарушать их границы. Если команда работает хорошо, то ее расширение увеличит общую производительность. Если же после вашего прихода стало хуже, то стоит задуматься, что и как вы делаете: возможно, вы занимаетесь не своим делом. Не берите задачи, назначенные другим людям, даже если время позволяет. Обсудите это с тимлидом. Или напишите напрямую коллегам, которым назначена задача, если ваш опыт может помочь им выполнить ее быстрее. Так вы еще и укрепите отношения в коллективе.
Старайтесь не задавать один и тот же вопрос несколько раз. Получив первый и достаточный ответ, запишите себе заметку, сохраните сообщение из чата, сделайте закладку в документации — в общем, все необходимое, чтобы не отвлекать коллег несколько раз одной и той же проблемой. Если спросить все-таки приходится — например, вы не уверены, что в двух случаях работает одна и та же схема — задайте вопрос со ссылкой на предыдущий ответ: «Мне делать это так же, как и вчера?». Это сэкономит всем время. Это же справедливо с ситуацией, когда вы видите, что ваш коллега вдруг начинает решать какой-то кейс не так, как рассказывал вам. Возможно, во второй раз он сделал это по-быстрому, чтобы переписать самостоятельно позже, так что обратитесь к нему, прежде чем менять его код самостоятельно.
Не притворяйтесь, что знаете то, чего на самом деле не знаете. В первое время вам могут предложить задачи, которые пока что вам не по зубам — например, потому что вы не освоили нужный инструмент. Не надо строить из себя героя: если вы, например, случайно сотрете базу данных, в которой заявляли себя как профи, возникнут вопросы. То же самое касается и резюме. Если у вас был когда-то небольшой опыт с WordPress, не нужно заносить в навыки веб-дизайн. Не думайте, что во всем поможет Google: для некоторых вещей как минимум необходимо пройти курсы и иметь сертификации. Сформулируйте свой реальный набор скилов на берегу — и вы избежите немало проблем. Если речь идет о новом инструменте, и вы чувствуете в себе силы в нем разобраться, стоит заранее обсудить, чтобы заложить на это дополнительное время (если планирование позволяет). Возможно, там действительно не потребуется глубоких знаний, и вы вполне успеете сделать всё самостоятельно.
Не стремитесь с порога менять то, что уже хорошо работает. Если вас взяли работать с Angular, а вы предпочитаете React, не стоит на каждой встрече говорить, как хорош React по сравнению с Angular. У команды наверняка были причины сделать именно такой выбор, но вы о них еще не знаете. Со временем, когда вы поймете все нюансы, можно будет выносить настолько глобальные предложения. Но не на старте работы. К тому же вы вряд ли укрепите свои позиции в команде, стремясь отказаться от того, на что ваши коллеги потратили много труда. И уж тем более не стоит выносить такие предложения на встречах со стейкхолдерами и клиентами: это может ухудшить их мнение обо всей команде.
Первые недели на позиции разработчика будут насыщены событиями и вызовами, как с технической, так и с социальной стороны. В английском языке есть слово grace, которое, в зависимости от контекста, можно перевести и как «легкость, плавность» и как «благие намерения». Сохраните это самое grace даже «в огне».
