Кодом и потом: 4 мифа о том, как становятся сеньорами

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Миф 1: сила знаний в книгах, или пусть мне подскажут

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

  1. Сложность задач, которые решает сотрудник.

  2. Скорость выполнения работы.

  3. Качество – решает ли задача проблему пользователя, не создавая при этом других препятствий.

  4. Поддерживаемость – насколько хорошо спроектирован и протестирован код.

  5. Эффективность – достижение результата с наименьшими затратами.

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

Миф 2: стаж определяет профессионализм

Вокруг полно примеров специалистов, которые много лет работают в индустрии и стагнируют. Так происходит, потому что многие отделяют саморазвитие от работы. Это неэффективно, потому что после трудового дня энергии на изучение чего-либо не остается.

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

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

Миф 3: hard-skills важнее soft skills

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

Как лучше: must have в софт-скиллах – коммуникации и умение решать проблемы. Поначалу джуны работают только со своим отделом. Потом им предстоит сотрудничать с коллегами из других направлений, поэтому налаживайте мосты сразу, решение проблем иногда требует построения гипотез и предварительных исследований. Сильный переговорщик может договориться с любым сотрудником компании. Для этого необходимы знания в смежных направлениях, будь то бэк, аналитики, дизайн, маркетинг и не только.

Миф 4: если не критикуют, все в порядке

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

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

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

  1. Развивать навыки и решения проблем.

  2. Нацелиться приносить своей работой больше пользы.

  3. Осознанно развиваться, повышая сложность и креативность задач.

  4. Вытаскивать обратную связь.

Источник: https://habr.com/ru/company/kolesa/blog/571498/


Интересные статьи

Интересные статьи

Нередко при работе с Bitrix24 REST API возникает необходимость быстро получить содержимое определенных полей всех элементов какого-то списка (например, лидов). Традиционн...
Существует традиция, долго и дорого разрабатывать интернет-магазин. :-) Лакировать все детали, придумывать, внедрять и полировать «фишечки» и делать это все до открытия магазина.
Здравствуйте. Я уже давно не пишу на php, но то и дело натыкаюсь на интернет-магазины на системе управления сайтами Битрикс. И я вспоминаю о своих исследованиях. Битрикс не любят примерно так,...
На сегодняшний день у сервиса «Битрикс24» нет сотен гигабит трафика, нет огромного парка серверов (хотя и существующих, конечно, немало). Но для многих клиентов он является основным инструментом ...
С версии 12.0 в Bitrix Framework доступно создание резервных копий в автоматическом режиме. Задание параметров автоматического резервного копирования производится в Административной части на странице ...