Перевод второй части статьи «How to Become an Outstanding Junior Developer».
В своей статье, предназначенной для разработчиков, только что устроившихся на свою первую работу, Джон Мозесмен раскрыл следующие темы:
- Чего ждать (в первые дни или недели) на работе.
- Краткосрочный и среднесрочный план.
- Установка на успех.
- Как стать замечательным начинающим разработчиком.
О том, чего компания ждет от начинающего разработчика, а также о собственных установках новичков и развитии мы поговорили в первой части статьи. Теперь давайте рассмотрим практические советы, как стать отличным разработчиком-джуниором. Таким, с которым будут рады работать все коллеги.
1. Коммуницируйте очень-очень хорошо
Придя в первый день на работу, вы можете и не иметь потрясающих знаний по части разработки, а вот потрясающие навыки коммуникации у вас вполне могут быть.
Как начинающий разработчик, вы постоянно будете обращаться к коллегам с вопросами и за помощью. Это нормально. Давайте рассмотрим, как это делать эффективно.
Когда ты продвигался-продивгался, и вдруг «уперся в стену», это очень неприятно. В такие моменты легко поддаться порыву и начать забрасывать вопросами коллегу, сидящего по соседству (или по электронной почте, или в чате).
Что-то вроде:
- «я застрял»
- «тут ошибки»
- «страница не загружается».
Теперь отступите на шаг и попробуйте представить, как это выглядит с точки зрения человека, к которому вы обращаетесь за помощью. Фраза «страница не загружается» вообще не помогает этому человеку помочь вам. Тут нет никакого контекста. Нет никакой информации о том, что происходит. Фактически, человеку придется просить вас предоставить больше сведений. Это очень неэффективно, к тому же раздражает коллегу, который пытается вам помочь.
Обращаясь за помощью, лучше пользоваться неким шаблоном. Например:
- Я работаю над <вставить-по-ситуации>
- но когда я пытаюсь <…>,
- происходит не <…>, а <…>.
- Я попробовал <…>, а еще <…> и <…>. А еще я смотрел <…> и <…>.
То есть, у вас должно получаться что-то вроде:
«Я работаю над исправлением бага со сбросом пароля пользователя, но когда пытаюсь сгенерировать ссылку на сброс пароля, токен user’а уже пуст. Я посмотрел, где установлен токен. Я вижу его в базе данных, но его нет в строке Х файла Y».
Если вы пошлете кому-нибудь подобное сообщение, человек сразу поймет:
- над чем вы работаете,
- в чем проблема,
- что вы уже испробовали,
- где корни проблемы.
Все это — ценная информация для человека, которого вы просите о помощи. Он будет очень признателен, что вы все так четко сформулировали, и особенно — что вы пытались решить проблему самостоятельно. Это покажет, что вы уважаете время других людей и не ищете, кто бы за вас все сделал.
В обращении за помощью нет ничего плохого. Но если кто-то просто решает вашу проблему, по факту он лишает вас возможности учиться и расти.
Дело в том, проблемы — нечто бесконечное. Нельзя сказать, что вот, мол, решите эти 10 проблем — и можете быть свободны до конца жизни. Будучи разработчиком, вы ежедневно решаете все новые и новые проблемы. Так что в ваших интересах получить ровно столько помощи, чтобы вы смогли выйти из тупика и дальше разобраться со всем самостоятельно.
2. Оттачивайте свое Google-фу
(Это как кунг-фу, только с Google. Мы не призываем срочно переходить на Duck-duck-go, — прим. ред.).
Эффективно искать ответы на свои вопросы — это отдельное искусство. Со временем у разработчиков вырабатывается навык «гугления». Это настоящий навык, который непременно есть у каждого опытного разработчика.
Порой вам нужно лишь «загуглить» конкретную проблему (это хорошо работает с текстами сообщений об ошибках):
Иногда поиск точной фразы из сообщения об ошибке позволяет найти подходящий результат, как показано на картинке сверху. У вас возникла проблема, и у кого-то другого тоже возникала точно такая же проблема.
Но порой поисковый запрос нужно подкорректировать, удалив информацию, специфическую для проекта:
На приведенной выше иллюстрации Google прежде не встречал функцию whos_that_pokemon_its_pikachu() в файле gotta_catchem_all.rb (ну, теперь повстречал — когда я это загуглил). Если удалить информацию, касающуюся проекта, и добавить более общую, вы получите куда лучший результат.
3. Используйте «таймер попыток»
У начинающих разработчиков часто случаются заторы в работе. Вы постоянно будете упираться в сообщения об ошибках, которые вам раньше не встречались. То, как вы будете вести себя в таких ситуациях, определит, насколько быстро вы вырастете в профессиональном смысле.
Несмотря на то, что подобные моменты очень раздражают, по сути это как раз те самые возможности для учебы и роста. Выполняя одни и те же отработанные операции снова и снова, вы не вырастете: рост происходит только тогда, когда вы встречаетесь с чем-то незнакомым.
Попав в подобную ситуацию, выделите себе какое-то время на попытки разобраться с проблемой самостоятельно. В некоторых компаниях на этапе онбординга вам сразу посоветуют так делать — скажут что-то вроде «прежде чем обращаться за помощью, 30 минут пытайся справиться сам». В других компаниях таких четких указаний не будет, но суть остается прежней: постарайтесь сделать все, что можете, для решения задачи, но если не выходит, обращайтесь за помощью.
Такой подход даст вам возможность и научиться чему-нибудь, и проявить уважение к времени коллег, которые сфокусированы на своей работе. Отвлекать кого-то, чтобы помогли справиться с тем, с чем вы и сами могли бы разобраться, — как минимум невежливо.
Так что сначала пытайтесь сами решить свою задачу, и только потом просите помочь вам!
Но тут есть один секретный прием: всегда устанавливайте себе таймер попыток.
Скажем, вы застряли. Пытайтесь справиться самостоятельно 30 минут, а потом обращайтесь к коллегам. Когда в следующий раз застрянете, снова отведите себе 30 минут на попытки разобраться, а потом просите о помощи.
Это вроде бы очевидно, но бывают дни, когда кажется, будто переходишь от проблемы к проблеме. Подобные ситуации ужасно раздражают и побуждают обращаться за помощью сразу же, как только проблема возникла. Это естественные побуждения, но старайтесь им не поддаваться.
Переведите дыхание, выйдите прогуляться, постарайтесь взглянуть на проблему под другим углом.
(Это, конечно, легче сказать, чем сделать!)
4. Не забывайте отдыхать и делать перерывы!
Не забывайте делать перерывы, когда кажется, что поток информации начинает подавлять. Пойдите прогуляйтесь. Выпейте стакан воды. Поспите, если можно. Порой помогает просто встать и немного подвигаться.
Помните, что через период становления прошел каждый разработчик, и вы тоже пройдете.
Процесс разработки всегда в некоторой степени раздражает. Вы постоянно допускаете ошибки и без конца сталкиваетесь с проблемами. Но со временем вы начнете куда лучше справляться со всем этим. Вы станете более уверенно решать возникающие проблемы, и они будут меньше вас беспокоить.
5. Спрашивайте у уточки
Вам случалось писать кому-то email или сообщение, описывая свою проблему, и вдруг, еще не дописав, находить решение самостоятельно? В сфере разработки это имеет свое название — «утиный дебаггинг». Это отсылка к книге «Программист-прагматик», в которой программист носил с собой резиновую уточку и занимался отладкой кода, заставляя себя пересказывать этот код строку за строкой уточке.
Когда вы пишете письмо или рассказываете о проблеме другому человеку, вам приходится логичным образом объяснять контекст — иначе собеседник ничего не поймет.
Чтобы это сделать, вы вынуждены обдумать проблему и как-то логически все упорядочить. А когда вы это делаете, вы невольно смотрите на проблему под другим углом, и часто это позволяет найти решение.
Возвращаясь к таймеру попыток, попробуйте скомбинировать этот подход с «уточкой». Прежде чем обратиться за помощью, попытайтесь объяснить свою проблему письменно, в черновике электронного письма. Весьма вероятно, что вам так и не придется отрывать коллег от их работы, поскольку вы справитесь самостоятельно. Но в наихудшем случае у вас уже будет готов отличный email или чат-сообщение, которые вы сможете отправить по назначению.
(Я неоднократно видел, что люди ставят себе на стол настоящих резиновых уточек!)
6. Ведите записи
Впервые попав в компанию, вы должны будете усвоить очень много информации. Вы будете знакомиться с кодовыми базами, продуктами, людьми, бизнес-логикой. Запомнить все это сразу невозможно, поэтому записывайте.
Когда я приступил к своей первой работе, мой босс сказал мне, что он с радостью объяснит мне что угодно, но он точно не хочет повторять что-либо дважды. Тогда я это понял, но теперь, восемь лет спустя, понимаю еще лучше. Это опять же об уважении к коллегам и к их времени.
Если человек мне что-то объяснил, а я это забыл — мы оба зря потратили время, к тому же, мне придется опять просить его объяснить. По совету босса я начал лепить себе записки на монитор и писать на них то, что хотел бы запомнить.
7. Ежедневно боритесь с синдромом самозванца
Если вы не знаете, что такое синдром самозванца, я объясню. Это когда у вас в голове постоянно звучит что-то вроде «Мне здесь не место. Я самозванец. Все остальные, кроме меня, все понимают».
С такими мыслями вам придется бороться ежедневно. У вас определенно будут неприятности на работе, но вы ведь уже встречались с неприятностями в вашей жизни, и успешно преодолевали их.
Синдрому самозванца подвержены очень многие разработчики, особенно начинающие, но со временем это пройдет.
В картинках синдром самозванца выглядит так:
Важное отличие разработчика-сеньора от джуниора
Конечно, у сеньора больше опыта, чем у начинающего разработчика, но не это его выделяет. У сеньора есть система решения проблем.
Когда я начинал свой путь в разработке, мне казалось, что когда-нибудь я перестану совершать ошибки.
Но все оказалось совсем не так. Я по-прежнему ежедневно допускаю невероятно много ошибок. Неправильный синтаксис, не тот файл, не та функция.
Я не перестал совершать ошибки, но я стал невероятно быстро их исправлять.
Это навык, который вырабатывается со временем в ходе решения задач.
Вот несколько советов по выработке такой системы.
5 советов по отладке
1. Не надо крушить код!
Я сам так поступал и неоднократно видел, что так же поступают многие другие начинающие разработчики. Вы сталкиваетесь с какой-то проблемой и начинаете что-то менять по всему коду. Вместо того чтобы подходить к делу системно и постепенно, люди вносят кучу быстрых правок, чтобы посмотреть, не устранит ли это проблему.
Это очень плохая привычка. Таким образом вы только внесете еще больше ошибок. Поступать надо по-другому:
2. Читайте сообщения об ошибках!
Это вроде как очевидно, но — правда, читайте эти сообщения. Что это за ошибка? В каком файле она появляется? На какой строчке кода? Все это жизненно важная информация.
Если вы удержитесь и не начнете сразу беспорядочно вносить правки, вы сможете перейти прямо в то место, где затаилась ошибка. Именно так и поступают опытные разработчики. Читают сообщения и переходят в указанное место.
Такой подход сэкономит вам кучу времени и избавит от лишних усилий.
3. Не нужно тратить время на невозможные (или невероятные) вещи!
Начинающие разработчики часто делают это. Они сталкиваются с ошибкой в коде, находят то, что (как им кажется) является причиной, а затем не могут поверить, что это не так. например:
«Я вижу, что проблема на 14 строке. Там проверяется, установлено ли для переменной is_admin значение true. Там значение не true, но ведь пользователь же является админом!»
Да, временами случается найти баг в языке или фреймворке, но в 99,9% случаев это вы что-то не так делаете или ситуация не такова, какой кажется.
Вместо того чтобы изумляться чему-то невозможному, лучше проверьте свои допущения относительно ситуации. Что-то определенно не так, как кажется. Ужасаться невозможному это пустая трата времени. Лучше запустите свою систему решения проблем.
4. «В случае сомнений выводите побольше всего на экран», — кто-то мудрый
Я не знаю, кто это сказал, но это одна из самых эффективных техник дебаггинга. Когда не знаете, что происходит, начните выводить состояние программы в подозрительных местах.
Что в переменной user? Каков ответ на HTTP-запрос? В этой ситуации мы использовали if или else? Мы вообще вызывали эту функцию? А на той ли странице мы находимся?
Я бессчетное число раз видел, как разработчики бились над отладкой (да и у самого такие случаи бывали), а на самом деле оказывалось, что они не с тем файлом работают! Быстрый print или console.log помогут убедиться, что вы проверяете именно тот код, который запускаете.
5. Делайте по шагу за раз
Все начинающие разработчики допускают одну общую ошибку: они делают много всего сразу.
Им хочется написать код за 30 минут, кликнуть кнопку запуска и увидеть, что все работает. Но по факту они проводят 30 минут за написанием багов и ошибок, исправлять которые — настоящий кошмар.
Когда я собираюсь создать новую страницу в приложении, первое, что я делаю, — пишу <p>привет</p> на странице. Мне нужно убедиться, что весь мой внутренний код настроен правильно и я действительно увижу на странице этот «привет». Я делаю один шаг за раз.
Вы тоже делайте по одной вещи за раз. Сначала сделайте так, чтобы на странице появился «привет». Затем получите input от пользователя. Потом проверьте этот input. На следующем шаге сохраните его. Если вы будете продвигаться маленькими шажками, в случае появления проблем вы всегда будете знать, где нужно вносить исправления.
Даже спустя восемь лет в разработке я все еще продвигаюсь в написании кода шаг за шагом. Я знаю, что точно допущу кучу ошибок, и хочу сразу узнавать, когда и где это происходит.
Заключение
Вы уже далеко зашли, но перед вами еще долгий путь. Вам предстоит многому научиться, выработать много новых навыков, а еще вас ждет много интересной и благодарной работы!
Не вешайте нос и не забывайте делать перерывы в работе. Совершенствуйтесь на 1% в день, и к концу года результаты вас поразят!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
