Освободитесь от юниорства типажей

Мы все начали с этого в какой-то момент, независимо от того, что может знать конкретный разработчик или как долго он работает, каждый начинает с самого начала, и нет никакого способа обойти это.

Но если вы прямо сейчас, приступаете к работе и задаетесь вопросом, что вам следует делать, чтобы перейти на следующий уровень в вашей компании (это может быть старший, полу-старший, младший продвинутый или любой другой вариант имен, которые вы можете использовать ), а затем я постараюсь дать вам несколько рекомендаций, основанных на моем предыдущем опыте и на том, что я обычно ищу в перспективных младших разработчиках.

Вы можете обнаружить, что некоторые из этих рекомендаций не применимы в вашем контексте, и это совершенно нормально, это не сценарий «все или ничего», а скорее тип «вы должны стремиться к некоторым из этих поведений в будущем». вещи.

Автономия

Когда вы только начинаете работу, когда кто-то другой держит вас за руку в процессе работы над вашей задачей, написания кода, устранения неполадок и фиксации его в основном репозитории - это хорошо.

Фактически, это кажется безопасным. И это отличное место. Проблема в том, что держание за руку может завести вас только до определенного предела. В конце концов, вы должны показать, что в ходе этого процесса вы также изучаете и применяете то, что вы узнали, для решения других, новых проблем.

Не путайте автономию с изолированной работой, никогда ни к кому не обращаясь за помощью.

Это просто глупо. Я имею в виду возможность получить задачу и поработать над ней самостоятельно. Это также включает в себя такие вещи, как:

  • Просить разъяснений, когда требования не ясны.
  • Обращение за помощью, когда возникает проблема, которую вы не знаете, как решить.
  • Поднимать руку и говорить, когда вы не согласны с целью задания.

Итак, вы видите, что «автономия» - это не закрытие рта и работа, а скорее не ожидание, что кто-то другой покажет вам, что тикет недостаточно ясен и что вы должны попросить разъяснений. Или просто делать то, что вам говорят, даже если вы знаете, что это неправильно.

Это не то, что вы будете развивать внезапно изо дня в день, скорее, вы будете развивать это всю свою карьеру. Но благодаря практике и опыту вы начнете приносить гораздо больше пользы, чем то, что вы можете принести с помощью своих навыков программирования.

И я понимаю, это страшно. Говорить, когда вам кажется, что вы недостаточно знаете, может быть ужасающим занятием. Поэтому постарайтесь прислушаться к следующим советам:

  1. Делайте это из смирения, а не высокомерия. Не заявляйте, что существует внешняя проблема, которая мешает вам работать, а скорее, что вы не можете работать с текущей ситуацией и хотели бы получить некоторую помощь.
  2. Нет ничего плохого в том, чтобы задавать вопросы или требовать помощи от коллег (в конце концов, мы все постоянно учимся), просто постарайтесь исчерпать все возможности, прежде чем делать это. У вас есть вопрос о решении программной проблемы? Вы уже искали проблему в Google? Вы хотите понять, как написать сообщение о коммите? Вы уже читали документацию? Используйте очевидные решения, чтобы показать своей команде, что вы способны самостоятельно устранять неполадки и обращаетесь к ним, потому что вам нужен их опыт.

Автономия - одна из ключевых черт, на которую обращают внимание менеджеры, когда думают о продвижении человека на руководящую должность. Таким образом, чем больше вы разовьете этот навык, тем больше у вас будет шансов получить следующее повышение.

Гибкость

Я предпочитаю эту черту, но знаю, что другие менеджеры со мной не согласны.

Дело в том, что многие разработчики склонны ограничивать себя определенной технологией. Вместо того чтобы считать себя «разработчиками», они считают себя «разработчиками JAVA», «разработчиками React» или «разработчиками .NET».

Согласен, это твоя специальность, я аплодирую, ты молодец, фантастика. Но если вы работаете достаточно долго - а, скорее всего, это не так, - вы узнаете, что большинство технологий очень похожи.

Если вы знаете JAVA, то переход на C # не так уж и сложен, или даже переход на Node.js. Есть концепции, которые очень похожи, а другие вам придется изучить. Если вы до сих пор работали над настольными приложениями, а теперь вас попросили поработать над веб-приложением, вы столкнетесь с такими понятиями, как HTTP-запрос, DOM и другими. Но это всего лишь часть нашей индустрии: мы всегда учимся.

Худшее, что я могу услышать от кого-то, - это «но я не знаю, как это сделать; Я никогда раньше этого не делал ».

Конечно, нет. Никто не сделал всего, мы постоянно находим новые проблемы, которые никогда не решались раньше. Насколько скучной была бы наша профессия, если бы нам постоянно приходилось решать одну и ту же проблему снова и снова?

Принятие обучения также делает вас очень гибким разработчиком. Тот, который может быстро освоить новые навыки и технологии.

Имейте в виду, я не говорю, что вам нужно знать, как освоить новую технологию за неделю. Я говорю, что при наличии возможности вы не должны убегать от решения чего-то совершенно нового и неизведанного. Вместо этого вы должны сначала прыгнуть головой, желая учиться.

Из-за этого мышления я работал с такими языками, как JAVA, PHP, C #, Node.js (или, скорее, JavaScript в целом), Python, немного Perl, Ruby и, возможно, с некоторыми другими, которые я не помню. Сейчас. Я эксперт по всем из них? Черт возьми нет! Я не думаю, что это возможно. Но я узнал что-то новое от каждой из этих технологий. И, что наиболее важно, я могу сразу же приступить к проекту и помочь, если потребуется. Это огромная добавленная стоимость и тот опыт, к которому вы должны стремиться.

Право собственности на вашу работу

Это очень связано с автономией, но я думаю, что он заслуживает отдельного раздела.

Как разработчики, мы работаем над несколькими функциями, а иногда даже над несколькими проектами одновременно. Но есть разница между тем, чтобы делать то, что вам говорят, и работать над тем, о чем вас просят.

Первый делает из вас бездумную кодирующую обезьяну. Жестко, я знаю, но вы просто пишете код, чтобы выполнить задание, которое вам кто-то дал, не задавая вопросов и не поднимая головы от ключевого слова. Это настолько просто, что обезьяну можно обучить этому (возможно, с моей стороны это преувеличение, но вы поняли).

С другой стороны, если ваша работа принадлежит вам, вы внезапно начнете:

  • Беспокоитесь о том, что вы реализуете и почему вы это делаете.
  • Интересно, какое влияние ваша работа окажет на продукт в целом.
  • Поднимать руку, когда что-то в вашей работе кажется вам неправильным или может оказать негативное влияние в другом месте.

Видишь, что происходит? Поскольку теперь вы «владеете» своей работой, вы не только выполняете ее «легкую» часть (написание кода), вы также добавляете гораздо больше ценности своей команде и проекту: вы заботитесь о проекте и вы заботитесь о его интересах.

Это не то, что может сделать обезьяна! Так поступил бы старший разработчик. В сочетании с автономией это то, что мы, менеджеры, склонны искать в младших разработчиках, поэтому подумайте о том, чтобы приложить дополнительные усилия и постараться понять, как все сочетается с вашей работой.

Лидерство

Нет, я не прошу вас возглавить команду на вашей первой работе. Перестань переживать по этому поводу!

Лидерские навыки являются обязательными для более высоких должностей в нашей отрасли, и я лично рекомендую уже начать над ними работать, медленно, но неуклонно.

Почему? К сожалению, очень немногие компании проводят обучение для новых менеджеров или технических руководителей. Напротив, это навыки, которые вы приобретаете «на ходу». Итак, что может быть лучше, чем сейчас, чтобы начать собирать их?

Хотя автономия и здесь очень важна, это лишь одна из многих вещей, которые вам понадобятся, чтобы стать техническим лидером.

Другие способности, над которыми вы, возможно, захотите начать работать (и практиковаться всякий раз, когда вы видите для этого шанс):

  • Коммуникативные навыки. Хороший лидер должен понимать, как общаться с другими. Как технические, так и нетехнические аналоги. Отличный способ развить этот навык - вести собственный блог. Письмо - отличная форма общения, которую вы можете практиковать бесплатно. Чем больше вы напишете, тем лучше будете объяснять сложные концепции. Вот почему я всегда говорю, что у каждого разработчика должен быть свой блог.
  • Техническая экспертиза. Нет, лидеры не должны быть гуру своих команд. Я писал об этом в прошлом, но лидеры должны обладать достаточными техническими знаниями, чтобы понимать проблемы, с которыми сталкивается их команда, и хорошо ли звучит решение. Если вы уже беспокоитесь об улучшении своих навыков разработчика, это качество придет само по себе, поэтому вам не нужно слишком о нем беспокоиться. Однако помните: если вы думаете, что уже знаете все, что нужно знать о своей области знаний, значит, вы работаете против себя.
  • Уверенность в своих навыках. Навык, который сложно развить, особенно с учетом того, насколько распространен синдром самозванца в нашей отрасли. Но лидер должен быть уверен в своих навыках и своей способности руководить командой. Это то, что вы получите через опыт, но вы получите его только в том случае, если будете искать возможности вырваться из своей зоны комфорта.

Все это навыки, которые вы будете развивать со временем, и не следует ожидать, что они будут обладать младшими разработчиками. Однако чем больше вы над ними работаете, тем быстрее вы начнете показывать своей команде (и менеджерам), что у вас есть все необходимое для достижения следующего уровня старшинства (постепенно приближаясь к руководящей должности, если вы этого хотите, является).

Не поймите меня неправильно, я понимаю, насколько пугающей становится ваша первая работа разработчика, и как все кажется новым, и все выглядят полными хулиганами, которые точно знают, что делают каждую секунду дня.

Но вам следует на время перестать смотреть и сосредоточиться на себе. Если вы заинтересованы в продвижении по карьерной лестнице, сосредоточьтесь на навыках, которые я упомянул здесь, которые, хотя они могут и не носить технический характер, они очень необходимы и помогут вам продвинуться намного быстрее, чем просмотр другого руководства по Flask.

А вы? Вы бы порекомендовали младшему разработчику какой-либо другой навык для повышения? Делитесь в комментариях!