Я работаю инженером-программистом последние 4 года, и, согласно уровню роли, которую я выполняю для своих клиентов, я официально нахожусь на среднем уровне, но как мне иди туда? Я подготовил несколько ключевых моментов, чтобы задокументировать свое путешествие!

Прислушивайтесь к отзывам старших разработчиков

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

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

Кодируйте, тестируйте, рефакторинг и тестируйте

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

Стратегия, которая очень помогла мне улучшить мой код, заключается в следующем:

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

Следуя этим шагам, я смог предоставить лучший код и лучшие функции благодаря двойному этапу тестирования!

Принимайте решения там, где это возможно

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

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

Сообщите о статусе, ожиданиях и проблемах

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

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

Освойте свой Git

Git — это тот инструмент, который, вероятно, будет использоваться везде в вашей ежедневной деятельности, независимо от того, используете ли вы его с пользовательским интерфейсом, в версии CLI или любым другим способом, который вам нравится. Чтобы понять, как перебазировать ветку, объединить ветку, создать ветку и т. д., очень важно сотрудничать с другими разработчиками в репозитории. Я предлагаю просмотреть некоторые онлайн-ресурсы о Git и постепенно раскрыть его потенциал, экспериментируя с фиктивными проектами.

Наряду с этим еще одним важным шагом является ежедневная проверка действий, происходящих на хостинг-провайдере Git вашей компании, будь то Github, Bitbucket, Gitlab или что-то еще. можете проверить реальный вклад, который вы вносите в проект, и следить за вашим ростом. Кроме того, это хорошее место, чтобы проверить PR других разработчиков, особенно от более опытных разработчиков, чтобы выявить различия между их и вашей реализацией!

Признавайте и учитесь на своих ошибках

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

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

Будьте разработчиком на 360 градусов

За 4 года работы в этой отрасли я повидал много разработчиков, и в последнее время я постоянно замечаю разницу между разработчиками от А до Я и 360-градусными разработчиками. Что это значит? Для меня разработчик из А-Я — это разработчик, который при получении ввода выполняет некоторые основные действия и приходит к вам с выводом или ошибкой и остается на месте, пока вы не дадите ему дополнительные инструкции. Это раздражает по двум причинам: во-первых, ему нужны другие люди, которые будут вводить постоянные инструкции, чтобы заставить его работать, а во-вторых, он никогда не подумает о том, чтобы выйти за рамки его/ее возможностей, чтобы решить проблему или дать лучшее решение. выход.

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

Это говорит о том, что разработчик должен с самого начала четко понимать, что она/он — это не просто робот, способный закрыть задачу, выполнив и написав x строк кода. У разработчиков гораздо больше возможностей для улучшения. Например, в бизнес-стороне, понимая логику того, что он/она строит, а также в технической части, улучшая рефакторинг или оставаясь в курсе последних технологий и так далее!

В конечном счете, вам нужно как минимум 1/2 года опыта, чтобы быть классифицированным как разработчик среднего уровня, и то, что вы делаете в течение этих лет, может либо ускорить процесс, либо замедлить его!