Это цикл статей. Следующую можно прочесть тут

Что ожидать и как помогать расти разработчику из trainee в уверенного junior?

Уровень разработчика — то чем все привыкли меряться и то за чем все перебегают из компании в компанию.

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

Эта тема меня беспокоит особенно сильно по той причине, что годы опыта все таки кое о чем говорят. Говорят они о количестве времени, во время которого ты работал работу. И чисто статистически верно то, что за m времени может произойти больше факапов и запар, чем за n, при условии что m > n. Вот и все. Об этом говорят года опыта. Это не тот показатель, по которому я буду отсеивать людей с позиций (буду если это сеньор, с 1.5 годами реального опыта), но тот, по которому я буду решать между двумя идентичными кандидатами, если не смогу взять двух.

Так вот, мой любимый тип разработчика — trainee. Это совсем начинающие ребята, не важно какой у них возраст_пол_вероисповедание, по ним с первого дня видно, горят ли у них глаза. Дальше дело техники, как говорит один мой хороший друг: "код можно научить писать и обезьяну", и мы учим… не обезьяну, конечно… а человека. Учим, рассказываем, выгоняем с работы, когда засиживаются, а они любят засиживаться, потому что интересно все. На этом этапе задача разработчика научиться работать с инструментами, понять что вода мокрая, огонь горячий, а стендап от слова "стоять". В каждом языке есть типовое задание. В руби — Хартл и его ака "твиттер". В javascript все дико любят туду листы и всевозможные реализации под тот фреймворк с которым ты работаешь. Если он может это написать по step-by-step гайду, он подходит на трейни. Когда он сможет написать его без step-by-step гайда, можно поговорить про джуна. Я специально сделал здесь упор на step-by-step, потому что не важно сколько у тебя опыта, ты будешь бегать на MDN смотреть порядок параметров в reduce и забывать базовые конструкции.

Дальше Junior — и тут нет резкого перехода. Он плавный. И именно поэтому у нас в компании сделано разделение на Junior Beginner/Junior/Junior Strong. Но это этап, на котором вы можете сразу увидеть, какова культура в вашей команде, я закончу этой мыслью раздел про Junior.

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

Помогать ему задумываться и разбираться в том, с чем имеет дело большую часть времени. То есть если он пол дня шлет запросы из браузера на бекенд, то разберался, что такое запрос и почему браузер шлет 2 запроса, когда у тебя бекенд на другом Origin. Он начинает осознавать процессы в разработке. Постепенно замечает, насколько он ошибается в оценках.
Это тот этап, когда стоит поиграть с человеком в скрам покер и сделать top-down оценку задачи, даже если у вас это не принято в команде.

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

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

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

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

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

Заканчивая описывать Junior`a, вернемся к культуре команды. На этом уровне человек будет впитывать культуру коммуникации команды, если вы шеймите тестировщиков и считаете их бесполезными, но не отдаете себе в этом отчета, взгляните на джуна и вспомните, был ли он таким пол года/год назад. Вел ли он себя так же по отношению к этим людям? Если "нет" в негативную сторону, то вот вам и звоночек. Он научился этому у вас и вашего окружения. Он еще не может четко сказать, почему что-то не важно, но уже это шеймит. Тем более что все мы уже знаем, каждый этап в разработке приложения важен и какой бы ни была команда, без тестировщика они выпустят продукт хуже или медленнее и дороже.

Изначально я опубликовал статью на Medium, но мне кажется для сегмента, с которым я хочу начать разговор — это плохая площадка. Я опущу часть интро, если хотите пообщаться пишите на @_golubev.

Я дал этой рубрике название work&dev fun(damentals). Потому что работа и разработка — это весело. Но надо учиться фундаментальным вещам. Не важно софт скилы это или хард скилы.
Все, далее описанное, это тот опыт который я приобрел. Он ограничен моим пониманием вещей, происходящих в IT. Процессов, которые тут происходят. Решений, которые принимаются. Это понимание позволило мне из Trainee в в одного их лидов Full-stack направления. Параллельно создать отдел, который специализируется на техническом развитии и мониторинге эмоционального состояния сотрудников, для того, чтобы сделать их работу комфортной и обеспечить их конкретным пониманием того, что именно от них ожидают в компании и проекте.