Карьерный совет для младших разработчиков

Опубликовано: 12/01/2021 Время на прочтение: 7 минут

Фото NeONBRAND на Unsplash.

Инженеры-программисты в начале своей карьеры часто спрашивают меня: «как я могу быстро повысить свой уровень?”

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

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

1. Задать много вопросов

Фото Камиллы Баттани на Unsplash.

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

Задавая вопросы, особенно на открытом форуме, как в одном из слабых каналов вашей компании, вы оказываетесь в уязвимом положении. Вы можете задаться вопросом: «будут ли другие смотреть на меня свысока, потому что я этого не знаю? Потеряю ли я доверие как инженер-программист?” В такие моменты важно напомнить себе о некоторых вещах.

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

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

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

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

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

Когда Google проводила исследование, чтобы определить, какие факторы способствуют высокой производительности команды, психологическая безопасность была вкладом №1. Члены команды должны чувствовать себя в безопасности и быть уязвимыми друг перед другом.

Итак, какие вопросы вы могли бы задать как младший разработчик, чтобы быть более эффективным? Вот несколько примеров:

  • Не могли бы вы дать мне пошаговое руководство по архитектуре нашего приложения? Какие фреймворки и библиотеки мы используем?
  • Не могли бы вы дать мне пошаговое руководство по структуре каталогов нашей кодовой базы? Где живет этот код? Как она организована?
  • Как выглядит процесс разработки? Какой тип рабочего процесса Git мы используем?
  • Как выглядит процесс выпуска? Как новый код попадает в производство? Как часто выпускается новый код?
  • Почему [функция X] была реализована именно так?
  • Почему мы используем [библиотеку а], а не [Библиотеку Б]?

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

2. Обратиться за помощью, когда вам это нужно

Фото Эми Хирши на Unsplash.

Точно так же важно обращаться за помощью, когда она вам нужна.

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

Вот отличное эмпирическое правило: если вы застряли на чем-то, попробуйте еще 15 минут, и если вы все еще застряли, вы должны попросить о помощи.

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

Если 15-минутный лимит времени истек, а вы все еще чувствуете себя застрявшим, вы должны обратиться за помощью. Вы можете думать, что это благородно-продолжать бороться самостоятельно, но помните, что вам платят за работу, которую вы делаете. Вы не несете финансовой ответственности за то, что тратите часы и часы на что — то, не добиваясь никакого прогресса, особенно если коллега может дать вам быстрый указатель, чтобы разблокировать вас. Ваши товарищи по команде могут быть отличным ресурсом для вас и всегда готовы помочь.

Знают ли они об этом или нет, опытные учителя и наставники часто используют теорию зоны ближайшего развития Выготского, а также строительные леса, помогая младшим разработчикам. Зона ближайшего развития (ЗПР) — это “расстояние между тем, что ученик может сделать без посторонней помощи, и тем, что он может сделать при поддержке кого-то, обладающего большими знаниями или опытом.” Строительные леса — это техника предоставления руководства студенту, чтобы помочь ему работать в рамках ЗПД.

Таким образом, полезный наставник дает младшему разработчику достаточно указаний, чтобы он мог выполнить свою задачу, или достаточно информации, чтобы разблокировать его на любой стадии разработки.

3. Постоянно Учитесь

Фото Адеолу Элету на Unsplash.

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

«Правило 10 000 часов» было популяризировано книгой Малкольма Гладуэлла «выбросы» еще в 2008 году. Это правило гласит, что требуется примерно 10 000 часов работы, чтобы стать экспертом в этом. Хотя вполне логично, что чем больше вы практикуете что-то, тем лучше у вас это получится, правило 10 000 часов было развенчано другими несколько раз с момента публикации книги.

Оказывается, что на самом деле важно не только то, сколько вы практикуете, но и то, как вы практикуете. Есть разница между” практикой “и «преднамеренной практикой».”

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

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

Если вы чувствуете, что вам трудно писать модульные тесты, пройдите двухчасовой курс Pluralsight по модульному тестированию с Jest (или любой другой фреймворк тестирования, относящийся к вашему языку программирования).

Если вы пытаетесь научиться реагировать, идите и читайте документы. Врачи отнеслись очень хорошо!

Постарайтесь понять некоторые основы технологий, которые использует ваша компания. Познакомьтесь с AWS, Heroku или любыми другими провайдерами IaaS/PaaS, которыми вы пользуетесь. Если ты разработчик, узнать фреймворка или библиотеки, которые использует ваша компания, как угловые, реагировать, или Вью. Если вы часто работаете с базами данных, узнайте о различиях между базами данных SQL и NoSQL, а также об их сильных и слабых сторонах.

Этот термин, придуманный Стивеном Р. Кови, является последней привычкой в его книге «7 привычек высокоэффективных людей». Цитируя доктора Кови, “мы никогда не должны быть слишком заняты пилением, чтобы тратить время на заточку пилы.”



прокрутка вверх