Главные ошибки, которые я допустил, работая junior программистом
Это перевод статьи, оригинал которой тут
По окончанию университета я, борясь с переутомлением и долгами, тем не менее, был полон надежд перевернуть мир профессионального программирования. Я уже что-то слышал об Agile и даже иногда-не-то-чтобы-часто применял эту методологию во время своей практики. За плечами у меня было много кода, написанного во время занятий в университете, персональных проектов и некоторый опыт временных подработок.
Я был уверен в том, что меня ждет хороший старт в роли Software Engineer-a, и был готов приступать к работе. Как большинство выпускников-программистов, я был готов учиться, расти и как можно быстрее стать лучшим в мире разработчиком.
И, как большинство junior программистов, я совершал ошибки. За первые две недели работы я написал баг, из-за которого одному из членов нашей команды пришлось работать сверхурочно, чтоб отчет был готов вовремя.
Тем не менее, большинство моих ошибок все же были связаны не с написанием багов или тем, что проект не был готов вовремя (хотя обе ситуации со мной, конечно же, случались). Они были связаны с тем, что я боялся выглядеть глупым. Многие из них были связаны с "синдромом самозванца" (imposter syndrome). Я боялся сказать, что не понимаю идею и концепт проекта, или же что я не могу запомнить, как обходить дерево.
Этот страх был причиной нескольких ошибок, которые я совершил в начале своей карьеры. Надеюсь, что эта статья о моих ошибках поможет вам избежать их на старте вашего профессионального пути.
Я не задавал достаточно вопросов
Я осознавал эту проблему, но нехватка знаний все равно не заставила меня задавать вопросы. Вместо этого я искал информацию с помощью Google или Stackoverflow (как и любой другой хороший программист, так ведь?)
На митингах я просто кивал головой и соглашался с тем, что говорили члены моей команды, надеясь, что никто не спросит моего мнения лично.
Если говорить в контексте кодинга, я продолжал читать ужасный код, который мне передали, надеясь, что в конце концов я пойму, что в нем написано (моя первая задача заключалась в обновлении биллинговой системы). Я потратил много часов, пытаясь прочитать не понятный мне код, просто потому что боялся спросить о значении какого-то акронима или термина.
Задавайте вопросы! Не поддавайтесь иллюзии, что вы не способны понять что-то простое, лишь из-за того, что вам не удалось понять это с первого раза. Помните, что каждый программист в вашей команде приложил множество усилий, чтоб изучить то, что он знает. Ваши коллеги тоже не знали всего после окончания обучения. Скорей всего, они тоже нуждались в помощи, чтоб понять что-то.
А возможно, среди них есть такие же, как и вы - те, кто просто стараются не отставать от команды. Вы удивились бы, если бы узнали, как много программистов кивают и молча соглашаются с какой-нибудь идеей, вообще не понимая, о чем идет речь.
Не стоит стыдиться, а стоит научиться задавать хорошие вопросы, которые направлены на улучшение понимания каждым членом команды. Например:
- Ты упомянул что-то о разделении таблицы. Я немного не понял, что ты имеешь в виду. Не мог бы ты объяснить это более детально?
- У меня есть проблемы с пониманием архитектуры проекта. Есть ли у нас какая-то документация по этой теме, которую я могу почитать?
- Сейчас я изучаю, как использовать ansible, но чувствую, что застрял с этим. Не мог бы ты мне помочь разобраться с парой вопросов?
Я делал слишком много утверждений
Когда я не задавал вопросы, я любил утверждать. Обычно, эти утверждения были непропорционально громкими и уверенными в сравнении с тем, сколько я знал на тот момент.
Я заметил, что это начало происходить примерно после первого года работы. В то время у меня уже было много знаний, и я не чувствовал себя новичком. К тому же, я хотел похвастаться тем, чему я уже научился на работе.
Мне кажется, это довольно важно помнить: типы совершаемых ошибок меняются в течение карьеры.
Я был резок, когда отстаивал свое мнение, и слишком горд, чтоб слушать других.
Я не понимал своей ошибки, пока проект, над которым работала моя команда, не оказался на грани провала. В команду пригласили несколько senior программистов, которые ознакомились с нашей работой и довольно быстро указали нам на наши ошибки. Конечно же, нам стоило иметь пару действительно senior программистов в нашей команде с самого начала, но это не зависело от меня.
В то время я осознал, что я все еще не до конца понимаю, что делаю, и как много всего, с чем еще нужно разобраться. Я снова научился слушать, задавать вопросы и нормально относиться к тому, что я чего-то не знаю.
Скорей всего, и для вас наступит момент, когда вам придется признать: несмотря на то, сколько всего вы уже знаете, гораздо больше всего еще нужно изучить. Чем раньше вы осознаете, что невозможно знать все, тем раньше вы начнете профессионально расти и развиваться.
Я перестал писать код, который не связан с рабочим проектом
Это то, где я потерял, как мне кажется, больше всего. Я перестал оттачивать свой навык кодирования, и вместо этого полностью сфокусировался на коде проекта.
Не поймите меня неправильно. Концентрация на коде и проекте работодателя была (и до сих пор есть) одной из главных составляющих успешного программиста. Но все же, я жалею, что не проводил пару часов в неделю за написанием кода для open-source проекта или выполнением заданий на LeetCode или TopCoder
Почему? Со временем большинство проектов начинают крутиться вокруг нескольких определенных концептов программирования. Я в основном работаю над сервисами с большой пропускной способностью и минимальной задержкой, которые общаются с помощью RESTful API. Тут бывают сложные задачи, но со временем они начинают быть похожими друг на друга. И я замечаю, что решаю их похожим способом.
Но я, например, никогда не работал с проектами, связанными с графическими движками, и не создавал даже простые текстовые редакторы (и со многим другим). Я не знаю, какие сложные для решения задачи имеют такие проекты, а я уверен, что имеют.
Работа над кодом вне своего проекта — это хороший способ поддерживать свои навыки кодинга на хорошем уровне и перспектива улучшить свое резюме с помощью вклада в open-source. Я уверен, что ваши технические скиллы вырастут до небес, если вы будете тратить на это хотя бы несколько часов в неделю. Если же вы не уверены, что можете выделить на это время, посоветуйтесь со своим менеджером. Возможно, вы сможете договориться о том, сколько рабочего времени вы можете потратить на кодинг для себя. В конце концов, в улучшении ваших технических навыков заинтересованы и вы, и работодатель.
Конечно же, я допускал много других ошибок. Но тут приведены те ошибки, которые ударили по мне больней всего.
Первые две ошибки связаны со страхом выглядеть глупо и желанием выглядеть лучше в глазах других. Не попадайтесь в эту ловушку! Фокусируясь на том, что думают о вас другие, постарайтесь помнить, что скорей всего, они не обращают на вас так много внимания, как вы думаете
Последняя ошибка связана с тем, что я перестал практиковаться в написании кода. Преданность написанию кода — это то, что привело меня к моей первой работе программистом. С тех пор как я стал senior программистом, я написал не связанного с работой кода больше, чем когда-либо. И это помогло мне писать код лучше на рабочем проекте (а также быстрее).
Я надеюсь, это поможет вам лучше начать вашу карьеру программиста.
…
Несколько слов от переводчика:
Может показаться, что автор статьи, описывая первую ошибку, говорит о том, что нужно задавать вопросы, вместо того, чтоб гуглить их или искать ответы на stackoverflow. Это не совсем так. Приведенные в статье примеры хороших вопросов помогают понять, что автор имел в виду.
Первый пример вопроса мы рассмотрим ниже. Второй вопрос задается, чтоб узнать, есть ли какая-то документация по проекту, и, понятное дело, читать ее. Во время чтения будут возникать вопросы, которые в свою очередь тоже можно погуглить и попытаться найти ответы. Ну или просто ознакомиться со смыслом того, из-за чего возник вопрос. Например, если вы в документации или коде встретили какой-то незнакомый паттерн, то можете почитать о нем, чтоб иметь базовое представление. Скорей всего, после прочтения ваш вопрос отпадет сам по себе. А может, и не отпадет. Тогда его можно задавать человеку из вашей команды. Но в это случае вы уже будете знакомы с этим паттерном на каком-то уровне, что сэкономит время человека, которому вы будете задавать вопрос. А возможно, у вас возникнет новый вопрос – почему тут (в коде) применяется этот паттерн? В любом случае, вы уже будете знать основу работы паттерна. И тогда вы сможете задать более точные вопросы, а человек, который отвечает на ваши вопросы, не будет тратить свое время, рассказывая вам о том, что можно было легко найти самому. То есть тут важно найти баланс. Не задавать слишком простые вопросы, но и не закапываться в долгий поиск ответа.
Вернемся к первому вопросу. Очевидно, что это пример вопроса во время какого-то разговора или митинга. В этом случае, конечно, у вас нет времени на то, чтоб погуглить. Во время митинга нужно сконцентрироваться на митинге. Если вы чувствуете, что какой-то вопрос не сильно повлияет на общее понимание предмета разговора, то можете поискать ответ после митинга. И тут главное записать то, что нужно потом погуглить. Если же вы теряете нить разговора, то спрашивайте.
Третий вопрос показывает, что человек уже изучает что-то и просто застрял на каком-то этапе изучения. Я уверен, что подавляющее большинство программистов будут рады помочь новичку советом, объяснением или просто ссылкой на полезную статью. Даже простой вопрос: «Я хочу разобраться с Docker. С чего посоветуешь начать?», - является хорошим вопросом для старта.