Comments 35
Ваша история полностью похожа на мою) За что я тимлиду благодарен!
Чет инфы совсем с гулькин нос :(
В работе джуна гораздо больше подводных камней, а читая ваш пост, создается впечатление что кроме вас (джуна) и тимлида вообще никого нет.
В работе джуна гораздо больше подводных камней, а читая ваш пост, создается впечатление что кроме вас (джуна) и тимлида вообще никого нет.
Так я не ставил целью описать еще одну аджайл модель. В том и смысл, чтобы изолировать работу ученика и учителя, рассмотреть именно эту грань отношений в команде
В том и смысл, чтобы изолировать работу ученика и учителя, рассмотреть именно эту грань отношений в команде
Но эта грань гораздо шире чем те три рассматриваемые вами ситуации. Вы описали небольшую часть очевидных вещей. Код ревью быть должен, оценивать трудозатраты надо и закладывать время про запас тоже. Переписывание кода? Не очень удачное название для второго пункта из которого вы делаете вывод об обучении. Да и тимлид вполне может поручить мидлу, например, помогать вам в работе, на первых парах, конечно же, если мидл есть в команде.
И как уже заметили, есть разница между СНГ-джуном и США-джуном. В какой компании вы работаете и какой продукт производите/поддерживаете. Удаленно ли или в офисе.
В общем, слишком много неописанных переменных в рассмотренных вами ситуациях.
Все как обычно
С удовольствием прочитал бы ваши мысли в вашей статье. А здесь я не могу написать то, что у каждого читателя в голове, здесь лишь мои мысли, и я делаю акцент именно на там, на чем считаю нужным.
Я еще раз повторю, я не ставлю целью описать полностью очередную аджайл модель. Я не против того, чтобы говорить об очевидных вещах, потому что почему-то их много где не замечают.
> Код ревью быть должен, оценивать трудозатраты надо и закладывать время про запас тоже.
Вы тоже говорите об очевидных вещах.
Не считаю необходимой дальнейшие обсуждения и наставления меня на путь истинный. Это мои мысли и мой опыт, пусть это и кажется очевидным для кого-то.
Не считаю необходимой дальнейшие обсуждения и наставления меня на путь истинный. Это мои мысли и мой опыт, пусть это и кажется очевидным для кого-то.
О как! Сколько гонору.
Дело в том, что Хабр это не ваш личный дневник. Вы рассматриваете небольшую часть СОВСЕМ очевидных вещей в отрыве от… ну хоть какой то общей картины процесса работы. Т.е. это даже не уровень «Нужно делать бэкапы».
Вы тоже говорите об очевидных вещах.
Вывод в одном предложении по рассмотренным вами ситуациям.
Сложно быть не джуниором, а СНГ-джуниором. Джуниоры в США сравнимы с нашими мидлами, а иногда даже с синьерами. Стажеры и джуниоры в big-4 пишут по 1к строк кода в неделю и успешно учатствуют в спринтах, эстимациях и прочем. Тот же гугл может нанять джуниора и дать ему полноценную задачу на 3-4 месяца летней стажировки. У нас же брать джуниоров это протягивать руку помощи неимущим. У нас даже мидлы не могут решить задачку на листочке без подсказок своей головой. "Решить задачку на листочке мерило навыков?" Да, мерило. Мерило навыков программирования без ошибок и решения абстрактных задач. Технологии тут не имеют значения. Наклепать 100 сайтов в год это одно. А саппортить продукт, которые разрабатывается 10 лет и все эти 10 лет в полете — другое. Память есть у всех, руки не у всех.
Не люблю рассуждать в стиле «там – хорошо, у нас – плохо». Ничто не мешает сделать хорошо и здесь. И я как раз описал 3 ситуации, которые, по моему мнению, в некоторых компаниях нуждаются в улучшении.
По поводу «крутых западных разрабов» – я работал с ними и читал их код. Поверьте, от локации мало что зависит, бывает и с запада приходит говнокод.
По поводу «крутых западных разрабов» – я работал с ними и читал их код. Поверьте, от локации мало что зависит, бывает и с запада приходит говнокод.
последний раз я слышал, чтобы качество работы оценивали в количестве строк кода, было лет 10 назад.
чтобы показать бредовость такой оценки, можно взять к примеру PostgresSQL (775 000 строк кода — отсюда). Получается, команда из 15 джуниоров напишет эту СУБД за год. Удачи, как говорится.
Остальное, тоже ерунда какая-то. Говнокод пишут, как в России, так и в США и Индии. Ну да, в вашей Big 4, качество джуниоров не сравнимо со студией, лабающей сайты, из какого-нибудь Петрозаводска (ничего личного против жителей Петрозаводска не имею, просто маленький город, как пример). Ну так сравнивайте тогда, Гугл и Яндекс, Амазон и VK.com — туда победителей олимпиад только берут. Сами-то туда сможете собеседование пройти?
чтобы показать бредовость такой оценки, можно взять к примеру PostgresSQL (775 000 строк кода — отсюда). Получается, команда из 15 джуниоров напишет эту СУБД за год. Удачи, как говорится.
Остальное, тоже ерунда какая-то. Говнокод пишут, как в России, так и в США и Индии. Ну да, в вашей Big 4, качество джуниоров не сравнимо со студией, лабающей сайты, из какого-нибудь Петрозаводска (ничего личного против жителей Петрозаводска не имею, просто маленький город, как пример). Ну так сравнивайте тогда, Гугл и Яндекс, Амазон и VK.com — туда победителей олимпиад только берут. Сами-то туда сможете собеседование пройти?
По моему, у нас «брать джуниоров» в 90% случаев означает «нам нужен программист для решения наших задач, но платить по рынку мы ему не хотим или не можем». Поэтому мы напишем, что готовы рассмотреть человека без опыта, и довольно укажем минимальную ставку оплаты, при этом требуя вполне себе стандартный стек технологий.
Кинем человека на задачи, не заморачиваясь, как и что он делает, главное чтобы работало.
В итоге за полгода-год на проекте нарастет приличное количество говнокода, которое потом придется разгребать уже следующему, пришедшему на смену нашему джуниору разработчику, потому что джуниор через год свалит на нормальную зарплату, осознав, что на этой работе ему изначально платить по рынку никто не собирался.
Кинем человека на задачи, не заморачиваясь, как и что он делает, главное чтобы работало.
В итоге за полгода-год на проекте нарастет приличное количество говнокода, которое потом придется разгребать уже следующему, пришедшему на смену нашему джуниору разработчику, потому что джуниор через год свалит на нормальную зарплату, осознав, что на этой работе ему изначально платить по рынку никто не собирался.
Не во всех компаниях СНГ такой уровень джуниоров, в компании где работаю чтобы попасть на должность джуниора, пришлось пройти через практику и стажировку, на которых как раз и происходило все описанное в статье, а джуниор это уже вполне квалифицированный разработчик.
Напишу свою историю Junior'а:
3 года назад закончил технарь по IT специальности. Кое-какие обрывистые знания помогли мне устроиться в местную маленькую фирму, которая занимается разработкой и поддержкой корпоративного и учетного ПО на Oracle. В мои обязанности входила и разработка и тех. поддержка этих самых продуктов (а если быть точнее, то я сидел на биллинге ЖКХ). В мои обязанности входили разработка бизнес-логики и отчетов на PL/SQL. В принципе было почти так же, как в статье, т.е. более опытный «тимлид» подсказывал, бил по рукам. И в начале на относительно простые задачи я тратил очень много времени, а потраченное время нужно было указывать в task системе. Не сказать, что я получил там бесценные знания, т.к. в работе зачастую использовались простые кострукции, но все же за полученный опыт я благодарен. Проработал я там примерно 1 год и 9 месяцев, достаточно тяжело было работать на позиции тех. поддержки и разработчика одновременно, да еще и ездить в командировки на «внедрения»(обучение пользователей работе с ПО). Ушел оттуда в никуда и полгода сидел без работы, пока не устроился junior php developer в торговую компанию. И здесь опять тот же путь, как и на прошлом месте работы :) Опять так же туплю в новой области, трачу много времени на относительно простые задания, но спасибо ведущему разработчику, пока терпит меня :) Если есть вопросы, то готов ответить…
3 года назад закончил технарь по IT специальности. Кое-какие обрывистые знания помогли мне устроиться в местную маленькую фирму, которая занимается разработкой и поддержкой корпоративного и учетного ПО на Oracle. В мои обязанности входила и разработка и тех. поддержка этих самых продуктов (а если быть точнее, то я сидел на биллинге ЖКХ). В мои обязанности входили разработка бизнес-логики и отчетов на PL/SQL. В принципе было почти так же, как в статье, т.е. более опытный «тимлид» подсказывал, бил по рукам. И в начале на относительно простые задачи я тратил очень много времени, а потраченное время нужно было указывать в task системе. Не сказать, что я получил там бесценные знания, т.к. в работе зачастую использовались простые кострукции, но все же за полученный опыт я благодарен. Проработал я там примерно 1 год и 9 месяцев, достаточно тяжело было работать на позиции тех. поддержки и разработчика одновременно, да еще и ездить в командировки на «внедрения»(обучение пользователей работе с ПО). Ушел оттуда в никуда и полгода сидел без работы, пока не устроился junior php developer в торговую компанию. И здесь опять тот же путь, как и на прошлом месте работы :) Опять так же туплю в новой области, трачу много времени на относительно простые задания, но спасибо ведущему разработчику, пока терпит меня :) Если есть вопросы, то готов ответить…
Спасибо за статью. Все выше перечисленные ошибки совершал мой лид когда я работал ещё на первом проекте.
Ну, и всегда стоит помнить, что в сорванных сроках виноват не “тот джуниор, что долго копается в коде”, а его тимлид.
Собственно это и стало причиной моего ухода из той компании.
Сейчас, после восьми лет работы, когда я сам уже стал лидом, стараюсь не наступать на эти грабли и это действительно дает свой результат. Я действительно горжусь своей командой.
Единственная ремарка, порой лида тоже ставят в жесткие рамки, и времени долго сидеть с джунами просто нет, менеджеру ведь нужен результат в короткие сроки
Ну, и всегда стоит помнить, что в сорванных сроках виноват не “тот джуниор, что долго копается в коде”, а его тимлид.
Собственно это и стало причиной моего ухода из той компании.
Сейчас, после восьми лет работы, когда я сам уже стал лидом, стараюсь не наступать на эти грабли и это действительно дает свой результат. Я действительно горжусь своей командой.
Единственная ремарка, порой лида тоже ставят в жесткие рамки, и времени долго сидеть с джунами просто нет, менеджеру ведь нужен результат в короткие сроки
Спасибо за статью.
Собственно, опыт конвертируем на все IT-специальности, его применимость не ограничивается разработкой.
Собственно, опыт конвертируем на все IT-специальности, его применимость не ограничивается разработкой.
Благодарю! Кратко, полезно и по сути.
Милая статья, на мгновение вспомнил молодость.
Он понимал, что джуниору оценки не должны ставиться сверху в жесткой форме, но одновременно с этим он не
давал мне завышать временные трудозатраты.
Оценки сверху не должны ставиться не только джуниору. Если тимлид назначает оценку, то он и является ответственным лицом за любой срыв сроков по задаче. Задача тимлида — получить оценку от разработчика (жунивора или сенивора) и сравнить ее со своей внутренней. Если есть расхождение в любую сторону — обсудить и выяснить детали.
Тимлид, спустя какое-то время, видит написанный в рамках этой задачи код, тихо ругается и
правит его.
Код разработаный разработчиком как джунивором так и сенивором — это их зона ответственности. Просматривать код должен не только тимлид и не столько он, сколько другие члены комманды (им потом придется с этим кодом работать). Они должны давать рекоммендации, а тот кто не прошел ревью — должен вносить правки (wipe your own ..s).
В целом я так понимаю статья больше о проблемах juinor тим лида, чем девелопера. Человек уже получил должность, но еще не понял в чем ее суть.
Про просмотр кода и ревью я как раз и говорю, и я с вами согласен.
Думаю, можно и так сказать. Это не стататья по сути, а просто небольшая попытка анализа ситуаций, о которых я слышал. К сожалению, вокруг полно ИТ-контор, которые думают лишь о прибыли, а не о взаимовыгодном сотрудничестве. И там зачастую пребывают такие-вот «тим-лиды».
В целом я так понимаю статья больше о проблемах juinor тим лида, чем девелопера. Человек уже получил должность, но еще не понял в чем ее суть.
Думаю, можно и так сказать. Это не стататья по сути, а просто небольшая попытка анализа ситуаций, о которых я слышал. К сожалению, вокруг полно ИТ-контор, которые думают лишь о прибыли, а не о взаимовыгодном сотрудничестве. И там зачастую пребывают такие-вот «тим-лиды».
К сожалению, вокруг полно ИТ-контор, которые думают лишь о прибыли, а не о взаимовыгодном
сотрудничестве. И там зачастую пребывают такие-вот «тим-лиды».
Не согласен. Там где думают о прибыли — умеют считать. Тимлид переписывающий код за джуниором — это:
- Два человека делают работу одного
- Более дорогой ресурс делает работу более дешевого
- Тимлид делая работу разработчика крадет время из своих непосредственных задач либо не отдыхает — снижает свою эфективность
Обычно позицию создают тогда, когда знают что человек будет 100% времени занят, может конечно быть что тимлида назначили с рассчетом на будующий рост, тогда такая ситуация может быть относительно терпимой.
----Смотри, а вот что случится, если я передам этому методу пустую строку на вход?
Массу подобных вопросов можно было снять написав юнит -тесты — они хорошо дисциплинируют в написании понятного кода.
Массу подобных вопросов можно было снять написав юнит -тесты — они хорошо дисциплинируют в написании понятного кода.
Можно перефразировать.
Джуниор написал кусок функциональности и юнит-тесты к ней, но не учел возможность NPE по неопытности, соответстенно и теста данного нет. И тимлид предлагает ему данный тест дописать, заодно показав на косячный момент и заставив писать тесты с учетом различных сценариев. Суть не меняется.
Джуниор написал кусок функциональности и юнит-тесты к ней, но не учел возможность NPE по неопытности, соответстенно и теста данного нет. И тимлид предлагает ему данный тест дописать, заодно показав на косячный момент и заставив писать тесты с учетом различных сценариев. Суть не меняется.
Смысл статьи: хорошо быть джуниором с хорошим тимлидом в адекватной компании, и плохо — с плохим тимлидом в плохой компании. Поспорить правда сложно.
В жизни абсолютно такая же ситуация и встречается сплошь и рядом. Разберём типовую ситуацию: в хорошей и при условии, что каждый член семьи воспитан с детства; с самого детства мальчика/девочку мать забирает с садика одевают обувь(с 2 лет как правило) и ухаживает/направляет при определённых ситуациях, далее ситуация располагает следующим образом, те повзрослевшие мальчик/девочка ухаживают за старенькой матерью — помогают одевать также обувь(как правило с 90 лет), приобретут лекарства, сводят в баню то есть понятно должный и своевременный оказывается уход.
Это и есть воспитание. И так или иначе внутри «системы» мы берём на себя обязательства в воспитании другого человека что делать? Представить, что человек родной; либо изначально необходимо было выстраивать своё предприятие со своими близкими.
Но как показывает практика, лучше взаимодействовать со случайными людьми внутри системы, т.к. с родственниками бывают неурядицы.
Да и не стоит забывать, что Россияне пользовались и пользуются западными технологиями(не своё генерируют, а улучшают на имеющейся основе). Учить и ещё раз учить историю.
Это и есть воспитание. И так или иначе внутри «системы» мы берём на себя обязательства в воспитании другого человека что делать? Представить, что человек родной; либо изначально необходимо было выстраивать своё предприятие со своими близкими.
Но как показывает практика, лучше взаимодействовать со случайными людьми внутри системы, т.к. с родственниками бывают неурядицы.
Да и не стоит забывать, что Россияне пользовались и пользуются западными технологиями(не своё генерируют, а улучшают на имеющейся основе). Учить и ещё раз учить историю.
Sign up to leave a comment.
Сложно быть Junior'ом