Перевод статьи «11 do’s and don’ts for your first programming job».
Все, что происходит в нашей жизни впервые, может быть очень захватывающим, но при этом и подавляющим. Когда я приступала к своей первой работе, я знала, что мне предстоит изучить много технических премудростей. Но я не осознавала, что есть также множество других навыков, нужных хорошему разработчику (помимо умения писать код). И для того, чтобы продвигаться по карьерной лестнице, необходимо приобрести каждый из этих навыков. Причем чем раньше вы это сделаете, тем быстрее избавитесь от приставки «джуниор» в названии вашей должности. Итак, вам…
Следует: найти наставника
Найдите человека (или нескольких людей) не из вашей компании, которому вы сможете задавать вопросы и от которого будете получать советы. Иметь наставника в собственной компании хорошо и тоже важно, но я советую найти как минимум одного постороннего человека, у которого вы сможете учиться. У него не будет никаких предубеждений относительно вас, а вам не придется волноваться ни о каких конфликтах интересов, так что вы сможете по-настоящему комфортно себя чувствовать, задавая любые вопросы.
Как найти наставника? На эту тему можно сделать отдельный пост. Но если кратко, то посещайте митапы и прочие технические мероприятия, знакомьтесь с людьми, подписывайтесь на них в соцсетях и давайте окружающим понять, что вы новичок в индустрии и ищете наставника. Вы удивитесь, узнав, как много посторонних людей захотят вам помочь.
Не следует: бояться задавать вопросы
Раньше я думала, что, задавая вопросы, я тем самым покажу свою слабость. Это как бы выявит мой недостаток опыта. Теперь я понимаю, что вопросы это суть работы программиста.
Умных незнакомых слов тысячи, и с каждым днем их становится еще больше. Даже люди, много лет работающие в этой индустрии, постоянно учатся чему-то новому. Все знать невозможно. Поэтому вопросы это неотъемлемая часть программирования.
А вот умение задавать хорошие вопросы это навык. И чем раньше вы его приобретете, тем быстрее станете уверенным в себе программистом.
Есть один совет относительно того, когда следует обращаться к окружающим с вопросами:
Для начала соберите достаточно информации для эффективной коммуникации: что работает, что не работает, что вы уже испробовали и каких сведений вам не хватает, чтобы разобраться со своей проблемой.
Пример «плохого» вопроса: «Понятия не имею, что здесь происходит, но что-то не так…»
Пример «хорошего» вопроса: «Я проверил логи и смог воспроизвести это локально. Кажется, что проблема где-то между Х и Y. Думаю, дело или в используемой нами версии API, или в том, что отсылается какое-то непредусмотренное значение. Может быть причина в чем-то другом, в чем-то, что я упустил, как думаешь?».
Следует: делиться своими успехами
Не каждым, конечно. Но если есть что-то, чем вы и вправду гордитесь, поделитесь этим со своей командой. Можете использовать для этого электронную почту или Slack. Опишите кратко, что вы сделали, как решили проблему, что узнали и в чем ценность этого.
Если у вас хороший менеджер, он должен побудить вас рассказать об этом на общем собрании команды, выступить на митапе или даже на конференции. Если нет, берите инициативу в свои руки и ищите митапы, которые можно посетить, соберите команду, чтобы поговорить о своем достижении, или даже напишите пост в блоге.
Трубить о своих достижениях может показаться неудобным, но поверьте мне: очень важно быть на виду. Это помогает вам заслужить уважение и признание на работе. Никто не узнает, насколько вы потрясающий специалист, пока вы это не покажете.
Не следует: паниковать
Неприятности неизбежны. И не важно, вы лично послужили их причиной или нет. Вопрос не в том, будут ли проблемы, вопрос в том, когда они будут. Поэтому, когда проблема появится на горизонте, как можно быстрее дайте об этом знать заинтересованным лицам (менеджеру продукта, техлиду, коллегам по команде), а затем обсудите со своим техлидом или менеджером, как вы собираетесь решить эту проблему.
Чем более спокойным и собранным вы будете, тем более уверенным покажетесь. Проколы случаются у всех. Даже у самых лучших из нас. Единственный способ гарантировать отсутствие багов – вовсе не писать никакого кода.
Следует: говорить погромче на митингах
Поначалу вас может пугать перспектива присутствовать на митинге с куда более опытными коллегами (я была в вашей шкуре, я знаю). Но не позволяйте страху контролировать вас. Вы – пара незамыленных глаз, и если что-то вам кажется странным или непонятным, вероятно, оно такое и есть – странное и непонятное.
Если вы заранее знаете, что будет обсуждаться, попытайтесь загуглить эту тему и немного подготовиться к митингу. Если узнать тему заранее не удалось, а обсуждается что-то, с чем вы не знакомы, попросите объяснить вам в общих чертах или ввести в курс дела. Сделайте это в начале митинга. Это покажет, что вы вовлечены в процесс, что вам не все равно. Если вы будете тянуть с этим до конца собрания, когда вас спросят, есть ли у вас вопросы, вы просидите все это время, не имея ни малейшего представления, о чем говорят коллеги, а это не улучшит ваше самочувствие.
Не следует: постоянно пытаться проявить себя
Когда вы только начинаете, не стоит слишком на себя давить и стараться делать какие-то большие, сумасшедшие, впечатляющие вещи, чтобы быть замеченным командой. Таким образом вы потратите много сил впустую и не получите того отклика, на который надеетесь.
Дело в том, что все ваши коллеги заняты делом и сосредоточены на собственных задачах и обязанностях. Никто не заметит (и всем все равно), что вы закончили фичу за рекордное время или взяли 8 дополнительных фич сверх обычной нагрузки, или что QA никогда не находили никаких багов в ваших фичах. Так что не нужно убиваться. Оно того не стоит. Поверьте мне.
Что поможет вам заслужить уважение коллег, так это ответственность, увлеченность своим делом, любознательность и вдумчивость. Покажите команде, на что вы способны: продумывайте, как ваша фича повлияет на другие области продукта, поднимайте тему потенциальных проблем, тщательно тестируйте ваши фичи (и просите других проверить ваши идеи), сообщайте о потенциальных edge-cases менеджеру продукта, всегда задавайте вопросы, если в чем-то не уверены.
Бонусный совет: если вы действительно хотите выделиться, займитесь мини-проектом, который поможет каждому члену команды в его рабочем процессе. Уделите внимание и найдите «болевые точки» в вашей работе, а затем напишите маленький shell-скрипт для автоматизации этого процесса. Или, если ваша команда пользуется Slack, создайте или найдите какое-то полезное дополнение. Убедитесь, что в этой вещи действительно есть потребность и что вы нашли действительно удобный способ решения вопроса. Спросите коллегу, что он думает по этому поводу и не может ли он просмотреть ваш код вместе с вами. Вы получите дополнительные очки за проявление инициативы и создание чего-то, что поможет каждому в ежедневной работе.
Следует: активно коммуницировать с коллегами и менеджерами
Сначала я считала, что нужно вести себя в стиле «работать, не поднимая головы». Если дизайнер вносил изменения, коллега неожиданно менял API или попадался крупный баг, которым приходилось заняться в первую очередь, я думала, что я должна принять это, как данность, и продолжать работать. Я думала, что если я что-то скажу, то это покажется жалобами или оправданиями. Но нет. Сообщать обо всем этом менеджеру продукта и техлиду действительно важно.
Это их работа – расставлять приоритеты и распределять задачи в зависимости от загруженности каждого члена команды. Если происходит нечто, способное вызвать задержку окончания работы над проектом, они должны узнать об этом как можно скорее, чтобы все уладить.
Кроме того, для менеджера и техлида важно знать, почему какие-то вещи занимают больше времени, чем ожидалось. В противном случае они могут подумать, что это из-за вашей медлительности и низкой производительности. И если дело НЕ в этом, важно, чтобы они это поняли.
Никто не поставит вам в вину излишнюю общительность. А вот игра в молчанку может привести к проблемам.
Не следует: ждать признания окружающих
У вас в работе над фичей только что был момент из серии «Эврика!». Вы думаете: «Вау, не могу поверить, что я это сделал!». Вы себя поразили – и этого должно быть достаточно. Ваши коллеги могут уже и не помнить, каково это – задеплоить свою первую фичу, реализовать какую-то рекурсивную функцию или впервые перенести базу данных. Для вас это сплошной восторг, и так и должно быть. Найдите среди коллег людей, способных разделить с вами эти ощущения и порадоваться за вас.
Следует: приложить усилие и изучить сочетания клавиш
Обратите внимание на своих коллег. Вы заметите, что они редко прикасаются к своей мыши или тачпаду. Они умеют переключаться между приложениями, перемещаться по текстовому редактору, осуществлять поиск и замену «вслепую». Изучение сочетаний клавиш, позволяющих все это делать, позволит вам стать более эффективным разработчиком, подняться на новый уровень. Главное, не пытайтесь освоить все сочетания за раз.
Также есть отличные инструменты командной строки, которые вы могли бы скачать.
Спросите у коллег, какими приемами и уловками они пользуются.
Не следует: всегда со всем соглашаться
Сначала я на все запросы отвечала «да», потому что хотела быть командным игроком и человеком, на которого товарищи могут положиться. Но это было зря, таким образом желаемых результатов не достигнуть. Такой подход привел к тому, что я работала больше, благодарности получала меньше, а в результате теряла фокус.
«Умение фокусироваться это умение говорить «нет», – Стив Джобс.
Нужно стремиться к балансу. Если вы джуниор, вам часто поручают задачи, за которые никто другой не хочет браться. Это нормально. Вы хотите приложить руки к любому делу, и не важно, насколько задача «скучна» – вы же все равно на ней учитесь. Но выполнение этой задачи не должно вас подавлять и заставлять пожалеть о своем согласии за нее взяться (а это вполне реально, если подвернется другая возможность, от которой придется отказаться).
Следует: заниматься разными вещами помимо работы
Определите, что вам интересно, и поищите возможности для волонтерства в этой сфере. Найдите митапы, которые сможете посетить. Вступите в какие-нибудь группы/организации. Работайте над личными проектами. Пишите посты для блога.
Разработчик должен быть частью сообщества и делиться чем-нибудь с этим сообществом.
И, честно говоря…
На то, чтобы почувствовать себя уверенно, следуя этим 11 пунктам, уйдет некоторое время. Научиться всему этому сложно. Собственно, сама я все еще работаю над несколькими из этих правил. Это все приходит по мере накопления опыта, но я хотела бы, чтоб кто-то сказал мне обо всем этом, когда я начинала.
Старайтесь прорабатывать каждый из советов по отдельности, по одному за раз. Главное, к чему следует стремиться:
- Защищать себя.
- Быть уверенным в себе.
- Задавать вопросы.
- Окружать себя поддерживающими, побуждающими к действиям людьми.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]