Адаптированный перевод статьи «How I’m working to overcome my struggles as a junior developer».
Я думаю, «борьба» это еще одно слово для определения программирования. А если вы только начинаете работать в этой сфере, то это борьба в квадрате. Нужно учиться писать код, находить правильные ресурсы, создавать портфолио, искать стажировку или работу, куда согласны взять джуниора, а затем последует работа над первым в жизни реальным проектом. И все это непросто.
Положительная сторона этой ситуации в том, что вы учитесь и выходите из своей зоны комфорта, чтобы испытывать новые вещи и реализовывать новые идеи. В конечном итоге вы станете значительно улучшенной версией себя прежнего.
В тех-индустрии много историй успеха, которые рассказывают нам о долгом пути обучения и борьбы с препятствиями. Снаружи все кажется захватывающим. Особенно так кажется джуниорам. Для них сеньоры и наставники это просто лучшие из людей, обладающие великолепной логикой и повергающие в ступор своими потрясающими способами написания кода.
Но когда мы приближаемся к этому миру и начинаем видеть все яснее, мы понимаем, что с трудностями сталкиваются абсолютно все. И баги с ошибками тоже бывают у всех. С приходом опыта мы начинаем осознавать, что разница в между нами и сеньорами в том, что они сталкиваются с более крупными и комплексными проблемами.
Я поделюсь своими любимыми твитами от двух людей, которые многому меня научили. Эти твиты всегда вызывают у меня улыбку и повышают мою мотивацию, а поскольку я не одна такая, думаю, они и еще кому-нибудь помогут.
Мне посчастливилось увидеть этот твит, когда я продиралась сквозь дебри JavaScript, пытаясь уложить в голове все изученное.
Когда я училась, я постоянно пребывала в поиске подтверждений того, что когда-нибудь я смогу стать хорошим программистом. Я хотела приобрести уверенность, что программирование это «моё», что я сумею писать хорошую логику и код не хуже, чем другие.
Когда мне случалось застрять над какими-то небольшими проблемами, когда мне не удавалось быстро что-то наладить, я чувствовала себя подавленной и разочарованной. И когда какие-нибудь знаменитые программисты демонстрировали своим подписчикам, что они тоже не совершенны, это очень укрепляло мою веру в себя.
Второй мой любимый твит был сделан одним из лучших разработчиков, автором серии «You Don’t know JS», Кайлом Симпсоном.
«20+ лет опыта разработки, 8 книг (продано больше 100 тыс. экземпляров), больше 300 тысяч часов просмотров моих видео, 4 тысячи часов, проведенных за обучением других людей лично…
И знаете, что? Мне по-прежнему трудно заставить свой код работать. И мой код по-прежнему озадачивает меня на следующий день.
В плане этих проблем вы не одиноки».
Не знаю, как вы, а я после прочтения этого твита чувствую себя гораздо спокойнее. На некоторое время, по крайней мере.
В своих предыдущих статьях я рассказывала о сложностях поиска работы, а теперь хочу рассказать о том, как выжить на этой самой работе.
Все дело в понимании кода
Чувства, которые я испытывала во время поисков стажировки, очень отличаются от чувств, которые я испытала, приступив к работе. Теперь страх не получить возможность проявить себя уступил место страху не справиться и потерять предоставленную возможность.
Было очень тяжело столкнуться с первой проблемой, когда мне нужно было настроить инструментарий graphJS в соответствии с требованиями. Поначалу я думала, что легко с этим справлюсь, но пришлось попотеть. Два дня я не могла найти решение.
Я задала пару вопросов своим наставникам и изо всех сил старалась справиться. Но порой мне казалось, что я так и не сумею сделать то, что нужно, и это меня угнетало.
Мои наставники не давили на меня. Вместо этого они внушали мне уверенность и идею, что сталкиваться с трудностями при изучении новой и обширной кодовой базы это нормально. Порой нужно время, чтобы разобраться в каких-то вещах и в чужом коде, так что не нужно быть слишком строгим к себе.
Мой наставник с пониманием отнесся к тому, что у меня возникли трудности с пониманием кодовой базы с сотнями функций и файлов. Он рассказал мне о методе утенка и сказал объяснять все уточке. Это должно было помочь мне лучше понять код и что в нем происходит.
«Застрять с какой-то проблемой это нормально, это случается со всеми нами. По мере накопления опыта такое происходит все реже, но все равно случается», – Армен Замбрано (наставник автора статьи, – прим. перев.).
Итак, вот что я для себя открыла
Знание, с чего начать, это уже половина дела
Чаще всего вы знаете решение и, возможно, логику, и как все это реализовать, но вы не знаете, с чего начать! Когда у вас множество файлов и функций, это сбивает с толку и становится тяжело определить, где нужно расположить свое решение, чтобы все хорошо работало.
Мой наставник Дастин Митчелл посоветовал мне для понимания кода и функций пользоваться комментариями в дополнение к моей собственной технике console.log(всё-что-попадается-на-пути).
Поначалу дело пошло более гладко, но все равно было сложно. Я снова застряла на относительно сложной проблеме. Чтобы в ней разобраться, мне потребовалось несколько дней.
К счастью, наставники и люди в open source с пониманием относились к проблемам джуниоров и не корили нас за это. Вообще, в мире технологий должно быть больше таких людей, готовых помогать и наставлять других.
Конфликты слияния это боль
Если вы начинающий разработчик и не имели дела с open source, я хочу предупредить вас о конфликтах слияния. Это просто ужасно, когда вы не умеете их разрешать. Вы проводите часы за поисками решения проблемы и в конечном итоге теряете свой код в попытках исправить конфликт слияния.
У меня были такие конфликты, а также случаи, когда я спутала несколько git-коммитов. Это было досадно и страшно. Но если бы со мной такого не случилось, я бы не узнала несколько новых концепций относительно слияний, коммитов и разрешения конфликтов в git.
Тяжело распознавать собственный код
Это касается практически всех. И это действительно забавно, что всего через несколько дней нам не удается распознать собственный код, написанный собственными руками. После решения проблемы с багом я пыталась решить похожую проблему и для этого по ссылке вернулась к предыдущей. И… как я могла такое написать, и какого черта оно работает?!
Рабочий код может так же ставить в тупик, как и нерабочий. В большинстве случаев с рабочим даже сложнее. И порой, возвращаясь к старому коду, ты заново его продумываешь и приходишь к лучшему решению.
Так что не стоит волноваться или переживать, если не можете определить, ваш это код или чей-то еще. Возможно, вы близки к тому чтобы узнать что-то новое.
Расскажите мне, как выжить
Основываясь на своих первых неделях стажировки, я сформулировала для себя (и других) несколько советов. В основе большинства из них лежат слова моих наставников и других прекрасных людей, которых я повстречала в Mozilla. Я поделюсь этими советами с вами, вдруг вам тоже поможет.
Ничего личного и фокус на учебе
Тяжело не принимать близко к сердцу и не чувствовать себя обиженным, когда разработчик-сеньор или наставник тебя поправляет. Это еще тяжелее, если работаешь в open source на публичной платформе.
Но я советую вам сосредоточиться на словах более опытных людей и постараться чему-то научиться. Без скромности и стремления учиться вы не усвоите новые концепции и хорошие подходы к написанию кода. Отставьте свое эго в сторону и учитесь на чужом опыте.
Впитывайте в себя как можно больше информации и задавайте вопросы о новых вещах
Держите глаза и уши открытыми, проявляйте жажду знаний и впитывайте полученную информацию. Не бойтесь испытывать разные новые вещи, находящиеся вне вашей зоны комфорта.
Порой мы чувствуем себя уютно со своим образом мыслей и подходом к написанию кода, однако есть много хороших практик и шаблонов проектирования, о которых мы просто не знаем. Старайтесь изучить как можно больше всего. Это будет вполне возможно, если следовать предыдущему пункту.
Прежде чем задавать вопросы, выполняйте «домашнее задание»
Задавать вопросы это не плохо, особенно если вы застряли. Но будет хорошим тоном сначала попытаться разобраться самостоятельно и подготовить правильные вопросы и свой вариант решения. А потому можно попросить ревью у наставников или сеньоров.
Это поможет научиться справляться с проблемами самостоятельно. Также ваши наставники не подумают, что вы даже не старались разобраться, прежде чем обращаться за помощью. Люди в open source и на сеньорских позициях часто бывают дружелюбными и готовыми помочь, если вы подойдете к ним с правильным вопросом.
Не сравнивайте себя с другими
Прекратите сравнивать себя с окружающими. Это скажется на вашей производительности и приведет к потере уверенности в себе. Помните, каждый мастер сначала был новичком. Все проходят через эти сложности, и ваш сеньор тоже был на вашем месте когда-то. Поэтому опытные разработчики в курсе всех проблем, с которыми сталкиваются джуниоры.
Но при всем желании нельзя стать мастером за одну ночь. Есть определенный путь становления, и каждый должен его пройти. Ваше время еще наступит, а пока работайте усерднее.
Помните, что все разработчики-джуниоры в одной лодке с вами, вы не какое-то исключение. То, чему мы учились в вузе, сильно отличается от того, что нам нужно реализовывать в реальной жизни. Поэтому нам нужно еще многому научиться, чтобы стать компетентными разработчиками.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
