Мне действительно повезло - когда я впервые устроился на работу по своей специальности в 2010 году, я оказался в хорошей компании и работал рядом с профессионалами высокого уровня и просто хорошими людьми.
Я быстро вырос рядом с ними.
Они всегда показывали мне хорошие практики и действительно уделяли мне время.
Но не всем так повезло – многие начинали свою карьеру в конторах достаточно среднего уровня, где их просто некому было учить.
Или я вообще не хотел.
Я просто хочу рассмотреть некоторые реальные случаи, которые я слышал о начинающих разработчиках, и сравнить их со своим собственным опытом.
Я рассмотрю всего 3 ситуации, каждая из которых будет состоять из 4 небольших частей:
- История, которую я услышал
- Что с этим не так
- Как это случилось со мной
- Краткое заключение
Ситуация 1: оценка времени, потраченного на задачу.
История : начинающий разработчик, еще студент, устраивается на работу в компанию и слышит от тимлида: «Эта задача выполнена за 8 часов.
Жду результата завтра».
В чем дело : услышать, что эта задача выполнена за N часов, уже стресс, а в стрессовых условиях наш мозг работает хуже.
Джуниор начинает паниковать сильнее, когда количество отработанных часов приближается к N. Более того, то, что тимлид делает за 8 часов, у юниора можно отобрать все 40. Как это случилось со мной : когда я немного освоился с проектом, мой тимлид попросил меня самостоятельно оценить задачи, и не просто назвать итоговую цифру, а подробно описать, куда было потрачено время.
Таким образом, он научил меня разлагать проблему на множество более мелких.
Он понимал, что юниору нельзя ставить суровые оценки сверху, но в то же время не позволял мне завышать затраты времени.
Он всегда просил меня обосновать, почему так произошло, и это обычно приводило к более адекватной оценке с моей стороны.
Краткое заключение : Вам нужно понимать, что вы взяли на работу новичка.
Ему нужно уделить время и понять, что даже быстрые задачи иногда требуют времени.
Ситуация 2: переписывание кода.
История : Новому разработчику дается задание и он его выполняет. Тимлид через какое-то время видит код, написанный в рамках этой задачи, тихо ругается и редактирует его.
Закончив правку, он, довольный собой, фиксирует ее и забывает обо всем.
В чем дело : Джуниор так и не понял, в чем именно заключалась его проблема.
После рефакторинга он видит даже отличный код, но с трудом его понимает. Руководитель команды последовательно тратит свое время на рефакторинг вместо того, чтобы тратить его на обучение своего падавана и выращивание сильного специалиста, которому даже через год потребуется гораздо меньше контроля.
Как это случилось со мной : тимлид, проверив мой код, сел рядом и сказал: «Посмотрите, а что будет, если я передам на вход этому методу пустую строкуЭ» И тогда я неуверенно ответил: «NullPointerExceptionЭ» Он согласился и предложил мне самому разобраться, как можно избежать этой ситуации.
Обычно мы тратили на это не более 5 минут, а затем следующие 5 минут он подробно объяснял мне, что еще мне нужно учитывать.
В результате время лидера команды было потеряно: 10 минут. Результат: оно того стоит. Краткое заключение : Обучайте своих подчиненных.
Если вы переписываете код новичка, объясните ему, почему это было сделано, и укажите на его ошибки.
Это позволит вам избежать этих ошибок и ненужного переписывания в будущем.
Ситуация 3: проверка кода.
Точнее, его отсутствие.
История : аналогично истории из предыдущего пункта.
Студент пишет код в рамках какого-то задания, затем тимлид смотрит на код одним глазом и по диагонали и проверяет, что всё работает. Затем дает ученику следующее задание.
В чем дело : Сложно учесть все изменения, просто бегло просмотрев бранч.
Кроме того, обзоры кода направлены именно на то, чтобы не пропустить плохой код, а также на обучение людей и указание на их ошибки.
И, конечно же, помочь им избавиться от этих косяков.
Как это случилось со мной : к сожалению, когда я начинал, на нашем проекте эта практика применялась не очень активно.
Поэтому тимлид внимательно сравнил мой бранч с основным (в то время он назывался trunc (svn)), а потом подсел ко мне и сказал: «Посмотри, что будет, если.
».
Ну, остальное вы уже знаете.
Краткое заключение : Всегда используйте всю мощь проверки кода.
Это не только предотвратит проникновение плохого кода в систему, но и поможет в удобной и понятной форме отобразить все проблемные места, объяснить юниору его недостатки и помочь ему их преодолеть.
Наставничество
Еще хочу сказать о такой полезной вещи, как наставничество.Вещь эта очень и очень хорошая, и переоценить ее преимущества действительно сложно.
Оно каким-то образом включает в себя все предыдущие пункты и многое другое.
Делитесь своими знаниями – рекомендуйте книги, отвечайте на вопросы и помогайте разобраться в мелочах.
В заключение
Длинные заключительные речи не подойдут, поэтому все просто — мотивируйте новичков достичь вершины и создайте для них дружескую атмосферу.Всем нравится работать в компаниях, которые ценят своих сотрудников, даже самых молодых.
Но через год-два эти молодые сотрудники станут достаточно опытными и смогут без дополнительного контроля приносить компании реальную пользу.
К тому же всегда приятно, когда кто-то перенимает твой опыт, и это помогает ему стать хоть в чём-то лучше.
Ну и всегда стоит помнить, что в сорванных сроках виноват не «тот джуниор, который долго копается в коде», а руководитель его команды.
Теги: #карьера программиста #обучение программированию #обучение программированию #Управление развитием #Управление персоналом #Карьера в IT-индустрии
-
$Mol: 4 Года Спустя
19 Oct, 24 -
Делаем Роутер И Nas На Одном Процессоре
19 Oct, 24 -
Google Критикует Мобильных Операторов
19 Oct, 24 -
Хабраобразование. Какой У Тебя Уровень?
19 Oct, 24
