Что делать с джуниор программистом, который самоучка и не с этой планеты?

Question

[beem7]

Если серьезно, то человек, конечно, не инопланетянин, но имеет странную судьбу и сложно понять в итоге, хорош он или плох.

Постараюсь разделить его проблемы на две категории.

Категория №1.
Его хобби всегда было не только программирование, но и техника. Делает всякое своими руками, изобретает, конструирует. Именно всякое. Может залезть в совсем незнакомое дело, тщательно подготовиться и сделать качественно. И с первого раза. Иначе (в чем отличие от программирования) будет трата денег на материалы и детали, а он из нищей семьи, поэтому лучше еще немного поэкспериментировать на кошках и потянуть времени, пока придет крутая мысль. Какие проблемы из этого растут?
- неспособность работать с изменяющимся ТЗ. С ним же никогда не было начальника, который мог сделать некорректную UML, лишь бы в срок, а потом бы он ее переделал и заставил разработчика переделать его код по этой UML.
- неспособность делать что-то делать в срок, но не совсем понимая задачу, а потом переделывать. Над ним же никогда не было начальника, который каждый день требовал отчетов, чтобы убедиться, что сотрудник не ничего не делает.
- внимательность и хорошая память. Он не привык делать все так, чтобы легко было проверить отсутствие ошибок. Ведь он способен проверять свое изделие долго. А если подгонять его, то будет куча багов.

Дальше хуже.

Категория №2.
Стрессоустойчивость.
В детстве чувак много хулиганил, врал родителям и т.д. Поэтому крайне закален. Заказчик уже сбился с ног, все время дергает нас, мы все время дергаем его, мы его уже уволили (в очередной раз) и просим лишь доделать долги, а он (вытянув из нас последние силы оправданиями в духе "заказчик идиот, ну не успели мы к дедлайну, так все равно код надо доделать и чтобы он работал! не мешайте мне!") сидит и спокойно копается в коде, устраняет что-то неработающее, параллельно приглаживая всякие мелкие косяки, которые никак нельзя не пригладить, даже если проект сгорел и горим уже мы.
Сам он при этом не понимает, почему мы так же не воюем со своим начальством, с заказчиком, ведь тогда порядка было бы в сто раз больше, а работы меньше. Ведь сколько уже дедлайнов сорванных, а заказчик все еще с нами и все вроде как нормально. Только вот мы-то не спецназ, а просто команда разработчиков. И не можем так торговать своими нервами, у нас сердце пошаливает, голова кружится... Так и умереть можно на рабочем месте.

Категория №3.
Интроверсия.
Он склонен всю задачу целиком держать в своей голове и думать над ней один. И чтобы никто не отвлекал. Обсуждать с кем-либо задачу, даже просто общаться в корпоративном чатике среди рабочего дня - все это вроде не дает видимых проблем, но по нему видно, что это его сильно раздражает.
В целом, нерешаемых задач для него нет. Но вот решаемых задач в срок тоже бывает маловато.

Comments

[Максим Федоров]

неспособность работать с изменяющимся ТЗ.

Это не способность жить с реальностью. Если Задача и вводные критерии поменялись — зачем их делать?! Непонимание обыденного факта этой жизни делает такого специалист глупцом. Отдельно стоит понять, что ТЗ — глупость, тогда как нужно ПОНИМАНИЕ задачи, формальная писанина говорит что сделать, а не зачем. Понимание говорит зачем делать ИЛИ НЕ ДЕЛАТЬ те или иные пункты.
Почитать: Исполнитель понимает задачу

неспособность делать что-то делать в срок, но не совсем понимая задачу

Туда же... Нельзя выполнить в срок что-то, когда не понятно зачем это нужно. ТЗ говорит что делать, но не говорит зачем это делать и потому может меняться по определению, тк причина задачи в желании/потребности... и это не потребность "чтобы мое задание выполнили"

Над ним же никогда не было начальника, который каждый день требовал отчетов, чтобы убедиться, что сотрудник не ничего не делает

Не понятная вода и каша. РЕзультат ваших некоторых мыслей, для меня лично не понятные строки...

[Виталий Першин]

Походу никто не понял, что ТС и есть этот джуниор...

[Crash]

я бы просто с таким распрощался и нашел нового джуна, благо джунов войти-вайтишников хватает.

[shurshur]

Виталий, я думаю все так сначала подумали, но к середине текста становится очевидно, что про самого себя так не пишут.

[Виталий Першин]

shurshur, К середине текста, когда она начинает говорить о своем нраве и оправдывает срыв дедлайнов не забывая рассказать о том что у него кружится голова?, ну ок...

[Robur]

beem7 Чтобы решить что делать, надо решить чего вы хотите получить. У вас в посте просто жалобы на человека, никаких целей-то нет. какой-то выброс эмоций: накипело, все такое.

Виталий, к середине текста, где явно написано "он" и "мы".

[Виталий Першин]

Robur, Да, ведь он пишет о себе в 3-м лице и хочет понять что думает о нем руководство и чего от него ожидать. Если это вам не очевидно, то посмотрите его вопросы.

[Robur]

Виталий, посмотрев вопросы, пожалуй соглашусь с вами.

[shurshur]

Виталий, да, вопросы у него как минимум та ещё жесть.

Но если это про себя, то как минимум начало доходить, что подобное состояние ненормально.

[kolossradosskiy]

Что это была за хня про хобби и про нищую семью?

Answer 1

[Антон]

Во первых:
Нужно разделять личные качества и профессиональные!!
(Какая разница, что он бедный или хулиганил....)
Второе:
Если профессиональные качества вас устраивают, то пусть человек работает и не мешайте ему.
Если не устраивают, то ищите другого специалиста
Третье:
Срыв сроков это не только его вина или еще чья то. Часто так бывает, что это общая вина: заказчик меняет ТЗ, менеджмент обещает сроки, лишь бы ухватить заказ, технический директор не вникает в процесс.... В итоге всё вешается на джуна.
И еще:
Программист это творческая профессия. Это не оператором работать по 8 часов по некому алгоритму. Тут и думать надо и вникать и прорабатывать отдельные моменты. Нужно создавать условия для комфортной работы, а не наседать и стоять над душой. Но чтобы релакс не затягивался, даже долги нужно планировать.
Далее необходимо понять, почему возникают задержки:
Если это плохая планировка времени, то пусть работает как ему удобно (в ночное время или вечернее), если задержки возникают из-за недостатка знаний, значит нужно их подтягивать, включая курсы или помощь наставников.
И:

Он склонен всю задачу целиком держать в своей голове и думать над ней один. И чтобы никто не отвлекал. Обсуждать с кем-либо задачу, даже просто общаться в корпоративном чатике среди рабочего дня - все это вроде не дает видимых проблем, но по нему видно, что это его сильно раздражает.

Меня тоже раздражает отвлекаться каждые 5 минут на сообщения, которые вообще не относятся ко мне. А бесконечные обсуждения могут бесконечно обсуждаться.
Взялись работать - работайте. Летучка 10 минут каждый день с утра. 60 минут в понедельник. И всё. Ибо нех.

С ним же никогда не было начальника

Начальник не команда. Начальник может и не быть наставником, советчиком, помощником.
Более ценно, когда есть кому подсказать.

ведь тогда порядка было бы в сто раз больше, а работы меньше

Работы было бы меньше, если бы вы, там наверху, между собой всё порешали, а потом уже приходили со своими хотелками, а не переобувались каждый день со своим ТЗ "не знаю что хочу".

Answer 2

[Saboteur]

Если человек не понимает, что деньги платят не за сделанную задачу, а за сделанную задачу в срок - то штрафовать его за каждый раз, когда он проваливает дедлайн. У него резко понизится мотивация делать какие-то костыли и повысится мотивация успевать в дедлайны.

Если обе стороны это не устраивает - распрощаться. Вы не папа и не мама, перевоспитывать - не ваша задача. Он тоже не малое дитя, должен понимать задачи которые перед ним ставят. Если в задачу входит в срок и он подписался под этим сроком, то должен понимать что игнорировать его нельзя. Понятно что все могут столкнуться с неожиданными проблемами, но это должны быть единичные случаи, а не регулярные.
Или человек не умеет планировать свое рабочее время, или не умеет определять сроки на решение задачи - первое это проблемы разработчика которые он должен решить самостоятельное , второе - это задача тимлида помочь и наладить оценку времени на задачи.

"И не можем так торговать своими нервами, у нас сердце пошаливает, голова кружится... Так и умереть можно на рабочем месте."

Это ОЧЕНЬ СТРАННО, когда дедлайны целого проекта зависят от ДЖУНА. Что-то в вашем проекте вы недоговариваете.

Comments

[beem7]

У него резко понизится мотивация делать какие-то костыли и повысится мотивация успевать в дедлайны.

Видите ли, он задерживается не только из-за того, что делает костыли или чего-то "не может" Он еще и перфекционист. И нередко с технической части он как бы действительно прав, но только никто из нас не просто так не починил вон ту мелочь, а потому что ее починка долга и нету времени. И при этом случаев, когда он именно не может что-то быстро решить, тоже достаточно. Прикольное сочетание, да?

Это ОЧЕНЬ СТРАННО, когда дедлайны целого проекта зависят от ДЖУНА.

А как нужно? Мы должны сами параллельно делать его задачи, на случай, если он не успеет?

[Сергей Горностаев]

beem7, да пофиг из-за чего он задерживает, рынок ждать не будет.

[Saboteur]

beem7,

Он еще и перфекционист

Это его личная проблема. Нужно ему пояснить, что платят ему не за перфекционизм, а на вовремя сделанную фичу. Если он считает себя перфекционистом, не таким как другие - он просто еще маленький несамостоятельный мальчик, который видимо не понимает откуда вообще берутся деньги и кто и за что их платит. Пусть идет ищет тех, кто платят за перфекционизм.
А то каждый может годами вылизывать 100 строк кода, не успевая в сроки, и думать что он особенный.

А как нужно? Мы должны сами параллельно делать его задачи, на случай, если он не успеет?

Тим лид отвечает за то, что проект будет сдан в срок. Если один из разработчиков не успевает, то задача тимлида - во-впервых знать о прогрессе и заранее понимать что кто-то не успевает. Перераспределить задачи между разработчиками так, чтобы ПРОЕКТ был сдан в срок. Перед заказчиком отвечает не джуниор, а тим-лид. Если он постоянно "перфекционирует" и его задачи приходится выполнять другим - то распрощаться, раз он все равно выходит бесполезным.
Но из-за отставания одного джуна заваливать весь проект - если бы я был заказчиком, я бы вообще не понял, и больше не связывался с компанией, которая не может урегулировать внутренние проблемы. Заказчик тем более не будет бегать за джуниором и объяснять ему важность сроков.

[Saboteur]

Пусть почитает истории. Почему взлетела Windows а не OS/2 (потому что Windows быстро вывели на рынок, а OS/2 долго вылизывали перфекционисты и она просто опоздала, хотя была гораздо стабильнее)

Почему Айфон считается "первым" смартфоном (не потому, что он идеальный, сколько проблем было у первых айфонов, да и не только первых), просто его торопились выпустить раньше, знали что гугл дышит в затылок.

Пусть осознает, что преждевременная оптимизация - не лучший выбор.
Хорошо, когда человек осознает как плохо, как хорошо и как идеально и делает сознательный выбор, исходя из сроков и возможностей. Это его плюс и задел на сеньора. Но подводить проект - нельзя

Answer 3

[nApoBo3]

Если один джун приводит к регулярным срывам дэдлайнов и что-то ещё должен доделать после увольнения иначе опять сроки сорвем, то наверно это ему повезло оказаться за бортом этой лодки, а не тем кто в ней остался.
Оставьте человека в покое, пусть он с собой разбирается сам, у вас сами проблем по горло.

Comments

[Robur]

Более того, на этом джуне похоже все держится, раз его уже много раз увольняли и брали обратно, плюс никто не может за него сделать его работу, и этот джун диктует всем вокруг как должна быть организована работа.
Тут действительно гораздо больше вопросов к автору поста чем к этому разрабу

Answer 4

[Яков Е]

Как уже было сказано, проблема в первую очередь в менеджере, а не в разрабе, хотя и он не подарок.

Что делать? Менять процессы.

Например, в таск трекере при смене статуса карточки на "В работе", разраб обязан проставить ожидаемое время выполнения. Если оно больше 8 часов, значит карточка разбивается на несколько. Любые подзадачи больше 2 часов декомпозируются через чек-лист. Если карточка не сделана в срок, значит это повод обсудить с менеджером, в чем проблема, какие варианты решения, сколько ещё времени надо.

Ещё посмотрите на "Центрирующие парадигмы Фридмана".

Answer 5

[xmoonlight]

Пусть всё делает по-шагам.
Распишет архитектуру и сдаёт каждый модуль (вначале - логику, затем - рабочий код). Часть модулей - можно поручить делать другим. (устранили 2 проблемы)

Общение: здесь вопрос конструктива. Возможно, вы (команда) хотите отслеживать правильность принятых им решений и выбранных алгоритмов/технологий, а возможно, просто поболтать по проекту и сделать вид, что идёт работа и работают все по своим задачам в тесном общении по проекту.
Нужно смотреть конкретно на детали общения и выявлять причины.