Мне действительно повезло – когда я впервые трудоустроился по профилю в 2010 году, я попал в хорошую компанию и работал рядом с профессионалами высокого уровня и просто хорошими людьми. Рядом с ними я быстро рос. Мне всегда показывали хорошие практики и действительно уделяли мне время.
Но не всем так повезло – многие начинали свою карьеру в конторах довольно среднего уровня, где их попросту было некому учить. Или вовсе не хотелось.
Я хочу просто рассмотреть несколько реальных случаев из жизни начинающих разработчиков, которые я слышал, и сравнить эти случаи со своим опытом. Я рассмотрю всего 3 ситуации, каждая из которых будет состоять из 4 маленьких частей:
- История, которую я слышал
- Что в ней не так
- Как это было со мной
- Краткий вывод
Если вопросов нет, то поехали.
Ситуация 1: оценка временных трудозатрат на задачу.
История: начинающий разработчик, еще студент, устраивается в компанию и слышит от тимлида: “Эта задача делается за 8 часов. Завтра жду результат”.
Что не так: слышать, что эта задача делается за N часов – это уже стресс, а в стрессовых условиях наш мозг работает хуже. Джуниор начинает паниковать сильнее, когда количество отработанных часов приближается к N. К тому же, что тимлидом делается за 8 часов, у джуниора может отобрать все 40.
Как это было со мной: когда я немного освоился на проекте, мой тимлид просил меня самостоятельно оценивать задачи, причем не просто выдавать итоговую цифру, а подробно расписывать, куда уходит время. Таким образом он научил меня декомпозировать задачу на множество более мелких. Он понимал, что джуниору оценки не должны ставиться сверху в жесткой форме, но одновременно с этим он не давал мне завышать временные трудозатраты. Он всегда просил меня обосновать, почему именно так, и обычно это приводило к более адекватной оценке с моей стороны.
Краткий вывод: нужно понимать, что вы взяли новичка. Ему нужно уделять время и понимать, что даже быстрые задачи порой занимают время.
Ситуация 2: переписывание кода.
История: начинающий разработчик получает задачу и выполняет ее. Тимлид, спустя какое-то время, видит написанный в рамках этой задачи код, тихо ругается и правит его. Закончив правки, он, довольный собой, коммитит его и забывает про все.
Что не так: джуниор так и не понял, в чем именно был его косяк. После рефакторинга он видит пусть даже превосходный код, но он в нем едва ли разберется. Тимлид стабильно тратит свое время на рефакторинг вместо того, чтобы потратить его на обучение своего падавана и выращивание сильного специалиста, который даже через год уже будет требовать гораздо меньшего контроля.
Как это было со мной: тимлид, после проверки моего кода, садился рядом и говорил: “Смотри, а вот что случится, если я передам этому методу пустую строку на вход?”. И я тогда неуверенно отвечал: “NullPointerException?”. Он соглашался и предлагал мне самому догадываться, как можно избежать этой ситуации. Обычно у нас не уходило более 5 минут на обсуждение, а потом он за следующие 5 минут подробно объяснял мне, что еще мне необходимо учесть. В итоге потрачено времени тимлида: 10 минут. Результат: стоит того.
Краткий вывод: Обучайте своих подчиненных. Если вы переписываете код новичка, объясните ему, зачем это было сделано и укажите на его ошибки. Это позволит в дальнейшем избежать этих ошибок и лишнего переписывания.
Ситуация 3: code-review. Точнее, его отсутствие.
История: схожа с историей из предыдущего пункта. Студент пишет код в рамках какой-то задачи, затем тимлид одним глазом и по диагонали смотрит на код и проверяет, что все работает. Затем дает студенту следующую задачу.
Что не так: сложно учесть все изменения, лишь бегло просмотрев бранч. К тому же, код ревью как раз и нацелено на то, чтобы не пропускать плохой код, а также обучать людей и указывать на их косяки. И, конечно же, помогать им от этих косяков избавляться.
Как это было со мной: к сожалению, когда я начинал, эту практику не использовали очень активно на нашем проекте. Поэтому, тимлид тщательно сравнивал мой бранч с основным (тогда еще он назывался trunc (svn)), а затем подсаживался ко мне и говорил: “Смотри, а что случится, если…”. Ну, а дальше вы уже знаете.
Краткий вывод: всегда используйте всю силу code review. Это не только не позволит плохому коду закрасться в систему, но и в удобной и понятной форме поможет отобразить все проблемные места, объяснить джуниору его косяки и помочь ему их преодолеть.
Менторинг
Еще хочу сказать о такой полезной штуке, как менторинг. Вещь эта весьма и весьма хорошая, и действительно трудно переоценить его пользу. Он так или иначе включает в себя все предыдущие пункты и не только. Делитесь знаниями – рекомендуйте книги, отвечайте на вопросы и помогайте разобраться в мелочах.
В качестве заключения
Длинных заключительных речей не получится, поэтому просто – мотивируйте новичков на достижение вершин и дарите им дружественную атмосферу. Всем приятно работать в компаниях, которые ценят своих сотрудников, пусть даже еще самых молодых. Но эти молодые сотрудники спустя год-другой станут уже довольно матерыми и смогут без дополнительного контроля приносить реальную пользу компании. К тому же, всегда приятно, когда кто-то перенимает твой опыт, и это помогает ему стать хоть в чем-то лучше.
Ну, и всегда стоит помнить, что в сорванных сроках виноват не “тот джуниор, что долго копается в коде”, а его тимлид.
Комментарии (34)
KotV4
10.02.2017 12:22+2Чет инфы совсем с гулькин нос :(
В работе джуна гораздо больше подводных камней, а читая ваш пост, создается впечатление что кроме вас (джуна) и тимлида вообще никого нет.
tmn4jq
10.02.2017 12:24+3Так я не ставил целью описать еще одну аджайл модель. В том и смысл, чтобы изолировать работу ученика и учителя, рассмотреть именно эту грань отношений в команде
KotV4
10.02.2017 12:59+1В том и смысл, чтобы изолировать работу ученика и учителя, рассмотреть именно эту грань отношений в команде
Но эта грань гораздо шире чем те три рассматриваемые вами ситуации. Вы описали небольшую часть очевидных вещей. Код ревью быть должен, оценивать трудозатраты надо и закладывать время про запас тоже. Переписывание кода? Не очень удачное название для второго пункта из которого вы делаете вывод об обучении. Да и тимлид вполне может поручить мидлу, например, помогать вам в работе, на первых парах, конечно же, если мидл есть в команде.
И как уже заметили, есть разница между СНГ-джуном и США-джуном. В какой компании вы работаете и какой продукт производите/поддерживаете. Удаленно ли или в офисе.
В общем, слишком много неописанных переменных в рассмотренных вами ситуациях.tmn4jq
10.02.2017 13:24+3Все как обычно
KotV4
10.02.2017 13:37-5Не считаю необходимой дальнейшие обсуждения и наставления меня на путь истинный. Это мои мысли и мой опыт, пусть это и кажется очевидным для кого-то.
О как! Сколько гонору.
Дело в том, что Хабр это не ваш личный дневник. Вы рассматриваете небольшую часть СОВСЕМ очевидных вещей в отрыве от… ну хоть какой то общей картины процесса работы. Т.е. это даже не уровень «Нужно делать бэкапы».
Вы тоже говорите об очевидных вещах.
Вывод в одном предложении по рассмотренным вами ситуациям.tmn4jq
10.02.2017 14:18+2> Дело в том, что Хабр это не ваш личный дневник
Как и не ваш.
Давайте просто остановимся на том, что я поделился своими мыслями по поводу конкретных ситуаций, а вы, к сожалению, не увидели в этом посте того, что хотели увидеть.
lookid
10.02.2017 12:39-13Сложно быть не джуниором, а СНГ-джуниором. Джуниоры в США сравнимы с нашими мидлами, а иногда даже с синьерами. Стажеры и джуниоры в big-4 пишут по 1к строк кода в неделю и успешно учатствуют в спринтах, эстимациях и прочем. Тот же гугл может нанять джуниора и дать ему полноценную задачу на 3-4 месяца летней стажировки. У нас же брать джуниоров это протягивать руку помощи неимущим. У нас даже мидлы не могут решить задачку на листочке без подсказок своей головой. "Решить задачку на листочке мерило навыков?" Да, мерило. Мерило навыков программирования без ошибок и решения абстрактных задач. Технологии тут не имеют значения. Наклепать 100 сайтов в год это одно. А саппортить продукт, которые разрабатывается 10 лет и все эти 10 лет в полете — другое. Память есть у всех, руки не у всех.
tmn4jq
10.02.2017 13:19+2Не люблю рассуждать в стиле «там – хорошо, у нас – плохо». Ничто не мешает сделать хорошо и здесь. И я как раз описал 3 ситуации, которые, по моему мнению, в некоторых компаниях нуждаются в улучшении.
По поводу «крутых западных разрабов» – я работал с ними и читал их код. Поверьте, от локации мало что зависит, бывает и с запада приходит говнокод.
superyateam
11.02.2017 13:49+2последний раз я слышал, чтобы качество работы оценивали в количестве строк кода, было лет 10 назад.
чтобы показать бредовость такой оценки, можно взять к примеру PostgresSQL (775 000 строк кода — отсюда). Получается, команда из 15 джуниоров напишет эту СУБД за год. Удачи, как говорится.
Остальное, тоже ерунда какая-то. Говнокод пишут, как в России, так и в США и Индии. Ну да, в вашей Big 4, качество джуниоров не сравнимо со студией, лабающей сайты, из какого-нибудь Петрозаводска (ничего личного против жителей Петрозаводска не имею, просто маленький город, как пример). Ну так сравнивайте тогда, Гугл и Яндекс, Амазон и VK.com — туда победителей олимпиад только берут. Сами-то туда сможете собеседование пройти?
asv4
11.02.2017 13:50По моему, у нас «брать джуниоров» в 90% случаев означает «нам нужен программист для решения наших задач, но платить по рынку мы ему не хотим или не можем». Поэтому мы напишем, что готовы рассмотреть человека без опыта, и довольно укажем минимальную ставку оплаты, при этом требуя вполне себе стандартный стек технологий.
Кинем человека на задачи, не заморачиваясь, как и что он делает, главное чтобы работало.
В итоге за полгода-год на проекте нарастет приличное количество говнокода, которое потом придется разгребать уже следующему, пришедшему на смену нашему джуниору разработчику, потому что джуниор через год свалит на нормальную зарплату, осознав, что на этой работе ему изначально платить по рынку никто не собирался.
nadya_ceban
13.02.2017 12:48Не во всех компаниях СНГ такой уровень джуниоров, в компании где работаю чтобы попасть на должность джуниора, пришлось пройти через практику и стажировку, на которых как раз и происходило все описанное в статье, а джуниор это уже вполне квалифицированный разработчик.
ls18
10.02.2017 14:01+1Напишу свою историю Junior'а:
3 года назад закончил технарь по IT специальности. Кое-какие обрывистые знания помогли мне устроиться в местную маленькую фирму, которая занимается разработкой и поддержкой корпоративного и учетного ПО на Oracle. В мои обязанности входила и разработка и тех. поддержка этих самых продуктов (а если быть точнее, то я сидел на биллинге ЖКХ). В мои обязанности входили разработка бизнес-логики и отчетов на PL/SQL. В принципе было почти так же, как в статье, т.е. более опытный «тимлид» подсказывал, бил по рукам. И в начале на относительно простые задачи я тратил очень много времени, а потраченное время нужно было указывать в task системе. Не сказать, что я получил там бесценные знания, т.к. в работе зачастую использовались простые кострукции, но все же за полученный опыт я благодарен. Проработал я там примерно 1 год и 9 месяцев, достаточно тяжело было работать на позиции тех. поддержки и разработчика одновременно, да еще и ездить в командировки на «внедрения»(обучение пользователей работе с ПО). Ушел оттуда в никуда и полгода сидел без работы, пока не устроился junior php developer в торговую компанию. И здесь опять тот же путь, как и на прошлом месте работы :) Опять так же туплю в новой области, трачу много времени на относительно простые задания, но спасибо ведущему разработчику, пока терпит меня :) Если есть вопросы, то готов ответить…
KeMik
10.02.2017 14:16+2Спасибо за статью. Все выше перечисленные ошибки совершал мой лид когда я работал ещё на первом проекте.
Ну, и всегда стоит помнить, что в сорванных сроках виноват не “тот джуниор, что долго копается в коде”, а его тимлид.
Собственно это и стало причиной моего ухода из той компании.
Сейчас, после восьми лет работы, когда я сам уже стал лидом, стараюсь не наступать на эти грабли и это действительно дает свой результат. Я действительно горжусь своей командой.
Единственная ремарка, порой лида тоже ставят в жесткие рамки, и времени долго сидеть с джунами просто нет, менеджеру ведь нужен результат в короткие сроки
xcore78
10.02.2017 17:27+1Спасибо за статью.
Собственно, опыт конвертируем на все IT-специальности, его применимость не ограничивается разработкой.
boblenin
10.02.2017 18:04+3Он понимал, что джуниору оценки не должны ставиться сверху в жесткой форме, но одновременно с этим он не
давал мне завышать временные трудозатраты.Оценки сверху не должны ставиться не только джуниору. Если тимлид назначает оценку, то он и является ответственным лицом за любой срыв сроков по задаче. Задача тимлида — получить оценку от разработчика (жунивора или сенивора) и сравнить ее со своей внутренней. Если есть расхождение в любую сторону — обсудить и выяснить детали.
Тимлид, спустя какое-то время, видит написанный в рамках этой задачи код, тихо ругается и
правит его.Код разработаный разработчиком как джунивором так и сенивором — это их зона ответственности. Просматривать код должен не только тимлид и не столько он, сколько другие члены комманды (им потом придется с этим кодом работать). Они должны давать рекоммендации, а тот кто не прошел ревью — должен вносить правки (wipe your own ..s).
В целом я так понимаю статья больше о проблемах juinor тим лида, чем девелопера. Человек уже получил должность, но еще не понял в чем ее суть.
tmn4jq
10.02.2017 18:28Про просмотр кода и ревью я как раз и говорю, и я с вами согласен.
В целом я так понимаю статья больше о проблемах juinor тим лида, чем девелопера. Человек уже получил должность, но еще не понял в чем ее суть.
Думаю, можно и так сказать. Это не стататья по сути, а просто небольшая попытка анализа ситуаций, о которых я слышал. К сожалению, вокруг полно ИТ-контор, которые думают лишь о прибыли, а не о взаимовыгодном сотрудничестве. И там зачастую пребывают такие-вот «тим-лиды».boblenin
10.02.2017 19:00+2К сожалению, вокруг полно ИТ-контор, которые думают лишь о прибыли, а не о взаимовыгодном
сотрудничестве. И там зачастую пребывают такие-вот «тим-лиды».Не согласен. Там где думают о прибыли — умеют считать. Тимлид переписывающий код за джуниором — это:
- Два человека делают работу одного
- Более дорогой ресурс делает работу более дешевого
- Тимлид делая работу разработчика крадет время из своих непосредственных задач либо не отдыхает — снижает свою эфективность
Обычно позицию создают тогда, когда знают что человек будет 100% времени занят, может конечно быть что тимлида назначили с рассчетом на будующий рост, тогда такая ситуация может быть относительно терпимой.
tmn4jq
10.02.2017 19:12Ну вот если бы все тимлиды имели мышление, схожее с вашим, данного поста бы не было.
Но увы, ситуации, описанные здесь, так или иначе имеют место быть.
BalinTomsk
10.02.2017 23:32----Смотри, а вот что случится, если я передам этому методу пустую строку на вход?
Массу подобных вопросов можно было снять написав юнит -тесты — они хорошо дисциплинируют в написании понятного кода.
VMichael
11.02.2017 00:40Кто напишет такие тесты для задач, которые пишет джуниор?
Если бы мысль о пустой строке на входе посетила джуниора, он бы это сразу обработал.
А если мысль не посетила, то он и тест на это не напишет.BalinTomsk
11.02.2017 00:57+1Как кто? Каждый девелопер должен писать тесты на свой код.
Особенно на проверку входных параметров.VMichael
11.02.2017 01:06Вы весь мой комментарий читали или первую строку только?
Повторю:
Если бы мысль о пустой строке на входе посетила джуниора, он бы это сразу обработал.
А если мысль не посетила, то он и тест на это не напишет.BalinTomsk
11.02.2017 01:37Вы когда нибудь тесты писали?
Первым делом это надо было обяснять юниору что такое юнит тесты и что входные параметры надо проверять на весь входной диапазон, еще до того как давать любые задания.
tmn4jq
12.02.2017 20:12Можно перефразировать.
Джуниор написал кусок функциональности и юнит-тесты к ней, но не учел возможность NPE по неопытности, соответстенно и теста данного нет. И тимлид предлагает ему данный тест дописать, заодно показав на косячный момент и заставив писать тесты с учетом различных сценариев. Суть не меняется.
AIxray
12.02.2017 21:12В жизни абсолютно такая же ситуация и встречается сплошь и рядом. Разберём типовую ситуацию: в хорошей и при условии, что каждый член семьи воспитан с детства; с самого детства мальчика/девочку мать забирает с садика одевают обувь(с 2 лет как правило) и ухаживает/направляет при определённых ситуациях, далее ситуация располагает следующим образом, те повзрослевшие мальчик/девочка ухаживают за старенькой матерью — помогают одевать также обувь(как правило с 90 лет), приобретут лекарства, сводят в баню то есть понятно должный и своевременный оказывается уход.
Это и есть воспитание. И так или иначе внутри «системы» мы берём на себя обязательства в воспитании другого человека что делать? Представить, что человек родной; либо изначально необходимо было выстраивать своё предприятие со своими близкими.
Но как показывает практика, лучше взаимодействовать со случайными людьми внутри системы, т.к. с родственниками бывают неурядицы.
Да и не стоит забывать, что Россияне пользовались и пользуются западными технологиями(не своё генерируют, а улучшают на имеющейся основе). Учить и ещё раз учить историю.
NorthDakota
Ваша история полностью похожа на мою) За что я тимлиду благодарен!