Мне действительно повезло – когда я впервые трудоустроился по профилю в 2010 году, я попал в хорошую компанию и работал рядом с профессионалами высокого уровня и просто хорошими людьми. Рядом с ними я быстро рос. Мне всегда показывали хорошие практики и действительно уделяли мне время.
Но не всем так повезло – многие начинали свою карьеру в конторах довольно среднего уровня, где их попросту было некому учить. Или вовсе не хотелось.
Я хочу просто рассмотреть несколько реальных случаев из жизни начинающих разработчиков, которые я слышал, и сравнить эти случаи со своим опытом. Я рассмотрю всего 3 ситуации, каждая из которых будет состоять из 4 маленьких частей:
- История, которую я слышал
- Что в ней не так
- Как это было со мной
- Краткий вывод
Если вопросов нет, то поехали.
Ситуация 1: оценка временных трудозатрат на задачу.
История: начинающий разработчик, еще студент, устраивается в компанию и слышит от тимлида: “Эта задача делается за 8 часов. Завтра жду результат”.
Что не так: слышать, что эта задача делается за N часов – это уже стресс, а в стрессовых условиях наш мозг работает хуже. Джуниор начинает паниковать сильнее, когда количество отработанных часов приближается к N. К тому же, что тимлидом делается за 8 часов, у джуниора может отобрать все 40.
Как это было со мной: когда я немного освоился на проекте, мой тимлид просил меня самостоятельно оценивать задачи, причем не просто выдавать итоговую цифру, а подробно расписывать, куда уходит время. Таким образом он научил меня декомпозировать задачу на множество более мелких. Он понимал, что джуниору оценки не должны ставиться сверху в жесткой форме, но одновременно с этим он не давал мне завышать временные трудозатраты. Он всегда просил меня обосновать, почему именно так, и обычно это приводило к более адекватной оценке с моей стороны.
Краткий вывод: нужно понимать, что вы взяли новичка. Ему нужно уделять время и понимать, что даже быстрые задачи порой занимают время.
Ситуация 2: переписывание кода.
История: начинающий разработчик получает задачу и выполняет ее. Тимлид, спустя какое-то время, видит написанный в рамках этой задачи код, тихо ругается и правит его. Закончив правки, он, довольный собой, коммитит его и забывает про все.
Что не так: джуниор так и не понял, в чем именно был его косяк. После рефакторинга он видит пусть даже превосходный код, но он в нем едва ли разберется. Тимлид стабильно тратит свое время на рефакторинг вместо того, чтобы потратить его на обучение своего падавана и выращивание сильного специалиста, который даже через год уже будет требовать гораздо меньшего контроля.
Как это было со мной: тимлид, после проверки моего кода, садился рядом и говорил: “Смотри, а вот что случится, если я передам этому методу пустую строку на вход?”. И я тогда неуверенно отвечал: “NullPointerException?”. Он соглашался и предлагал мне самому догадываться, как можно избежать этой ситуации. Обычно у нас не уходило более 5 минут на обсуждение, а потом он за следующие 5 минут подробно объяснял мне, что еще мне необходимо учесть. В итоге потрачено времени тимлида: 10 минут. Результат: стоит того.
Краткий вывод: Обучайте своих подчиненных. Если вы переписываете код новичка, объясните ему, зачем это было сделано и укажите на его ошибки. Это позволит в дальнейшем избежать этих ошибок и лишнего переписывания.
Ситуация 3: code-review. Точнее, его отсутствие.
История: схожа с историей из предыдущего пункта. Студент пишет код в рамках какой-то задачи, затем тимлид одним глазом и по диагонали смотрит на код и проверяет, что все работает. Затем дает студенту следующую задачу.
Что не так: сложно учесть все изменения, лишь бегло просмотрев бранч. К тому же, код ревью как раз и нацелено на то, чтобы не пропускать плохой код, а также обучать людей и указывать на их косяки. И, конечно же, помогать им от этих косяков избавляться.
Как это было со мной: к сожалению, когда я начинал, эту практику не использовали очень активно на нашем проекте. Поэтому, тимлид тщательно сравнивал мой бранч с основным (тогда еще он назывался trunc (svn)), а затем подсаживался ко мне и говорил: “Смотри, а что случится, если…”. Ну, а дальше вы уже знаете.
Краткий вывод: всегда используйте всю силу code review. Это не только не позволит плохому коду закрасться в систему, но и в удобной и понятной форме поможет отобразить все проблемные места, объяснить джуниору его косяки и помочь ему их преодолеть.
Менторинг
Еще хочу сказать о такой полезной штуке, как менторинг. Вещь эта весьма и весьма хорошая, и действительно трудно переоценить его пользу. Он так или иначе включает в себя все предыдущие пункты и не только. Делитесь знаниями – рекомендуйте книги, отвечайте на вопросы и помогайте разобраться в мелочах.
В качестве заключения
Длинных заключительных речей не получится, поэтому просто – мотивируйте новичков на достижение вершин и дарите им дружественную атмосферу. Всем приятно работать в компаниях, которые ценят своих сотрудников, пусть даже еще самых молодых. Но эти молодые сотрудники спустя год-другой станут уже довольно матерыми и смогут без дополнительного контроля приносить реальную пользу компании. К тому же, всегда приятно, когда кто-то перенимает твой опыт, и это помогает ему стать хоть в чем-то лучше.
Ну, и всегда стоит помнить, что в сорванных сроках виноват не “тот джуниор, что долго копается в коде”, а его тимлид.
