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