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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии (9)


  1. Gorthauer87
    06.08.2021 10:39

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

    И вот, не всем это нравится, потому что другим потом сложнее это все понимать.


    1. aryslanova Автор
      09.08.2021 07:06

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


  1. iiwabor
    06.08.2021 10:56
    +3

    Учиться надо непрерывно и постоянно, как только говоришь себе "Я все уже знаю" - начинается стагнация.

    "Чтобы оставаться на месте нужно бежать изо всех сил, а чтобы двигаться вперед - нужно бежать еще быстрее!" Л. Керолл


  1. Lofer
    06.08.2021 12:24
    +2

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

    Обезьянка видит - обезьянка делает, к сожалению такого "побочного" эффекта не имеет. Обезьянка не построила ракету для полета в космос, однако не плохо колет орехи камнем.

    must have в софт-скиллах – коммуникации и умение решать проблемы

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

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


    1. aryslanova Автор
      09.08.2021 08:37

      Для того, чтобы никто не "садился" на шею другой стороны, есть грейды. Хороший тимлид не допустит такого.

      В данном контексте подразумеваются коммуникации с точки зрения исследования: "как это можно сделать", "как это делали ранее", "как улучшить свой процесс", а не "сделай за меня".

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


  1. HellWalk
    06.08.2021 13:47
    +4

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

    Смешались в кучу кони люди...

    Если рядовой программист 90% времени пишет код - то hard-skills для него важнее

    Если тим-лид 90% времени общается и занимается взаимодействием между людьми и отделами - то для него важны soft skills

    Ну и главный миф: что можно спокойно перейти из написания кода в управление людьми.


    1. aryslanova Автор
      09.08.2021 06:54

      Основная наша мысль была такой: хочешь быстрее вырасти - умей общаться. Без soft skills обучение может затянуться. Рядовой программист будет учиться только на своих ошибках, нежели если он будет узнавать мнения у тимлида или команды.


      1. HellWalk
        09.08.2021 10:05

        узнавать мнения у тимлида или команды

        Вроде как для этого делают обязательное ревью кода


    1. kalombo
      09.08.2021 13:49

      Хм, если вы пишите код, хотя бы вдвоем, уже важны soft-skills, вам приходится "продавать" свои идеи и решения. Вам придется научиться договариваться, т.к. разногласия в выборе решения неизбежны. Особенно если вы 90% времени пишете код, значит 90% времени у вас вероятность появления разногласия