Лет 8 назад я писал о том, как растить джунов. Джуны за это время подросли до Middle+ и… застряли. Денег хотят больше, а давать не за что. На Senior не тянут. Что делать?

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

Кто есть кто

Стажёр – ещё не закончил университет, но проявил инициативу, чтобы попасть на практику в конкретную контору. Базовый уровень инициативности, умение выслушать чего от него хотят, уточнить детали, начать что-то делать, по ходу дела как-то продолжать задавать вопросы, но в итоге сделать задачу правильно – большего от стажёра не требуется. Почему “как-то” курсивом: много – плохо, мало – плохо, совсем не задавая, сделать правильно не получится. Идеального решения нет, поэтому любое сойдёт.

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

Миддл – достаточно разбирается в том, как что работает в техническом плане, чтобы самостоятельно и готовые задачи решать, и создавать новые, проявляя базовые навыки декомпозиции. Не обязательно ставить задачи кому-то другому, декомпозиция для себя тоже важна. Это человек, который научился нормально работать в команде и думает о других, наносит пользу в конечный результат своей работы, например через коммуникацию – пойти с встречным предложением к фронтендерам, подробно расписать детали для тестировщиков на их языке, понять “кажись продакты странного хотят” и вытянуть из них недостающий контекст, с которым хотелка уже не кажется странной. На техническом плане хорошая лакмусовая бумажка – насколько знает о данных своего сервиса: объёмы, пропускную способность, профиль нагрузки и распределение оной между другими системами, с которыми взаимодействует его система.

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

Из технических аспектов - на этом уровне разработчик обязан знать все зависимости проекта:

  • Пакетные, причём как явные – перечисленные в pyproject.toml или где сейчас модно, так и транзитивные, а также причины фиксации версий и иметь представление в какой момент лучше тратить усилия на обновление (правильного ответа нет, имхо субъективщина, но ответ “не знаю” – точно неправильный).
  • Инфраструктурные – знать, где запущено приложение и его зависимости и как с этим работать – k8s, elk, Postgres с репликацией, pgbouncer и(ли) пулом коннектов, кластером redis или tarantool. Middle+ понимает, как приложение потребляет ресурсы, а самое главное – в курсе своих пробелов в знаниях.

Сеньор - самый странный из всех грейдов.

  • Сеньор делает меньше всего, потому что делегирует.
  • Сеньор подхватывает на себя менеджерские функции. Теоретически может занимать роль тимлида, техлида, проектного менеджера, в зависимости от того, что больше заходит, иногда заходит всё и сразу, но получается хреново и разрабатывалка отваливается
  • Платят ему за то, что он как минимум имеет какое-то представление, как его команде добиваться больших результатов с учётом имеющихся ограничений. Очень хорошо, если он при этом придаёт команде динамику – вкладывается в развитие других членов, атмосферу в коллективе, поднимает вопросы о найме недостающих людей. Советы тимлиду – уже вклад в команду.
  • Сеньор отладил умение считать деньги на реализацию хотелок и резонный встречный вопрос бизнесу – а что, реально стоит того?
  • Я идеализировал фразу о решении проблем Middle+, реально навыков для самостоятельного решения хватит на 70-80% таких проблем. Навыков сеньора навыков хватает уже для 90-95%.
  • У сеньора растёт акцент на коммуникацию за пределами своей команды – конструктивное общение со смежниками, которое даёт качественные улучшения результатов его проектов, а в идеале всех проектов предприятия.
  • Неопределённость уже не пугает. Сеньор спокойно выясняет информацию, если не может - заменяет на гипотезы и строит систему дальше.
  • За что сеньоры, не кочевавшие из компании в компанию могут просить на хлеб с двумя слоями масла – огроменный исторический контекст: человек, проработавший на одном месте больше трёх лет, помнит как всё устроено, поэтому его скорость принятия качественных решений на порядки больше, чем у человека со стороны.
  • Чтобы не держать совсем уж всё в памяти, может рисовать квадратики и вести документацию в первую очередь для самого себя, это уже должно войти в привычку, потому что ты дед, а память плохая. Привычкой оно становится не само по себе - боль от длительной IT-археологии, в которой выходишь в итоге на самого себя мучительна. Хороший маркер, что ваш миддл+ подрос – инициирует ведение документации, потому что задолбался жить в бардаке.
  • К слову о решениях – сеньор должен отвечать за свои решения. Обычно такое приходит с пониманием, что “мне же эту херню потом сопровождать” и не обязательно на этом грейде, бывают и вполне ответственные миддлы. Решение, избранное сеньором как правило жизнеспособно.
  • Одно из извечных решений – что делать с техдолгом. Можно записывать, игнорировать, устранять случайным образом, устранять системно, откладывать устранение постоянно или откладывать устранение иногда. Единственное неправильное решение здесь - отсутствие решения.

Сеньор+ и прочих архитекторов я пока не рассматриваю.

Так как растить сеньоров?

Возьмём миддл+ и подумаем. Как ему стать сеньором? Заняться тем, чего  ждут от сеньора. Если вы сам сеньор, отдайте ему куски своей работы.

  1. Дать ему возможность заниматься менеджерской работой. Постепенно, не сразу. Начните с увеличения работы с людьми, “сходить, договориться” со смежниками. 
  2. Дать ему возможность влиять на стратегию, хотя бы советами, хотя бы на уровне квартального планирования. Топ-N проблем для решения в этом году, топ-N фич, которые стоит продать бизнесу.
  3. Ставить перед ним вопросы развития команды. Пусть менторит хотя бы часть новичков, миддлов и так далее.
  4. Либо сопровождает сам, либо организует сопровождение. Все, кто старше него “по званию” должны спокойно уходить в отпуск, зная что если с сервисом что-то и случится, с ним разберутся. Проводите учебные инциденты, в которых он будет координатором, в крайнем случае – ждите 2-3 минуты с готовым решением, давая ему действовать самостоятельно.
  5. Просто дать поработать. Контекст сам по себе не наберётся. Если проект основной - потребуется минимум полгода для погружения через выполнение полезных бизнесу задач, а не сидеть полгода читать исходники и документацию. С побочными проектами сложнее: я за один год осилил один энтерпрайз проект на 40% по собственной оценке. Я не смог бы тянуть его в одного, но хотя бы разгрузил остальных ребят и таки нанёс пользы где смог. В идеале миддл+ должен самостоятельно составить себе план освоения проекта и выбирать задачи, балансируя между освоением нетронутого и нанесением пользы. С планом можно и помочь. На мой взгляд лучше не вводить ни поощрений, ни штрафов за соблюдение этого плана, но это вкусовщина.
  6. Рисовать квадратики в PlantUML или Mermaid, документировать непонятные куски проекта по мере решения задач, с валидацией “правильно ли я понял” через ревью в пулл-реквестах – тройная выгода: тёмные углы проекта освещаются, погружающийся получает обратную связь, задачи бизнеса продолжают решаться. Такая документация может быть кривой, косой и устаревать, но это лучше чем никакой документации.
  7. О решениях. Выделить ему зону ответственности в проектах, где он главный. Модуль, подсервис, кусок кода и так далее. Тесты тоже в каком-то роде модуль. В этой зоне он должен за полгода стать экспертом. В ней порядок, который он наводит вокруг должен быть особенно качественным, потому что он наводится с душой. Ну или с особой ответственностью за результаты своей работы. Должен же он чем-то гордиться?
  8. Процессы. Начать отвечать хотя бы за несколько процессов работы в команде и оптимизировать их. В идеале внедрить такой процесс. Можно банальщину - разбор постмортемов, PBR, актуализацию документации, автоматизацию работы поддержки. Те же алгоритмы, но исполняются людьми. В ещё большем идеале – внедрить по своей же инициативе, но адаптировать извне, если есть требования в компании - тоже хороший опыт. Здесь опять же прокачается навык коммуникации – слушать возражения коллег, искать компромиссы, продавать свою позицию.