Перевод статьи «5 great Questions for Junior Developers to ask».
Когда разработчики-джуниоры приступают к работе на новом месте, зачастую они довольно плохо ориентируются в рабочих вопросах. И, что еще хуже, они часто стараются не задавать «лишних» вопросов — из-за стеснительности или нежелания надоедать коллегам.
Но подобные волнения излишни: задавать вопросы совершенно нормально. Более того, это важно и абсолютно необходимо. В этом посте я собрал некоторые из вопросов, которые сослужили мне хорошую службу в начале карьеры разработчика и облегчили вхождение в профессию.
«Как вас зовут?»
Хм, а это как-то связано с карьерой разработчика? Вы не поверите! Правда, здесь куда большее значение имеет не факт вопроса, а то, что вы запомните ответ.
В свой первый рабочий день обязательно будьте общительны и прямолинейны. Спрашивайте коллег, как их зовут, и старайтесь запомнить имена с первого раза. Поверьте мне, это имеет большое значение (поскольку первое впечатление можно произвести лишь однажды).
Если вы начнете свой путь с проявления вежливости, дружелюбия и интереса к коллегам, люди будут более терпимы к вашим ошибкам и с большей готовностью будут помогать вам, когда вы (неизбежно) столкнетесь с трудностями.
«На какие классы/файлы мне нужно обратить внимание при решении этой задачи?»
Самое сложное в программировании это не написание кода, а управление сложностью и чтение кода других людей. Разработчик-джуниор, только что столкнувшийся с большой и незнакомой кодовой базой, чаще всего и понятия не имеет, с какого края к ней подступиться. Начиная работать над выданным вам заданием, сразу спрашивайте коллег, куда нужно смотреть. Это сэкономит вам много времени и избавит от недоразумений.
«Я не уверен, что выбрал правильный подход для решения своей задачи. Как думаете, я на верном пути?»
При решении задач я подолгу приглядываюсь к разным частям кодовой базы, пытаясь соединить их так, чтобы это имело смысл. Бывает, что подход, который я придумал изначально, оказывается не настолько хорош, и тогда передо мной встает необходимость переписать свое решение или придумать совершенно другое. В таких случаях, прежде чем что-то менять, мне всегда хочется убедиться, что мои предположения верны. Потому что будет слишком обидно, если правильным на самом деле окажется первый вариант.
«Мне кажется, что эту часть моего кода можно оптимизировать или полностью переделать, но я не уверен, как именно это сделать. Можете дать мне фидбэк?»
При написании кода все довольно быстро запутывается, в результате возникает потребность в рефакторинге. Вопреки тому, что вам может казаться, опытные разработчики редко раздражаются, если вы спрашиваете их мнение насчет своего кода. Часто даже наоборот: у разработчиков уже бывает собственное устоявшееся мнение о том, как надо писать код, и они весьма охотно делятся этим мнением с окружающими.
Подобные вопросы помогут вам в написании кода, больше похожего на код коллег.
«Я прочитал требования к задаче несколько раз, но вот эта часть мне не понятна. Не могли бы вы объяснить подробнее?»
Умение понимать требования бизнеса это одна из самых важных частей работы разработчика, хотя об этом не часто говорят. На приобретение этого навыка может уйти довольно много времени. Поэтому я советую вам при возникновении любых вопросов по этой части задавать их как можно скорее, а не строить предположения самостоятельно.
Помните: спросив что-то у коллеги, вы отберете несколько секунд его рабочего дня, но если вы построите что-нибудь неверно, ему все равно придется вам объяснять все то же самое, только еще и исправлять ваши ошибки.
Всегда стоит помнить о том, что задавать вопросы это хорошо. Это показывает окружающим вашу заинтересованность и мотивацию, а также способствует вашему росту. Никогда не бойтесь спрашивать, но при этом не забывайте оставлять себе некоторый простор для самостоятельной работы и экспериментов.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
«это имело смыл.» — смыСл
Спасибо, исправили!