Сложно быть Junior'ом10.02.2017 12:33

Мне действительно повезло — когда я впервые трудоустроился по профилю в 2010 году, я попал в хорошую компанию и работал рядом с профессионалами высокого уровня и просто хорошими людьми. Рядом с ними я быстро рос. Мне всегда показывали хорошие практики и действительно уделяли мне время.

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

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

• История, которую я слышал
• Что в ней не так
• Как это было со мной
• Краткий вывод

Если вопросов нет, то поехали.

История: начинающий разработчик, еще студент, устраивается в компанию и слышит от тимлида: «Эта задача делается за 8 часов. Завтра жду результат».

Что не так: слышать, что эта задача делается за N часов — это уже стресс, а в стрессовых условиях наш мозг работает хуже. Джуниор начинает паниковать сильнее, когда количество отработанных часов приближается к N. К тому же, что тимлидом делается за 8 часов, у джуниора может отобрать все 40.

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

Краткий вывод: нужно понимать, что вы взяли новичка. Ему нужно уделять время и понимать, что даже быстрые задачи порой занимают время.

История: начинающий разработчик получает задачу и выполняет ее. Тимлид, спустя какое-то время, видит написанный в рамках этой задачи код, тихо ругается и правит его. Закончив правки, он, довольный собой, коммитит его и забывает про все.

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

Как это было со мной: тимлид, после проверки моего кода, садился рядом и говорил: «Смотри, а вот что случится, если я передам этому методу пустую строку на вход?». И я тогда неуверенно отвечал: «NullPointerException?». Он соглашался и предлагал мне самому догадываться, как можно избежать этой ситуации. Обычно у нас не уходило более 5 минут на обсуждение, а потом он за следующие 5 минут подробно объяснял мне, что еще мне необходимо учесть. В итоге потрачено времени тимлида: 10 минут. Результат: стоит того.

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

История: схожа с историей из предыдущего пункта. Студент пишет код в рамках какой-то задачи, затем тимлид одним глазом и по диагонали смотрит на код и проверяет, что все работает. Затем дает студенту следующую задачу.

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

Как это было со мной: к сожалению, когда я начинал, эту практику не использовали очень активно на нашем проекте. Поэтому, тимлид тщательно сравнивал мой бранч с основным (тогда еще он назывался trunc (svn)), а затем подсаживался ко мне и говорил: «Смотри, а что случится, если…». Ну, а дальше вы уже знаете.

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

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

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

Ну, и всегда стоит помнить, что в сорванных сроках виноват не «тот джуниор, что долго копается в коде», а его тимлид.

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

• NorthDakota

  10 февраля 2017 в 11:42

  +1

  ↑

  ↓

  Ваша история полностью похожа на мою) За что я тимлиду благодарен!

• KotV4

  10 февраля 2017 в 12:22

  –1

  ↑

  ↓

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

  • tmn4jq

    10 февраля 2017 в 12:24

    0

    ↑

    ↓

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