Как вырасти из джуниор разработчика

Это перевод статьи Как вырасти из джуниора

Прошло два года после такого как я закончила Lighthouse Labs как junior software developer. 8 недель интенсива, в течении которого нам рассказывали что такое программирование, обучали языкам Ruby и JavaScript, познакомили с 3 или 4 фреймворками и подтолкнули к разработке собственного проекта.

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

Я приняла участие в Poliglot conference unconference Там было проведено по меньшей мере две сессии, посвященные тому как вырасти из джуниора. Поэтому я хочу поделиться с вами теми вещами, которые мне помогли.

• ВЫДЕЛИТЬ ОПРЕДЕЛЕННОЕ ВРЕМЯ, ДЛЯ ПРОВЕРКИ.

Как новому сотруднику мне не возбранялось задавать вопросы. Однако через месяц или два я почувствовала, что пора бы уже перестать их задавать, пора самой знать. Да, я думала, что я должна уже сама уметь находить решения. Я не хотела больше быть обузой. Я не хотела выглядеть глупой, невежественной или прямо сказать дурочкой. В конце концов, сколько еще можно учиться… Правильно? НЕТ.

Учиться можно всегда и ровно столько, сколько нужно, чтобы научиться. И некоторые вопросы намного сложнее, чем другие.

В конце концов, я попала в замкнутый круг. Я верю, что смогу решить задачу. Она занимает все мое время. У меня стресс. Старшие разработчики, с другой стороны не хотели контролировать. Они знали, что я самоучка. Шли недели без какого-либо малейшего прогресса.

Решение: Еженедельно (первоначально дважды в неделю) в течении 30 минут проверять проект, чтобы обсудить направление развития и возможные препятствия.

В результате, вместо того, чтобы бегать с вопросами каждые 30 минут, у меня есть время, чтобы получше разобраться с задачей и записать вопросы. 30 минут обсуждения задачи со старшими разработчиками - бесценны. Я получала ответы на вопросы, узнавала больше о компании и общалась с наставником. И в конце встречи у каждого было чувство, что мы не стоим на месте.

• РЕЦЕНЗИРОВАНИЕ КОДА (CODE REVIEWS).

Сделать что-то новое, какой-нибудь функционал, починить баг и запустить код на моем локальном компьютере - это одно. А вот передать его в продакшн это совсем другое. Многие компании используют код ревью, как инструмент передачи знаний. Я всегда буду благодарна одному из моих первых наставников, который вместе со мной разобрал каждый кусочек кода, который я отправляла в качестве pull request (запрос на включение внесенных изменений).

• Расскажите о проблеме - все должны знать суть.
• Запустите код - покажите его работу.
• Пройдите по решению используя не профессиональные слова - покажите, что вы понимаете суть решения.
• Пройдите по коду - покажите каждый этап в коде.

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

Принципы, изложенные в “Чистом Коде”, могут быть выработаны и усвоены с помощью этой практики. Если в команде есть еще младшие разработчики, я предлагаю вам привлечь их к этому процессу.

• РАЗБОРЫ ПОДХОДОВ К РАЗРАБОТКЕ (СПОСОБОВ РЕШЕНИЯ ЗАДАЧ).

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

Решение: обсудить возможные решения и подходы до написания кода. На доске. Какие части кода можно адаптировать, что я могу создать и использовать в будущем.

Что действительно сработало для меня, это когда мне приходилось решать задачи в условиях недостатка времени, вне зависимости от того было оно принято или нет. Это помогло мне понять мои ошибки в подходе к разработке и то, в каком направлении нужно развиваться.

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

• БОЛЬШЕ РАБОТАТЬ С КОДОМ.

Первое, что нужно сделать до того как начать писать код, это посмотреть, как такая задача решалась раньше, и как это было реализовано. Таким образом, работа с кодом кажется естественным предложением.

Однако больше всего мне помогла работа над сторонними проектами. Переписывание кода, написанного кем-то и понимание, как он разрабатывался шаг за шагом.